PreTravelled() virtual method

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

PreTravelled() virtual method

Postby MartinHowe » Sat Dec 19, 2020 3:30 am

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 allExpand view
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.
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom

Re: PreTravelled() virtual method

Postby Graf Zahl » Sat Dec 19, 2020 4:52 am

As actor virtuals this is a clear 'no', this stuff makes more sense as an event.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: PreTravelled() virtual method

Postby MartinHowe » Sat Dec 19, 2020 6:39 am

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?
User avatar
MartinHowe
In space, no-one can hear you KILL an ALIEN
 
Joined: 11 Aug 2003
Location: Waveney, United Kingdom


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest