ZScript Discussion
Moderator: GZDoom Developers
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.
Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
-
- Posts: 3060
- Joined: Thu May 03, 2012 1:18 pm
- Graphics Processor: nVidia with Vulkan support
- Location: Maryland, US
Re: ZScript Discussion
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.
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.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
ZZYZX wrote: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:And:
- 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)
Additionally: expose some basic canvas methods (draw string, draw texture, getting screen dimensions, etc)
- 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
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!
Last edited by Nash on Fri Jan 20, 2017 5:03 pm, edited 2 times in total.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
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.
I've written some event-based UI systems in game engines before, although those were from scratch and SDL-based mostly.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.ZZYZX wrote: P.S. Just reread your last post — how is status bar related to the menus??? Especially when you aren't in a map?
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.
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
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: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.
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);
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.
-
-
- Posts: 17934
- Joined: Fri Jul 06, 2007 3:22 pm
Re: ZScript Discussion
That BTIL thing must come from the [wiki=Classes:CustomSprite]CustomSprite[/wiki] thing.
-
- Posts: 22
- Joined: Sat Nov 03, 2012 2:41 pm
Re: ZScript Discussion
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?
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?
-
-
- Posts: 1384
- Joined: Sun Oct 14, 2012 1:43 am
- Location: Ukraine
Re: ZScript Discussion
Well it wasn't called properly anyway, as first argument to format should be the format string, not some mysterious name.Gez wrote:That BTIL thing must come from the [wiki=Classes:CustomSprite]CustomSprite[/wiki] thing.
-
-
- Posts: 17465
- Joined: Mon Oct 27, 2003 12:07 am
- Location: Kuala Lumpur, Malaysia
Re: ZScript Discussion
Notepad++: Say no more famThe Second wrote: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?
SLADE: Coming soon according to sirjuddington
List of keywords: Look inside gzdoom.pk3, it's all in the /zscript directory
-
- Posts: 598
- Joined: Sun Feb 24, 2013 4:07 pm
- Location: United Kingdom
Re: ZScript Discussion
Seconding this. For a mod of mine, I'm wanting to alter the hitscanning functions (A_PosAttack, A_SPosAttack, A_CPosAttack, etc).Ed the Bat wrote: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.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: ZScript Discussion
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.