ZScript Discussion

[Agentbromsnor]

However, I suggest you drag TheZombieKiller in here to post his even more recently revised one as that one takes care of some further issues which mine had.

Already available here

Right here, Agent.

What should I be looking for there? Sorry, but I haven't followed any of the discussion up till now, so I don't have any idea about the context of what tackles this issue.

[Xaser]

Just a quick tangent here. I haven't delved into ZScript for my own projects yet so I'm curious: What can't ZScript do? My project is still very small code-wise, but has a decent chunck of ACS I'd like to refactor into the ZScript equivalent if possible, but I don't want to start yet if I'm just gonna run into some roadblock.

One important thing that's not yet in is the ability to add new functions to the root Actor definition. This meant it's not possible to create a common function for actors that don't inherit from a custom class (e.g. if you're modifying Doom's monsters by extending them rather than defining monsters from scratch ones). If you can get away with inheriting from a common class for whatever you're doing, though, you're all set.

[This is the part where Gez pops in and brings up the desire to modify existing actors in-place (e.g. ammo) without resorting to DEHACKED. Yes, I'd love that too, but that's opening an oil drum of worms. ;]


FWIW, I don't think this should discourage you in starting the conversion anyway. I've done so myself even though there's a few ACS-ish bits (UI mostly) hanging around. It's a much better base to build on, for sure.

[Major Cooke]

UI

Soon.

networking

Never.

What should I be looking for there? Sorry, but I haven't followed any of the discussion up till now, so I don't have any idea about the context of what tackles this issue.

base_player.zs, function UpdateLegsAndBody, line 61. This code smooths player movements and compensates for whenever the player tries to move into an unreachable place.

[Graf Zahl]

What can't ZScript do?

UI, networking

UI will eventually be doable. Networking of course not, it's too low level.

[Graf Zahl]

One important thing that's not yet in is the ability to add new functions to the root Actor definition. This meant it's not possible to create a common function for actors that don't inherit from a custom class (e.g. if you're modifying Doom's monsters by extending them rather than defining monsters from scratch ones). If you can get away with inheriting from a common class for whatever you're doing, though, you're all set.

You can already do that by using static functions. It may not be as nice but it's certainly doable.

[This is the part where Gez pops in and brings up the desire to modify existing actors in-place (e.g. ammo) without resorting to DEHACKED. Yes, I'd love that too, but that's opening an oil drum of worms. ;]

And I won't open that can of worms. I think what makes a lot more sense is to expose the Dehacked editing capabilities for ammo and weapons to some other control lump - but absolutely NOT to the part that DEFINES the actors.

[Major Cooke]

Static functions? Could we get a quick example of that in zscript?

[ZZYZX]

Code: Select all

class A
{
  static void DoSmth()
  {
  }
}

Code: Select all

A.DoSmth();

This is how you call BlockThingsIterator.Create(). Look at the definition of that in the ZScript files.
If you need to provide the self pointer, you will have to do so manually with Actor parameter to the function.

[Graf Zahl]

Better like this, so that it can do something with the calling actor:

Code: Select all

class A
{
  static void DoSmth(Actor me)
  {
      me.A_PlaySound("loudnoise");
     me.A_SpawnProjectile("fireball");
  }
}

Code: Select all

A.DoSmth();

[/quote]

[Major Cooke]

So then I can just call A.DoSmth(self); from any other class without inheriting from A? Will I need to declare A in the actors I wish to call them?

Also what about returning?

[Graf Zahl]

Static functions can be called from everywhere, unless they are declared protected or private.
And they can return just like any other function, the only difference is that they do not have a hidden 'self' pointer.

[ZZYZX]

By the way apparently you can call a static method parameter 'self' instead of 'me' so that you can easily copy code around.

[Major Cooke]

Static functions can be called from everywhere, unless they are declared protected or private.
And they can return just like any other function, the only difference is that they do not have a hidden 'self' pointer.

Ah right, I see now. So in a way this is almost no different from a struct being declared and used.
But out of curiosity, what would be better to use for global functions, structs or classes with static functionality? So far it appears both methods are the same, but structs are more 'stick to the declared actors' and as a result use less memory...?

By the way apparently you can call a static method parameter 'self' instead of 'me' so that you can easily copy code around.

I have my suspicions...

[Gez]

And I won't open that can of worms. I think what makes a lot more sense is to expose the Dehacked editing capabilities for ammo and weapons to some other control lump - but absolutely NOT to the part that DEFINES the actors.

All I'm asking for is the ability to do what dehacked can do for actor properties. I'm not even asking about changing states, here, just the properties. I don't care about whether it propagates or not to inheritors (what would make sense to me is that it doesn't propagate to stuff that inherited during a previous compilation unit, and would propagate in stuff that inherits in a later unit -- coincidentally it's the approach that requires the least amount of work).

I'll point out that Eternity's EDF can do that with its thingdelta. i'm not even asking about the framedelta and others here, just thingdelta. It's nothing that is desperately needed.

With DECORATE or ZScript, if you want to change the max ammo of the Hexen mana, you'll have to replace the mana, which will mean replace the weapons, which will mean replace the classes, and also replace the HUD, and disable the old mana from the alt HUD, so you end up getting encumbered by a ton of MAPINFO, SBARINFO, ALTHUDCF and redundant DECORATE/ZScript code. It's ridiculous is what it is.

And it's dumb that if you load a mod that gives cacodemons blue blood and a mod that gives cacodemons health bonus drop items, they won't work together, when each of them is simply a modification of an actor property. That's the stuff that shouldn't need complete actor replacement. Would be so much better if they could simply update properties of the same actor, magically working together as a result of not having to use replacements.

[Xaser]

static functions

Well, well! That will do nicely -- can't believe I missed that!

re:"thingdelta"-equivalent; given some explicit syntax (i'd propose "extend class A" if it wasn't already taken) and limiting it to JUST properties, would this really be that problematic in practice? Gez's order of propagation makes sense in my head, and the big lingering danger would be having Mod A unintentionally overwrite something essential from Mod B... but we already have of that problem with "replaces" (try loading ARGENT with a mod that modifies monsters; surprise! Chaingun and Gauss aren't dropped by the bosses anymore). Curious to know what other problems are extant since I've only got limited insight to the big picture.

[ZZYZX]

ZScript will eventually need to have a way to hook various engine events (for doing manual rendering of the UI for example — for which Tick is not enough, but per-frame precision is needed, as well as manual interpolation in thinkers, if any).
Example — UIEventHandler, that receives mouse input, keyboard input and canvas paint event, allowing it to draw stuff on the screen.
So:

• EventHandler -> (UIEventHandler, WorldEventHandler, PlayerEventHandler)
• EventHandler.Register(handler) // since event handlers are required to derive from either of the system handlers, type argument is not needed
• EventHandler.Unregister(handler)
• MAPINFO/GameInfo definition for specifying default handlers that are automatically loaded (for zscriptifying SBARINFO later for example, also for ZScript functioning outside of the map, i.e. in menus)

And:

• WorldEventHandler: OnMapLoaded, OnMapUnloading, OnActorSpawned, OnActorDestroyed, OnLineAction
• PlayerEventHandler: OnPlayerJoined, OnPlayerLeft, [OnPlayerSpectated]
• UIEventHandler: OnPaint (called every RENDER frame), OnKeyDown, OnKeyUp, OnMouseMove (absolute X/Y coords, mouse in menus), OnMouseDelta (relative X/Y delta, ingame), OnMouseDown, OnMouseUp, OnMouseScroll

Additionally: expose some basic canvas methods (draw string, draw texture, getting screen dimensions, etc)
For each handler these are the virtual methods, whatever methods are overridden are executed for every event. There might be needed some way to block further propagation of the event, but that's something to do after it's been implemented IMO.

Graf, what do you think about this scheme? I might try to implement it if it's ok.