[Zscript] Custom Functions on Actor

[Xaser]

This was discussed briefly in the ZScript thread, but I'm gonna go ahead and open up a topic on this so it doesn't get lost.

A handy proposition: the ability to define custom functions on Actor so all custom actors can use them. 'Nuff said.

A quick concrete use case for this: a monster mod that adds new gib sequences to existing monsters. Since they'll inherit from the originals, the only common ancestor you can define a custom "TossGibs" function on would be Actor itself.

This may end up being a larger part of the question of "(how) can we modify existing actors?", but I figure we can at least start with one of the simpler cases.

[Graf Zahl]

This is actually the easiest part. Non virtual functions can be added retroactively to an existing class, but that's pretty much all that can be added retroactively.

Redefining properties is something different entirely. It's surely doable but requires a very different mechanism. And of course, if any such mod is loaded, Dehacked needs to be blocked completely, there's no way around that or bad things can happen.

[Major Cooke]

Oooh, I thought you couldn't add functions currently to Actor.

[Graf Zahl]

You still can't. But that part is doable.

[Major Cooke]

I take it global variables are also out of the question?

I mainly ask because it'd be easier to have limiting spawning functions based on incrementing the global var by one on an actor's spawn and subtraction by one upon death. Much easier on the computing this way over having to iterate.

Or it'd be better in a struct of some kind that could be global but... Falls under the same circumstances.

[Nash]

Global variables would be useful for Strife/Hexen-like adventures with hub-based levels.

[Graf Zahl]

Global variables come with the problem that they need to be serialized and the system is not equipped for that. They need to be stored in a place where the serializer can reach them and at the moment that does not exist. The main issue here is that the management of global data in the game engine is rather messy.
We have the global level struct and we have the global pointers for sectors etc. Right now the only global game elements that got exported are the level and the players because they were needed somewhere.
Before going any further here, the global level data needs to be come a Level object that obeys the same rules as other objects, and once that exists, a Game object that encapsulates an entire game session. And once that exists, you can have your global variables.
I can outright tell you that this is a MAJOR job to refactor, but absolutely necessary to make the engine future proof. And before that isn't done there won't be any global variables.

[Graf Zahl]

Considering that this can be easily worked around with static functions in some structs I'd rather not make this change.

[Major Cooke]

I thought you said it would be more powerful to use a class? Or was that just for iterators in particular?

[Graf Zahl]

You only need a class when you want to use virtual functions. This here would be purely static.