So I made the necessary internal changes so that Effects are now proplists. The question now is how the script interface should look like.

1. proplist EffectPropList(object Target, int EffectNumber)
The lazy-and-dreadful variant. Only upside compared to EffectVar is that one can use names instead of numbers. (EffectPropList(target, num).OldWalkSpeed=target.ActMap.Walk.Speed)

2. func Fx*Start(object target, proplist effect, temp)
Better (effect.OldWalkSpeed=target.ActMap.Walk.Speed), but requires function interface changes all over the place. If we had decent static analysis, we could probably find them all. Changing only FxFooStart etc. calls with script and manually fixing up the rest might work. The engine functions like ChangeEffect and RemoveEffect would use the proplist just like the effect number today.

3. Have the effect be the "this" object for the effect calls. Would make the context during effect callbacks effectively global. Might violate lots of assumptions in the engine. Would require lots of script changes, so this and the following options require some sort of transition plan.

4. Like 3, but make the command object/id be the Prototype of the effect. Probably not a good idea - for example, setting local variables silently modify the effect instead of the object. But only allowing definitions might work - Effects would become a second possible instance for definitions besides objects.

5. Callbacks stored as first class functions in a non-definition proplist that is used as the effect prototype. The classic object oriented approach, and C4Script does lack first-class functions anyway. I didn't want to introduce them as secondary to functions identified by name, but OpenClonk is young enough yet that we could probably replace all those interfaces using function names to use pointer to functions instead. Raises lots of design questions (Do we want closures? What's the syntax?) and needs yet more serialization code for savegames.