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.

Re: ZScript Discussion

Postby Beed28 » Sun Jan 22, 2017 3:44 pm

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.
User avatar
Beed28
Making entire worlds bounce up and down.
 
Joined: 24 Feb 2013
Location: United Kingdom

Re: ZScript Discussion

Postby Gez » Sun Jan 22, 2017 3:51 pm

Well elaborate, then.
Gez
 
 
 
Joined: 06 Jul 2007

Re: ZScript Discussion

Postby Beed28 » Sun Jan 22, 2017 3:56 pm

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).
You do not have the required permissions to view the files attached to this post.
User avatar
Beed28
Making entire worlds bounce up and down.
 
Joined: 24 Feb 2013
Location: United Kingdom

Re: ZScript Discussion

Postby Jadwick » Sun Jan 22, 2017 4:30 pm

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.
User avatar
Jadwick
 
Joined: 31 Dec 2016

Re: ZScript Discussion

Postby dpJudas » Sun Jan 22, 2017 4:39 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZScript Discussion

Postby ZZYZX » Sun Jan 22, 2017 5:01 pm

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 retarded 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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: ZScript Discussion

Postby kodi » Sun Jan 22, 2017 5:02 pm

@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
kodi
Proscrastinator
 
 
 
Joined: 06 May 2013

Re: ZScript Discussion

Postby Jadwick » Sun Jan 22, 2017 5:17 pm

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
Jadwick
 
Joined: 31 Dec 2016

Re: ZScript Discussion

Postby Graf Zahl » Sun Jan 22, 2017 5:19 pm

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
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Graf Zahl » Sun Jan 22, 2017 5:22 pm

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
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby Graf Zahl » Sun Jan 22, 2017 5:24 pm

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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby ZZYZX » Sun Jan 22, 2017 5:27 pm

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 allExpand view
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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: ZScript Discussion

Postby Graf Zahl » Sun Jan 22, 2017 5:39 pm

Every time people started replacing core stuff it broke their mods later. EVERY. SINGLE. TIME!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZScript Discussion

Postby ZZYZX » Sun Jan 22, 2017 5:44 pm

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: ZScript Discussion

Postby Graf Zahl » Sun Jan 22, 2017 5:47 pm

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!
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Scripting

Who is online

Users browsing this forum: KaptainMicila and 0 guests