ZScript Discussion

[Ed the Bat]

I need to spend some time taking advantage of those static functions. I can skip some inheritance that way.

One question I've had on my mind for a while, though... can ZScript let me alter existing functions to any extent? Like, if I could alter how A_Chase works, such that it will apply to every monster in the game, perhaps I could scrap this gargantuan set of custom actors that redefine their See states just so they'll move more smoothly. It feels like this will still be out of my reach, but then, ZScript has surprised me multiple times already with how powerful it is.

[Nash]

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.

I like the sound of that!

[ZZYZX]

Updated the post a bit, outlined how exactly it should work. Graf's opinion is welcome, I'm actually interested in coding that thing
I've written some event-based UI systems in game engines before, although those were from scratch and SDL-based mostly.

[Graf Zahl]

I don't think that such an event system is the way to go. Once I expose subsystems that can receive events they will be able to do so, but whatever gets done must integrate with the current order of things and not impose a completely different handling model on the engine. This can seriously backfire.

My roadmap stands: Now that actors are mostly exported I'll try to make some sense out of the status bar code, then the thinker system in general and after that the menu - and then we may talk again.
If someone has ideas about improving the actor system, pull requests are welcome - but jumping the gun on other parts of the engine is not on my agenda. This needs time and no rush job.

[ZZYZX]

Not on yours, which is why I proposed to work on this in parallel in separate repository with some distant possibility to merge in the future, like the portals.
Either way, how do YOU imagine being able to insert user code into the existing rendering pipeline, if not event handlers? And on integration — obviously the backend would integrate with the existing system, but with ZScript frontend looking different and a bit more user-friendly.

[Graf Zahl]

It makes no sense to work on an event system before I haven't laid out how things are to be. Should that stuff later in any way get in the way of other stuff I'd be screwed. Especially UI related stuff is completely out for the time being, as that directly interferes with the statusbar, which is basically the sole class to take care of UI.

[ZZYZX]

What on the map events though? I've offered a convenient way to globally! Postprocess third-party actors by your mod, adding healthbars or shadows or whatever else fancy features to already defined actors without modifying them, modifying their properties on spawn, thus effectively doing what was suggested multiple times — altering, or rather, extending, functionality of existing actors.
That's a suggestion on improving the actor system that you were talking about

If you'd read my post a bit better (or maybe you just haven't seen the latest revision? sorry for editing too much, click to make sure pls), you'd notice that I'm not only targeting the UI — although it's an important point — but also the playsim, much like ACS special script types like OPEN, etc, all done within the same ZScript event framework, the purpose of which is to eventually deprecate ACS for everything except what it was originally intended for: small three-line strictly map logic scripts like in Hexen.
It's an universal plugin system in a sense, with different plugin types being "event handlers".

Right now we have people still having to use Open scripts in order to make ZScript work. See above in this thread.

P.S. Just reread your last post — how is status bar related to the menus??? Especially when you aren't in a map?
Actually that doesn't even matter. What matters is whether there are any architectural ideas on how to have ZScript code replace the statusbar once it's done.
We'll need to somehow bind classes in ZScript to the UI layer, which is where the event system comes in
But yea, I can understand that it's not the exact time to think about it yet, just please don't outright throw it out of the window without consideration, as the concept IMO is very promising and easy to implement.

[Graf Zahl]

P.S. Just reread your last post — how is status bar related to the menus??? Especially when you aren't in a map?

Not at all. I never implied that. It's just that these are two systems that already use an object hiearachy so they are good candidates for scripting.


For your event stuff, if you can make a quick demo of what you imagine I might be able to tell you more about its feasibility.

[ZZYZX]

Okay, will try to make something up.
Also, currently changing format() to String.Format/String.AppendFormat + vararg and almost finished, but why I'm posting here is that you have in sharedmisc.txt this expression:

Code: Select all

format(name, "BTIL%04d", args[0] & 0xffff);

Without any assignment or logging or anything. Commented that, I guess that's debug leftovers.

The vararg keyword works this way: until ellipsis expression, the function arguments are parsed and typechecked/typecasted as any normal arguments.
After the ellipsis is encountered, the same rules as for FxFormat apply — ambiguous string-like stuff is casted to String, then forwarded unchanged.
Ellipsis without vararg will result in classic A_Jump behavior — that is, arguments will be still typechecked and typecasted against the last specified argument type.
Trying to use vararg without native causes compilation error, as you wanted. Although I personally would have also implemented accessors for variadic arguments for the modders.

[Gez]

That BTIL thing must come from the [wiki=Classes:CustomSprite]CustomSprite[/wiki] thing.

[The Second]

Hello,

I'm wondering if there is a Zscript language file available for Slade, notepad++ or other text/script editor. If not, is there a list of Zscript keywords and functions so I can write my own language file?

[ZZYZX]

That BTIL thing must come from the [wiki=Classes:CustomSprite]CustomSprite[/wiki] thing.

Well it wasn't called properly anyway, as first argument to format should be the format string, not some mysterious name.

[Nash]

Hello,

I'm wondering if there is a Zscript language file available for Slade, notepad++ or other text/script editor. If not, is there a list of Zscript keywords and functions so I can write my own language file?

Notepad++: Say no more fam

SLADE: Coming soon according to sirjuddington

List of keywords: Look inside gzdoom.pk3, it's all in the /zscript directory

[Beed28]

One question I've had on my mind for a while, though... can ZScript let me alter existing functions to any extent? Like, if I could alter how A_Chase works, such that it will apply to every monster in the game, perhaps I could scrap this gargantuan set of custom actors that redefine their See states just so they'll move more smoothly. It feels like this will still be out of my reach, but then, ZScript has surprised me multiple times already with how powerful it is.

Seconding this. For a mod of mine, I'm wanting to alter the hitscanning functions (A_PosAttack, A_SPosAttack, A_CPosAttack, etc).

[Graf Zahl]

No. Once a function is defined it cannot be changed. That would be far too dangerous because its injecting foreign code into existing classes without their knowledge.