When moving attached objects, it will now move the attachment target along with the object. This makes moving elevator cases and wind generators a lot easier.
As discussed in http://forum.openclonk.org/topic_show.pl?tid=2917, I
have merged all copyright notices into a single file and referenced that
merged file from each source file.
For the updated source files, the timeline has been split into three
parts:
1. Pre-RWD code (before 2001)
2. RWD code (2001 through 2009)
3. OpenClonk code (2009 and later)
All pre-RWD copyright notices have been left intact, as have RWD-era
copyright notices where the file did not have a RedWolf design copyright
notice but only individual author ones. All copyright notices of the
OpenClonk era have been replaced by a single notice ranging from the
first recorded year to the current year (2013). Mape code did not get a
OpenClonk Team copyright notice because it is somewhat separate from the
main OpenClonk codebase and has only been touched by Armin Burgmeier.
Sending handles might desync network games if one of the connected
engines had run a different scenario before the current one, since ID
handles aren't cleared between games.
fInternal basically acted as a reverse "evil bit" as in RFC 3514: when
set, the engine would not do any checks on the script contained in the
control packet, nor log the script (visibly in game; the packet log
would of course contain the packet). A malicious game client thus would
be able to inject arbitrary script without people (immediately) noticing
anything was amiss.
As of this patch, only the host is able to execute arbitrary scripts,
and those will be shown in the message board for all players to see.
This privilege can be irrevocably disabled in network games by any
client by using the "/nodebug" message board command.
Closes#936.
Actions changed include dropping definitions, (de-)selecting objects,
player elimination. This removes some more pre-assembled C4Script code
going across the network unchecked.
Part of #936.
Instead of sending pre-composed C4Script code across the network, make
player self-management (surrendering, team changes etc.) send a
dedicated control packet. This means less network traffic, and also a
smaller attack vector for malicions C4Script injection.
Part of #936.
MsgBoard commands used to be evaluated on the issuing client. Malicious
clients would be able to insert arbitrary C4Script code to be executed
instead of the scenario-defined command; other clients would not be able
to tell the difference.
Instead, we now only send the command identifier, issuing player and
command parameter. This is still not perfect because clients can
insert any player they want, but it's better than before.
Part of #936.
Rotation was still stored as an integer and as a fixed point number.
Compute the integer on demand from the fixed point instead, like the
position. Rewrite the movement code where the two variables were
temporarily out of sync.
This requires replacing C4AulScript::Def with C4AulScript::GetPropList() and
C4DefScriptHost::Def, and making C4GameScriptHost::GetPropList return the
scenario proplist prototype.
Definition calls won't be able to change the local variables, of course.
Other proplists will be able to use local variables once they can have
functions.
I hate StdStrBuf. It's just close enough to any sane string class that you think
it does reasonable things, then when you don't look it will turn around and stab
you in the back with a rusty fork.
+ CustomMessage now uses a normal picture of a definition/object
+ BigIcon is now the small (and only) "Portrait" the player chan choose
+ In future, one could of course make the max size of the BigIcon bigger
There's no need to go through the entire object list to get an object
number, so convert most usages of ObjectNumber(obj) with obj->Number. Add a
new method to check proplist pointers for debugging purposes to
C4PropListNumbered.
This time with more manual checking and using git blame -M -C, so that
a few cases of copied code get a copyright notice corresponding to
their initial introduction.
This also converts internal usage of ForcePosition to C4Real. For the
attach procedure, this should only result in smoother movements, but the
consequences for flight are less clear.
Peter Wortmann