ZScript Discussion

[Beed28]

Hah! I managed to edit the Doom monster hitscanning functions! Without even editing "gzdoom.pk3"! And it even works with DeHackEd monsters!

...

The bad news is I don't know whether the method I did it with is "frowned" upon, so to speak.

[Gez]

Well elaborate, then.

[Beed28]

Here's a demo file that has the Doom hitscan monsters now throwing imp fireballs if anyone wants to see, but I fear the method I used might end up being phased out...

Try it out with a few DeHackEd monsters that used the hitscan functions as well (the MAP29 boss in gd.wad is a good place to start, as she uses a hitscan attack).

[Jadwick]

How do you get a weapon to change state in an action function?

I'm trying to make custom bobbing animations, but the state doesn't seem to change.

I have a function defined in my custom weapon class and call it every frame before A_WeaponReady to see if the player is moving, and it's supposed to change the weapon's state either to the still animation or the bobbing one, but the state never changes. Even when I remove all the code except invoker.SetStateLabel. invoker.ResolveState doesn't work either.

---

Code: Select all

Class MD3Pistol : Pistol
{
	Default
	{
		Obituary "$OB_MPPISTOL";
		+WEAPON.DONTBOB
		Inventory.Pickupmessage "$PICKUP_PISTOL_DROPPED";
		Tag "$TAG_PISTOL";
	}
	States
	{
		Ready:
			1WPA U 1 A_WeaponReady();
			1WPA U 0 CheckSway2();
			Loop;
		Deselect:
			1WPA V 1 SetPlayerProperty(0, 1, 2);
			1WPA WXYZ 1;
			1WPB ABCD 1;
			1WPB E 1 A_Lower();
			Loop;
		Select:
			1WPA A 1 SetPlayerProperty(0, 1, 2);
			1WPA BCDEFGHIJKLMNOPQRS 1;
			1WPA T 1 A_Raise();
			Loop;
		Fire:
			1WPB HI 1;
			1WPB J 1 A_FirePistol();
			1WPB KLMNOPQR 1;
			Goto Ready;
		Sway:
			1WPC C 1 A_WeaponReady();
			1WPC D 0 CheckSway();
			1WPC D 1 A_WeaponReady();
			1WPC E 0 CheckSway();
			1WPC E 1 A_WeaponReady();
			1WPC F 0 CheckSway();
			1WPC F 1 A_WeaponReady();
			1WPC G 0 CheckSway();
			1WPC G 1 A_WeaponReady();
			1WPC H 0 CheckSway();
			1WPC H 1 A_WeaponReady();
			1WPC I 0 CheckSway();
			1WPC I 1 A_WeaponReady();
			1WPC J 0 CheckSway();
			1WPC J 1 A_WeaponReady();
			1WPC K 0 CheckSway();
			1WPC K 1 A_WeaponReady();
			1WPC L 0 CheckSway();
			1WPC L 1 A_WeaponReady();
			1WPC M 0 CheckSway();
			1WPC M 1 A_WeaponReady();
			1WPC L 0 CheckSway();
			1WPC L 1 A_WeaponReady();
			1WPC K 0 CheckSway();
			1WPC K 1 A_WeaponReady();
			1WPC J 0 CheckSway();
			1WPC J 1 A_WeaponReady();
			1WPC I 0 CheckSway();
			1WPC I 1 A_WeaponReady();
			1WPC H 0 CheckSway();
			1WPC H 1 A_WeaponReady();
			1WPC G 0 CheckSway();
			1WPC G 1 A_WeaponReady();
			1WPC F 0 CheckSway();
			1WPC F 1 A_WeaponReady();
			1WPC E 0 CheckSway();
			1WPC E 1 A_WeaponReady();
			1WPC D 0 CheckSway();
			1WPC D 1 A_WeaponReady();
			1WPC C 0 CheckSway();
			1WPC C 1 A_WeaponReady();
			1WPC B 0 CheckSway();
			1WPC B 1 A_WeaponReady();
			1WPC A 0 CheckSway();
			1WPC A 1 A_WeaponReady();
			1WPB Z 0 CheckSway();
			1WPB Z 1 A_WeaponReady();
			1WPB Y 0 CheckSway();
			1WPB Y 1 A_WeaponReady();
			1WPB X 0 CheckSway();
			1WPB X 1 A_WeaponReady();
			1WPB W 0 CheckSway();
			1WPB W 1 A_WeaponReady();
			1WPB V 0 CheckSway();
			1WPB V 1 A_WeaponReady();
			1WPB U 0 CheckSway();
			1WPB U 1 A_WeaponReady();
			1WPB T 0 CheckSway();
			1WPB T 1 A_WeaponReady();
			1WPB S 0 CheckSway();
			1WPB S 1 A_WeaponReady();
			1WPB T 0 CheckSway();
			1WPB T 1 A_WeaponReady();
			1WPB U 0 CheckSway();
			1WPB U 1 A_WeaponReady();
			1WPB V 0 CheckSway();
			1WPB V 1 A_WeaponReady();
			1WPB W 0 CheckSway();
			1WPB W 1 A_WeaponReady();
			1WPB X 0 CheckSway();
			1WPB X 1 A_WeaponReady();
			1WPB Y 0 CheckSway();
			1WPB Y 1 A_WeaponReady();
			1WPB Z 0 CheckSway();
			1WPB Z 1 A_WeaponReady();
			1WPC A 0 CheckSway();
			1WPC A 1 A_WeaponReady();
			1WPC B 0 CheckSway();
			1WPC B 1 A_WeaponReady();
			Loop;
			
	}
	
	action void CheckSway()
	{
		let onr = invoker.owner;
		if(onr)
		{
			Vector3 ownerVel = onr.vel;
			if(ownerVel.x == 0 || ownerVel.y == 0)
			{
				invoker.SetStateLabel("Ready");
			}
		}
	}
	action void CheckSway2()
	{
		invoker.SetStateLabel("Sway");
		/*let onr = invoker.owner;
		if(onr)
		{
			Vector3 ownerVel = onr.vel;
			if(ownerVel.x != 0 || ownerVel.y != 0)
			{
				invoker.SetStateLabel("Sway");
			}
		}*/
	}
}

[dpJudas]

In the end, what' preventing us from combining different approaches: Static mesh for the main parts of the map and some hybrid approach for portals where the static way won't work? The main view is the most important one anyway so if that can be sped up, it may even be fine to render the portals with a traditional BSP - and even there a lot depends on the portal's shape. A line portal can be handled with a simple hardware clip plane and for sector portals some analysis is necessary to decide how to do it - but that's normally a one-time operation when the map starts.

I can't see any reason why a hybrid method wouldn't work. In fact, I think maybe one way of drawing the scene could be to still do the traditional BSP, but then it just skips render (only updates the clipper) for the parts it renders from the static mesh. So the current BSP walking code would draw the dynamic parts. The static parts are then drawn afterwards (or before - not sure which is best). In such an approach the portals could just be considered to not ever be in the static mesh.

[ZZYZX]

"No" from any dev - be it dpJudas, Graf, myself, ZZYZX, or anyone else - simply means "do it (and maintain it) yourself if you want it that badly."

(note: edited)
You know, what you are saying here is similar to "when you have problem with people, just beat them up, God gave you arms and even legs for that". Civilized argument is a way to do things.
In case I make a fork — yes, it will solve my problem for now (just like kicking that [censored word] neighbour to the kidneys), but then I'll face the consequences later (either with cops or neighbour )
And in case you didn't notice, I did not go with pointless arguments all over — once I saw that there actually is a renderer implementation (even two) that will break, I'm completely (well, not so, but whatever) ok with not including renderer-internal stuff. I like to believe that I actually know when to stop in a discussion before it eventually changes to name-calling and pointless fecal throwing, and I don't have any mods that need this functionality so I'm not biased that way.
As in the case of Graf — I'd like to work with him, not against him, because the latter contributes nothing to the Doom modding and GZDoom itself. But it doesn't mean that I'll blindly accept any unrealistic (from my POV) statement until it's a bit elaborated.

Here's a demo file that has the Doom hitscan monsters now throwing imp fireballs if anyone wants to see, but I fear the method I used might end up being phased out...

Try it out with a few DeHackEd monsters that used the hitscan functions as well (the MAP29 boss in gd.wad is a good place to start, as she uses a hitscan attack).

As for this, people are already using the same approach to replace shaders (oh wait, one of these is you! hi) and no one phased that out yet.

And to make it clear: I am 100% against any renderer code touching playsim code whatsoever. All by itself this will break Zandronum compatibility right out the gate because it does run as a headless server no matter what renderer it is configured for. And I've already mentioned breaking demos and multiplayer - even in the sorry state that they are in now I see no reason to break them further. Please don't.

Problem is that we view modders differently. I expect them to NOT touch playsim when they use the renderer hooks. At most — NOINTERACTION actors or visual sprite changes. This should not affect Zandronum at all.
Zandronum modders do that already: they have +SERVERSIDEONLY and +CLIENTSIDEONLY actors, as well as CLIENTSIDE ACS scripts, which already have to not touch the playsim otherwise it will desync and Zandronum will not resolve that automagically.
But every time I say about somehow making playsim undeterministic, you always see the worst possible outcome IMO.

[kodi]

@jadwick
It's much easier to use an invisible Overlay state that calls A_WeaponOffset (or A_OverlayOffset) in a loop with whatever sway equation you wish to have. Start this overlay by calling A_Overlay once in/after the select state. Clear the overlay at the start of the Fire state and restart it after if you don't want swaying while firing.

[Jadwick]

@jadwick
It's much easier to use an invisible Overlay state that calls A_WeaponOffset (or A_OverlayOffset) in a loop with whatever sway equation you wish to have. Start this overlay by calling A_Overlay once in/after the select state. Clear the overlay at the start of the Fire state and restart it after if you don't want swaying while firing.

I'm using 3D models, which I've modeled a custom bobbing animation for, so for each frame of animation I need to draw a new "sprite".

[Graf Zahl]

Here's a demo file that has the Doom hitscan monsters now throwing imp fireballs if anyone wants to see, but I fear the method I used might end up being phased out...

Try it out with a few DeHackEd monsters that used the hitscan functions as well (the MAP29 boss in gd.wad is a good place to start, as she uses a hitscan attack).

That really worked? Actually that's very, very dangerous. Mods have broken in the past trying to replace internal lumps like that and for most there is a check to prevent that. Seems for ZScript I either forgot or it isn't working.

[Graf Zahl]

I can't see any reason why a hybrid method wouldn't work. In fact, I think maybe one way of drawing the scene could be to still do the traditional BSP, but then it just skips render (only updates the clipper) for the parts it renders from the static mesh. So the current BSP walking code would draw the dynamic parts. The static parts are then drawn afterwards (or before - not sure which is best). In such an approach the portals could just be considered to not ever be in the static mesh.

After is better, because if you split the static mesh you can omit the parts that have no parts visible. But the main attraction with a static mesh would be to save the clipper time, which is a large chunk for maps like Frozen Time.

[Graf Zahl]

As for this, people are already using the same approach to replace shaders (oh wait, one of these is you! hi) and no one phased that out yet.

Goddamnit! Forget one sanity check and it gets abused. Here's the problem: Once I implement a Vulkan renderer that shader stuff will break for sure. It will also break if new shader based features get added. In clear English: DON'T DO THAT! - EVER!

[ZZYZX]

Goddamnit! Forget one sanity check and it gets abused. Here's the problem: Once I implement a Vulkan renderer that shader stuff will break for sure. It will also break if new shader based features get added. In clear English: DON'T DO THAT! - EVER!

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]

Every time people started replacing core stuff it broke their mods later. EVERY. SINGLE. TIME!

[ZZYZX]

Well to be fair they generally say "use (G)ZDoom x.y.z". And even now there are still a lot of mods that provide their own version of ZDoom (sometimes based on 1.x, sometimes 2.x).

[Graf Zahl]

Like I said: Some people never learn. For providing an old EXE with a mod the same applies as for replacing core lumps: Eventually it breaks and goodbye, mod!