Not logged inOpenClonk Forum
Up Topic Development / Scenario & Object Development / Interface: Ammunition
- - By Newton [de] Date 2010-01-13 00:27 Edited 2010-01-13 00:37
Here is an interface/functionality for ammunition and related objects:

Stackable.c4d (L_ST)

Including this object means, the object is stackable. Other objects of the same type will be added automatically to the object. This functionality is similar to the Pack-functionality of the arrows in old clonk titles only more general.  The count of how many objects are stacked together (into a single one, this one) is shown in the picture of the object and can be queried and set via GetStackCount()/SetStackCount(). To take one object of the stack, call TakeObject(). As long as the object exists, one can always take an object, even if it is the last one (self). This object is always outside.
 
On entrance (or to be more precise: on RejectEntrance), it will be checked if the entering stackable object can be distributed over the other objects of the same ID. If yes, this object is deleted and the other object(s) will have a higher stack-count.
 
Example 1:
'15x Arrow' is about to enter a clonk which has '5x Arrow'. 15 will be added to the stack-count of the clonks '5x Arrow'-object (making it '20x Arrow'), the entering object will be deleted.
 
Example 2:
'17x Arrow' is about to enter a clonk which has '15x Arrow' and a bow with '10x Arrow' in it's ammunition slot. 10 will be added to the stack-count of the arrows in the bow, 5 to the stack-count of the arrows in the clonk (assuming MaxStackCount() is 20) and the original arrows-object will have 2 arrows left. If there is an inventory slot left, the '2x Arrow" object will enter the clonk.
 
Most objects which can be stacked might want to set different pictures and ingame graphics for different counts of objects. This can be done by overloading UpdatePicture(), but remember to write _inherited() then.

ExtraSlot
Collectible objects that define HasExtraSlot() and return true, will have an extra slot in the clonks HUD, displayed as a smaller 32x32 box in one corner of the item. Drag and drop on this item will be possible. The slot reflects Contents(0) of the object. The clonk will directly collect new items into this slot too. So the object should reject the collection of all but certain types of objects via RejectCollect (e.g. the bow should only take arrows). For the update of the hud (whether the item is still there or not), the object should also have the function SetHUDObject(object hudobj) and call hudobj->Update() every time the Contents(0) changes (Ejection, Collection2).
Parent - - By Caesar [de] Date 2010-01-13 16:55
Is there a callback to the object being stacked? (I remember some glitches with magic arrows.)
Parent - - By Newton [de] Date 2010-01-13 17:01
The stackable object calls on RejectEntrance() in each and every stackable object of the same ID Stack(this) which returns the count of how many items have been taken. So both sufficiently know of the process to update their variables, name, picture, mass and price.
Parent - - By Zapper [de] Date 2010-01-13 17:43
And what if an object wants to remove itself rather than being stacked? The problem was, that color modulated arrows were used for the "Magic Arrows" spell but you could collect them and that way remove there removal-timer
I remember some crashes when removing the active object in RejectEntrance (or another EngineCallback)
Parent - - By Newton [de] Date 2010-01-13 18:18

>And what if an object wants to remove itself rather than being stacked?


If the object wants to remove itself or not being stacked, it can do so by overloading parts of the stackable-script in their own script. Only of the same ID will the objects be stacked - that means by editing the script of the same object, one is in full control of the stacking.

>I remember some crashes when removing the active object in RejectEntrance (or another EngineCallback)


That should be easily fixable
Parent - - By Zapper [de] Date 2010-01-13 19:14
The problem was that a normal arrow (ARRW) was used as the magic arrow. I always like effects (*NoStack*) as a possibility to prevent stuff like that
Parent - - By Caesar [de] Date 2010-01-13 20:08
I always disliked the abuse of Effects as additional local variables. Couldn't we do that in a more direct way?
Parent - By Sven2 [de] Date 2010-01-13 22:27
We can probably use proplist functionality now.
Parent - - By Newton [de] Date 2010-01-13 20:31
That can be done differently
Parent - By Zapper [de] Date 2010-01-14 22:22
With proplist now probably - yes (while there mostly would still need to be an effect to remove the property from the object after some time - so there would not be a huge benefit I guess)
But I'd like to have the functionality :)
Parent - By Newton [de] Date 2010-01-13 23:55
ExtraSlot is by the way possible for vehicles too. At least it should. That whole thing is untested yet anyway.
Up Topic Development / Scenario & Object Development / Interface: Ammunition

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill