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
Beed28
Posts: 598
Joined: Sun Feb 24, 2013 4:07 pm
Location: United Kingdom

Re: ZScript Discussion

Post by Beed28 »

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

...

The bad news is I don't know whether the method I did it with is "frowned" upon, so to speak.
Last edited by Beed28 on Sun Jan 22, 2017 3:56 pm, edited 2 times in total.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: ZScript Discussion

Post by Gez »

Well elaborate, then.
User avatar
Beed28
Posts: 598
Joined: Sun Feb 24, 2013 4:07 pm
Location: United Kingdom

Re: ZScript Discussion

Post by 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).
Attachments
zscript-hitscan_replacer.pk3
(1.87 KiB) Downloaded 97 times
User avatar
Jadwick
Posts: 5
Joined: Sat Dec 31, 2016 4:48 am

Re: ZScript Discussion

Post by 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.
Spoiler: Entire code
Last edited by Jadwick on Sun Jan 22, 2017 4:50 pm, edited 1 time in total.
dpJudas
 
 
Posts: 3037
Joined: Sat May 28, 2016 1:01 pm

Re: ZScript Discussion

Post by dpJudas »

Graf Zahl wrote: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.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: ZScript Discussion

Post by ZZYZX »

Eruanna wrote:"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.
Beed28 wrote: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.
Eruanna wrote: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.
Last edited by ZZYZX on Sun Jan 22, 2017 6:56 pm, edited 14 times in total.
User avatar
kodi
 
 
Posts: 1355
Joined: Mon May 06, 2013 8:02 am

Re: ZScript Discussion

Post by 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.
User avatar
Jadwick
Posts: 5
Joined: Sat Dec 31, 2016 4:48 am

Re: ZScript Discussion

Post by Jadwick »

kodi wrote:@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".
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Beed28 wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

dpJudas wrote: 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

ZZYZX wrote: 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!
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: ZScript Discussion

Post by ZZYZX »

Graf Zahl wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Every time people started replacing core stuff it broke their mods later. EVERY. SINGLE. TIME!
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: ZScript Discussion

Post by 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).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by 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!
Locked

Return to “Scripting”