I tried using the Travelled() method in the inventory item and keeping pointers to some map objects, but they are destructed by the time Travelled() is called, even though the inventory object still holds a reference to them: the GC goes and nulls those references out! Normally I would consider this a bug in the GC as even though the objects must be removed from the map as that map is being destroyed, they should surely exist as pure data until all references to them are gone. The only other alternative is to have actors speculatively update the inventory objects (performance penalty) every tick and even then when multiplayer is involved it gets complicated.
All this hackiness and performance hit could be avoided just by having the dual of Travelled(), so that the work only needs to be done when the level is just about to end and when all player related info (e.g., FriendPlayer in friendly monsters) is finally fixed. In any case, it seems odd that teleport functions have a "pre" variant but end level does not.
Please can we have some sort of complement to Travelled() for inventory items and player pawns? I would prototype it something like this:
Code: Select all
virtual void AboutToEndLevel(int how)
const TRAVEL_ENDLEVEL = 0; // level is about to end, may be reentered (if in a hub)
const TRAVEL_ENDHUB = 1; // level is about to end, can never be reentered as end of hub
const TRAVEL_ENDEPISODE = 2; // level is about to end, can never be reentered as end of episode
const TRAVEL_ENDGAME = 3; // level is about to end, can never be reentered as end of game
Or is there already a good way of doing it that I don't know about?
EDIT: If this is likely to be a case of, "yes, but DIY", at least I'd then know it was worth doing it; I'm not at all familiar with that part of GZDoom's code, my last big contribution to ZDoom was in 2008, and I hate the clumsy way Git works with pulls and so on, so I'd only want to DIY if I knew that it would be accepted in some form.
EDIT EDIT: This doesn't need access to the UI nor return a bool to cancel level end or whatever; I imagine they would cause massive problems in multiplayer; it's more about getting data on that state of the mod's objects so that the special effect occurs in Travelled() when the next level (if any) is started.