![[de]](/mwf/flags/de.png "Germany")
I have written a little patch which moves the line pickup handling to the Clonk and want to ask for comments on it.
In detail, I removed ObjectComLineConstruction in C4ObjectCom, which was only used for handling line pickups. I ported the line pickup part to the Clonk in its context menu and extended it so that other line kits work correctly if they have the callback IsLineKit() and, in the associated lines, LineKitID() returns the line kit the lines are built with (or nothing if they are built with LNKT).
In detail, I removed ObjectComLineConstruction in C4ObjectCom, which was only used for handling line pickups. I ported the line pickup part to the Clonk in its context menu and extended it so that other line kits work correctly if they have the callback IsLineKit() and, in the associated lines, LineKitID() returns the line kit the lines are built with (or nothing if they are built with LNKT).
Attachment: linepickup.patch (12k)
![[us]](/mwf/flags/us.png "United States")
I haven't yet tried this out, but in general moving such stuff from the engine to the script is always a good thing, of course. I have two small comments on the patch:
Hm, the engine did not do this, did it? It might be nice to avoid the "abrupt" stop via SetX/YDir() in case SetComDir is enough, such as when the Clonk is in the "Walk" action. This makes the clonk decelerate a few frames instead of stopping from one frame to the other which might especially be visible when having zoomed in a bit. On a related note: I do find it annoying that SetComDir(COMD_Stop) is not enough to make something stop when it is swimming or floating... but that's another story...
Even if this works (does it?) it seems like an unpleasant hack to stuff into one line what belongs into two.
>
+ SetXDir(0);
>+ SetYDir(0);
>+ SetComDir(COMD_Stop);
Hm, the engine did not do this, did it? It might be nice to avoid the "abrupt" stop via SetX/YDir() in case SetComDir is enough, such as when the Clonk is in the "Walk" action. This makes the clonk decelerate a few frames instead of stopping from one frame to the other which might especially be visible when having zoomed in a bit. On a related note: I do find it annoying that SetComDir(COMD_Stop) is not enough to make something stop when it is swimming or floating... but that's another story...
>
+ var kitID = cline->~LineKitID() || LNKT; //downwards compatible
Even if this works (does it?) it seems like an unpleasant hack to stuff into one line what belongs into two.
>Hm, the engine did not do this, did it?
Actually, the engine did ObjectActionStand, which is equal to
SetComDir(COMD_Stop);
if (SetAction("Walk")) {
SetXDir(0);
SetYDir(0);
}> Even if this works (does it?) it seems like an unpleasant hack to stuff into one line what belongs into two.
It works with strict 2 and it's a comfortable alternate also used in Perl for a:a?b.
> Actually, the engine did ObjectActionStand
So if nobody remembers why then we should maybe try to change this as I proposed above - leaving a comment in the code so the place where we changed behaviour intentionally can easily be found in case it breaks something.
My guess is that all actions processed by ObjectComDigDouble in C4ObjectCom can also be done by a C4script inside the Clonk. I think the structure can be something like:
- Check content object: if ~Activate return;
- Check background objects(line removal, tree chopping, other): FindObject(Find_AtPoint(), Find_Func("HasActivateInteraction")) and then call in that object ActivateInteraction, or something similar. return if something was done.
- Clonk internal Activation.
I'm in favor of everything that can be pulled from the engine and rewritten in C4Script.
In general, that's the right direction (and definitely in this case). But we should not forget to make sure that:
* We don't lose functionality
* The new stuff is at least as easy to use from a Scripter's point of view (customizability is not everything, we also need clear and easy interfaces).
* We don't run into severe performance losses. Might be a bit paranoid to bring that up, but I remember running into that with Torque faster than I imagined.
* We don't lose functionality
* The new stuff is at least as easy to use from a Scripter's point of view (customizability is not everything, we also need clear and easy interfaces).
* We don't run into severe performance losses. Might be a bit paranoid to bring that up, but I remember running into that with Torque faster than I imagined.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
