ZScript Discussion

[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).

[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.

[Major Cooke]

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.

[ZZYZX]

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.

[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.

[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.

[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 ?

[Major Cooke]

Graf, can you answer ZZYZX's and my questions please?

[wildweasel]

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.

[Graf Zahl]

I have a bigger problem to solve right now and no time to look into this stuff.

[Blue Shadow]

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.

[Major Cooke]

So it's not lost to time, I've posted it on mantis.

[Graf Zahl]

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?

[Major Cooke]

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.

[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.

• 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.