ZDoom

so can I request clientside scripts from zandronum into zdoom please?

So in current version, code like this produces results like this.
That's also an usage example. Any feedback on usability of this?

(also, @Graf, why exactly do Fist and Pistol call OnDestroy, but next given weapons don't call PostBeginPlay?)

Global vars?

As an aside, this could be EXTREMELY useful for my other mod I'm working on, and choosing random respawn locations. More info on that later when I have time.

Using EventHandler as static storage is possible. Although I personally wouldn't... or would. Who knows.
It wasn't designed for that, but fits that role perfectly.

I'd definitely use it for spawn points and keeping track of what team belongs to which since they can change teams based on whichever team is operating on them.

We have structs, and heck, could even use classes for messaging, and thus, your point about extensibility is invalid, since we could pass them into callbacks. But that's all beside the point that you missed in the first post I made regarding it: I don't see the proposed system easily interoperable with other parts of the game. For example, I want the Archvile to actively seek and resurrect fallen monsters. With your system I would have to keep track of all Archviles alive, "subscribe" to the "actor died" event, then from the handler pass the data to the Archviles and make them get over there and raise the fallen, rinse and repeat. In ideal world, I would make each Archvile subscribe to the same event, and cleanly get the relevant message data and deal with it.

No. You will have to do a ThinkerIterator or BlockThingsIterator, check for dead actors and guide the archvile to the closest of them.

WorldThingDied is not for altering the playsim, it's for collecting stats, displaying various messages, and such.
For example you have a custom statusbar which checks boss monsters in the level and adds/removes them from the display.
Or if you want to observe damage events and do all kinds of processing about them (i.e. see if actor X was damaged by player Y, add Z score to the player based on the type or calculated power of damaged monster).

Otherwise, if you really want to use event handlers for this, you have to store all dead things in an array in an event handler, and in the archvile do something like this: Currently you'd have to do a static array with a length counter, but I know in the future there are going to be dynamic arrays and maybe linked lists, which makes this approach rational.
And there's nothing wrong with this, having 1000 event handlers in separate Actors is not going to work properly anyway performance-wise, because the current architecture assumes there will be AT MOST some 10 event handlers registered.

Also, one major point that you are missing — handlers are implemented as classes because they should not be tied to the playsim (actors or thinkers), as event handlers are actually ENTRYPOINTS into the stuff that is not available for actors at all, like drawing on the screen, doing user input, perhaps in the future even loading your own lumps by something like GameLoadLumps. It's a plugin system more than everything else.
The playsim stuff is there mainly so that you don't anymore need to depend on ACS for catching these events (like map OPEN, etc).

Also, tested with Thing-related handlers in nuts.wad, don't seem to get any performance regressions if NOT handling any events, and almost unnoticeable performance regressions with non-empty defined handlers (like -3 fps or so, while I get 18 fps in nuts.wad after firing a pistol even on a regular GZDoom).

Major Cooke wrote: I too would love to hear more about this.

First, you must establish a relationship between the spawner and the spawnee (eg the player and the particle, respectively). Either store the spawner in a pointer -or- make an actor variable have a valid reference to it -or- whatever else that works for you.

Then, in BeginPlay or Tick, check for the consoleplayer, like this:
Look inside zscript/inventory/powerups.txt APowerSpeed :: DoEffect for a similar concept (although it's functionality is reversed, is checking for the first person camera instead of just the actor, and it's just making the trail invisible instead of destroying it; see below)

So how is this safe in multiplayer?

Well, the particle I am spawning is COMPLETELY non-interactive - there's no collision, it doesn't affect anything else around it, and most importantly - the particle does not spawn anything else!!! That last bit is very important; as soon as you try to spawn something from that particle, the game will desync.

Also, another crucial step is that the particle MUST unconditionally spawn on all machines, for all players. That's the rule. So I made no effort to stop the particles from spawning for everyone.

So because my precipitation particle is completely isolated in terms of collision and spawning new actors, I can actually afford to destroy it, if it doesn't "belong" to my player actor. So this means that I can crank up the density of the particle spawn for MYSELF, and other players will not notice a thing on their screens ("my" particles don't even exist for too long on their machine; they've already been Destroy()'ed as early as possible!)

Lastly, if you're too afraid of this, you can also do what PowerSpeed is doing in gzdoom.pk3 and simply make it invisible, although that won't get rid of the Actor overhead because it still exists in the world, just made invisible.

ZZYZX wrote:modders that do care about demo and networking compatibility!

Of course I do. Multiplayer still works the last time I played it a few weeks ago, and there were people who went through a lot of trouble to even make multiplayer a thing in Doom in the first place, so why not support it?

Also, awesome work on your event handler system. I can't say I fully understand yet the entire concept and how to use it; but if it will let me replicate OPEN ACS scripts, and to do things like store quest variables and quest progress that remain persistent between maps - I'm stoked for it.

Nash wrote:Also, awesome work on your event handler system. I can't say I fully understand yet the entire concept and how to use it; but if it will let me replicate OPEN ACS scripts, and to do things like store quest variables and quest progress that remain persistent between maps - I'm stoked for it.

You can't make something persistent between maps in the savegame using event handlers.
That's going to be an entirely different concept (i.e. storing serialized global variables in ZScript) which is probably out of scope of the event system.

In the event system, event handler is either serialized or global.
That is, you can have GameInfo-defined Static event handler, but this will result in something that can't be stored in a savegame and will always be loaded from the current source code.
Then you can have GameInfo or Map-defined non-Static event handler, and it will be saved to savegames and between levels in a hub, but you won't be able to access these from another level.

I'm a bit confused about the "not for altering the playsim" statement -- This makes sense for render events but not so much for the world types. Would I not be able to do something like spawn an actor in a WorldThingDamaged event or iterate through the global players[] array in WorldLoaded and initialize some stuff? Seems like I'm missing or misunderstanding something.

The one I'd be really interested in though is the future "PlayerJoined" event; that'd be the proper way to init player vars on map start and presumably we'll at be allowed to modify the player through that, at least.

If the event is fired from within the playsim it should be safe to do play-related things in it.

Of course we all know that with so much power at your disposal comes great responsibility. This event system is very powerful but that also means it's easily abusable in the end of less skilled modders.

@Nash: To clarify this is spawning one for all eight of them? (eight in total) Or because this is non-interactive, the actor can safely call Destroy() without consequence and only one spawn is needed?

Does zscript support #defines ?
and where should I add the doomed number in my zscript code?
EDIT:
And can I make global vars or I'm forced to create an actor where everyone has access to his vars?

ibm5155 wrote:Does zscript support #defines ?

IDTS, use const for that.

ibm5155 wrote:and where should I add the doomed number in my zscript code?

https://zdoom.org/wiki/MAPINFO/Editor_number_definition

ibm5155 wrote:EDIT:
And can I make global vars or I'm forced to create an actor where everyone has access to his vars?

Event system kinda allows you to have global vars in the handler, but that's a hack and otherwise you have to create an actor, yes.
(and Graf hasn't pulled nor commented the ES yet anyway)

He's busy with a work project so it'll have to wait.