ZScript Discussion

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

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!)
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Btw I'm sorry, but I still didn't get a response on non-renderer events. Do I try to implement them, or is it a no, or is it a not now? Should I finish this system at all (I mean if I remove the offending stuff)?
(by finishing I mean the state where there is some basic framework with one render event (before frame rendered) and mapload/mapunload, and where serialization works AS EXPECTED).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47985
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

What are your plans there? An event system in itself is not a 'no' by default, of course it depends on which kinds of events you want to send.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

ZZYZX wrote: In clear English: MAKE LEGIT SHADER REPLACEMENT IN GLDEFS! (or at least allow it to be made, more pull requests to the god of pull requests) (sorry for yelling, directly copied your post)
Every time you'd say "you can't change the existing stuff by scripting!" people will find a way with hacks. They want total conversions :)

As for the replacement shader, for example:

Code: Select all

replacementshader "name" { ... }
Then ACS or ZScript SetReplacementShader() from Screen static class. And it won't break with Vulkan any more than another user shader from GLDEFS would.
Was this accounted for? Doesn't look like it.
User avatar
ZZYZX
 
 
Posts: 1379
Joined: Sun Oct 14, 2012 1:43 am
Discord: ZZYZX#1394
Github ID: jewalky
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Graf Zahl wrote:What are your plans there? An event system in itself is not a 'no' by default, of course it depends on which kinds of events you want to send.
  • For now — finish the basic framework and make sure serialization works as specified in my first post about it.
  • Then rename Map* to World* and make a dedicated handler type.
  • Then add playsim events (analogous to all ACS script types, possibly a bit different, for example WorldLoaded should be called every time map is actually loaded, and not when changing from previous level, same with WorldUnloading, so that when you type "map mapxx" it fires as well; and add some way to verify where we came from and if this is a hub, etc as WorldEventHandler fields).
  • Afterwards — more playsim events (WorldActorSpawned/WorldActorDestroyed being one example, not sure what else). This is to preprocess actors with your mod, say, add shadows or health bars to monsters dynamically.
  • Afterwards — try to do something with d_events.h to forward these to ZScript using my interface, and add fake "UI paint" event that's executed before or after the menus/HUD.
    (to be discussed: for example there can be multiple events for different UI stages, or if all UI is going to be zscriptified there will have to be some sorting mechanism to ensure that some handlers fire before others, so that console is always on top for example, then menus, then statusbar, then everything else).
    Possible way:

    Code: Select all

    virtual int GetUiLayer() { return 1; }
    Where UI layer is a number that defines when your handler is called relatively to the other ones, like CSS z-index property, and then also add something like bool EventProcessed to tell the system that lower UI handlers should not get the event.
    You will have to do this part either way, and event system is the best way I think, since it allows multiple mods to stack their stuff with each other naturally.
  • Into the last part in the future you will be able to put your menus and statusbar code, too, using GameInfo-defined static event handler.
    With each menu being own event handler subclassing class ZDoomMenu, and when you want to change current menu to some other one you can do Unregister(self) -> Register(somethingelse).
    Not sure how exactly the current menu system works, I think it's flat and only has the concept of currently active menu.
So: EventHandler -> RenderEventHandler, WorldEventHandler, PlayerEventHandler, UiEventHandler. Plus their Static counterparts.
User avatar
Ed the Bat
Posts: 3060
Joined: Thu May 03, 2012 1:18 pm
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support
Location: Maryland, US

Re: ZScript Discussion

Post by Ed the Bat »

The DetermineType() function in DeHackEdPickup seems like it could be useful to me in automatically identifying what item is being replaced. However, I notice it is not only native, but private. I would ask if consideration could be given to lifting that restriction, but I imagine it's there for a reason.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47985
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

That function looks up the sprite name and matches it to the original Doom item type owning that sprite. Its sole purpose is to emulate pickup type determination by sprite like Doom originally did. It is entirely useless outside Dehacked.
User avatar
krokots
Posts: 241
Joined: Tue Jan 19, 2010 5:07 pm

Re: ZScript Discussion

Post by krokots »

OK, I'm new to ZScript, but I got stuck on something incredibely easy.
Using gzdoom 2.3.2
Why this works:

Code: Select all

		Spawn: 
		PROP A 10;
		TNT1 A 1 A_Jump(256,"Spawn2");
		Loop;
And this doesn't:

Code: Select all

		Spawn: 
		PROP A 10;
		TNT1 A 1 
		{
		A_Jump(256,"Spawn2");
		}
		Loop;
Also, does SetUserVariable (ACS) works on variables in ZScript ?
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

Graf, can you answer ZZYZX's and my questions please?
User avatar
wildweasel
Moderator Team Lead
Posts: 21374
Joined: Tue Jul 15, 2003 7:33 pm

Re: ZScript Discussion

Post by wildweasel »

Major Cooke wrote:Graf, can you answer ZZYZX's and my questions please?
I'd recommend patience or a different approach. Things get lost in the shuffle, and Graf might just be too busy to write up a response at the moment.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47985
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

I have a bigger problem to solve right now and no time to look into this stuff.
User avatar
Blue Shadow
Posts: 4903
Joined: Sun Nov 14, 2010 12:59 am
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: ATI/AMD (Modern GZDoom)

Re: ZScript Discussion

Post by Blue Shadow »

krokots wrote:OK, I'm new to ZScript, but I got stuck on something incredibely easy.
Using gzdoom 2.3.2
Why this works:

Code: Select all

		Spawn: 
		PROP A 10;
		TNT1 A 1 A_Jump(256,"Spawn2");
		Loop;
And this doesn't:

Code: Select all

		Spawn: 
		PROP A 10;
		TNT1 A 1 
		{
		A_Jump(256,"Spawn2");
		}
		Loop;
Put a return before the A_Jump call:

Code: Select all

return A_Jump(256, "Spawn2"); 
See [wiki]anonymous functions[/wiki] for more info.
Also, does SetUserVariable (ACS) works on variables in ZScript ?
Yes.
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

So it's not lost to time, I've posted it on mantis.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47985
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Major Cooke wrote:
ZZYZX wrote: In clear English: MAKE LEGIT SHADER REPLACEMENT IN GLDEFS! (or at least allow it to be made, more pull requests to the god of pull requests) (sorry for yelling, directly copied your post)
Every time you'd say "you can't change the existing stuff by scripting!" people will find a way with hacks. They want total conversions :)

As for the replacement shader, for example:

Code: Select all

replacementshader "name" { ... }
Then ACS or ZScript SetReplacementShader() from Screen static class. And it won't break with Vulkan any more than another user shader from GLDEFS would.
Was this accounted for? Doesn't look like it.

This is just as unclear as your request on Mantis. If you don't provide more specifics I can not give you some pointers about the problem. What do you want replaced?
User avatar
Major Cooke
Posts: 8059
Joined: Sun Jan 28, 2007 3:55 pm

Re: ZScript Discussion

Post by Major Cooke »

ZZYZX from Mantis wrote:Incorrect wording, not replacement, but adding a global postprocess thing to the existing pipeline, the same way as current user shaders work (just not binding to a particular texture name).
Normal GZDoom stuff should still fire without any way to change it.
Last edited by Major Cooke on Mon Jan 23, 2017 12:16 pm, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47985
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

ZZYZX wrote:
Graf Zahl wrote:What are your plans there? An event system in itself is not a 'no' by default, of course it depends on which kinds of events you want to send.
  • For now — finish the basic framework and make sure serialization works as specified in my first post about it.
  • Then rename Map* to World* and make a dedicated handler type.
  • Then add playsim events (analogous to all ACS script types, possibly a bit different, for example WorldLoaded should be called every time map is actually loaded, and not when changing from previous level, same with WorldUnloading, so that when you type "map mapxx" it fires as well; and add some way to verify where we came from and if this is a hub, etc as WorldEventHandler fields).
  • Afterwards — more playsim events (WorldActorSpawned/WorldActorDestroyed being one example, not sure what else). This is to preprocess actors with your mod, say, add shadows or health bars to monsters dynamically.
  • Afterwards — try to do something with d_events.h to forward these to ZScript using my interface, and add fake "UI paint" event that's executed before or after the menus/HUD.
    (to be discussed: for example there can be multiple events for different UI stages, or if all UI is going to be zscriptified there will have to be some sorting mechanism to ensure that some handlers fire before others, so that console is always on top for example, then menus, then statusbar, then everything else).
    Possible way:

    Code: Select all

    virtual int GetUiLayer() { return 1; }
    Where UI layer is a number that defines when your handler is called relatively to the other ones, like CSS z-index property, and then also add something like bool EventProcessed to tell the system that lower UI handlers should not get the event.
    You will have to do this part either way, and event system is the best way I think, since it allows multiple mods to stack their stuff with each other naturally.
  • Into the last part in the future you will be able to put your menus and statusbar code, too, using GameInfo-defined static event handler.
    With each menu being own event handler subclassing class ZDoomMenu, and when you want to change current menu to some other one you can do Unregister(self) -> Register(somethingelse).
    Not sure how exactly the current menu system works, I think it's flat and only has the concept of currently active menu.
So: EventHandler -> RenderEventHandler, WorldEventHandler, PlayerEventHandler, UiEventHandler. Plus their Static counterparts.

Most of this sounds reasonable, I'm not sure about doing the menus this way, it'd be changing a working system to something different.

Return to “Scripting”