PreTravelled() virtual method

[MartinHowe]

I have recently been trying to implement a scheme whereby an actor does something special when the player is about to end a level. For my use case I have hacked up something that works when hubs are not involved, but would require significant effort if they are and even then is kinda hacky. This is done via an inventory item in the player's possession so that it doesn't have to depend on maps being designed for it, subclassing PlayerPawn, etc. I tried also having actors notify the inventory object from OnDestroy(), but the player references in the array are lost by then.

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

The TRAVEL_ENDGAME is included for completeness; it could also be used if it is desired to finalise some custom CVars or write stats to the log file.

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.

[Graf Zahl]

As actor virtuals this is a clear 'no', this stuff makes more sense as an event.

[MartinHowe]

Indeed, and I suggested this as an actor virtual only because a lot of stuff that I would have expected to be events seem to be done that way. So before commenting further or trying to implement anything, please can I have some clarification as to how the Devs decide which paradigm is used for each event-like thing?

In particular, I thought there was a downer on events generally, due to the mess in EDuke32, or is that only because they don't use scoping?