ZDoom

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.

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.

Major Cooke wrote:Graf, can you answer ZZYZX's and my questions please?

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;

return A_Jump(256, "Spawn2"); 

Also, does SetUserVariable (ACS) works on variables in ZScript ?

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.

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.

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.