ZDoom

• How does an ACS ENTER script (apparently, according to people more knowledgeable than me) do this properly? I'm not familiar with all the inner workings and quirks, but to my understanding it properly catches an actual player.mo spawning in the level and can be used for initialization. Or am I wrong, and an ACS ENTER script A) triggers for voodoo dolls too, B) triggers the same way as a PlayerEntered event, or C) something else?
• If a spawn event is added that triggers on all player spawns, including voodoo dolls, what about adding a flag to the event indicating the player is a voodoo doll? Again I'm not familiar with the inner workings, but I would hope GZDoom internally tracks and/or "emulates" voodoo doll behavior in such a way that it can be flagged for events like this.
• If the engine can't tell the event handler that the spawned player is a voodoo doll, would it really be so bad to run a spawn event on every player and voodoo doll anyway? If they're not supposed to be differentiated from actual players, I would want to run initialization on them too, right?
• If PlayerEntered is kept as-is, what is the recommended workaround for ensuring I actually have a valid / existing player? Obviously the event only runs once so I can't simply not do initialization if the player.mo doesn't exist. For example, I received this pull request on my mod Ugly as Sin (a sub-mod for Hideous Destructor). As I understand the workaround, it defers my initialization code to a separate function. If the PlayerEntered event fails to initialize, it creates a thinker attached to the player, that calls the initialization in the thinker's PostBeginPlay instead. To me, this seems hacky and I declined to implement it in favor of waiting for an answer here.
  • My other theorized solutions included:
  • Doing initialization in a WorldThingSpawned event and checking if the thing is a player.
  • Flagging a potential player in PlayerEntered but running the actual initialization in a WorldTick override that continuously checks if the player.mo exists first

Caligari87 wrote:Sorry for the bump but is there any reason this can't be added?

Spoiler: for context

---

For context, here are my initialization functions that were causing address zero pointer errors for certain players when running in a multiplayer game:

Code: Select all

override void PlayerEntered(PlayerEvent e) {
    PlayerInfo player = players[e.PlayerNumber];
    player.mo.giveinventory("DarkDoomZ_Flashlight", 1);
}

Code: Select all

override void PlayerEntered(PlayerEvent e) {
    PlayerInfo player = players[e.PlayerNumber];
    if(!player.mo.countinv("UaS_FoodRation") || !player.mo.countinv("UaS_WaterRation")) { toSpawn_Rations += 3; }
    if(!player.mo.countinv("UaS_MessKit")) { toSpawn_Messkit++; }
}

(both on the line where player.mo is first referenced)