DECORATE to ZScript Conversion questions

[Enjay]

Please excuse the generic title, but I am likely to have a few questions as I come across them.

I'm in the process of updating some DECORATE actors to ZScript.

The first stumbling block I have come across is this - random damage.

This DECORATE:

Code: Select all

Damage (random(2,5))

was applied o a missile actor.

RockstarRaccoon's ZScript converter ( viewtopic.php?t=60380 ) and my expectation was that this would work in ZScript in the actor's default block:

Code: Select all

Damage (random(2,5));

However, it's obviously wrong because GZDoom doesn't like it. I get an error message telling me: "damage: non-constant parameter"

I've looked in some other ZScript files and this seems as if it might be more complicated than just the syntax for a single line. So, can anyone tell me how to give a missile actor random damage?

[Kzer-Za]

Wiki says to use DamageFunction in ZScript instead of damage if you want a custom damage expression instead of a one-figure value (https://zdoom.org/wiki/Actor_properties#Damage).

[Graf Zahl]

It's called 'DamageFunction' in ZScript because the parser can't deal with it using the same name as the constant property

[phantombeta]

For future reference, we have a page on the wiki documenting most (or all) of the required changes when converting DECORATE to ZScript. I hope it helps with everything you need

[Enjay]

Well, that was straight forward enough, thank you.

And that Wiki page looks useful too.

So far, the random damage is the only thing that I haven't been able to figure out for myself. Weird, given how simple it was (and it's even on that Wiki page). I've managed to figure out quite a few other things.

I also spotted some unexpected results - like a smoke effect no longer sending smoke into the air, but just smouldering on the ground. I'd changed A_CustomMissile to A_SpawnProjectile to get rid of the deprecation warning, but this actor used the pitch parameter. So, once I realised what was going on, I had to go back and change quite a few special effects actors that were using +ve pitch values that needed to be changed to -ve ones. Still, it was only grunt work once I figured out the cause.

[Enjay]

OK, here's one that I just need an opinion on.

I have several actors that inherit from others. Some of these do not change the original actor's stats (i.e. the things that would end up in the default block in ZScript).
For example, it might be an actor that is identical to the original, but with an altered death sequence.
When such actors are run through the conversion tool, the tool adds a default block for them, but its empty. Effectively this:

Code: Select all

Default{}

The actors seem to work equally well with this empty default block in place, or with it removed entirely.
My fear was that having an empty default block might somehow nix the stats from the actor being inherited from, but that doesn't seem to be the case (which makes sense seeing as how these are additive in nature).

So, my question is, is there any harm in having an empty default block like this?
(I hope not, because the tool has created many of them, and it will be a pain to search through the files to find them all and remove them.)

[SanyaWaffles]

shouldn't cause any harm.

[Enjay]

Thank you. and phew!

[Enjay]

OK, so far so good. Lots of converting has been done. However, I have another question.

The problem is with this line of code:

Code: Select all

INCY E 0 ThrustThing (angle*256/360, 12, 0, 0);

Ii is used to make an enemy jump towards the player. However, GZDoom warns me that there is a truncation of floating point with it.
The line seems to be correct according to the Wiki (which may be out of date/only dealing with DECORATE). https://zdoom.org/wiki/ThrustThing

How do I change this so that I no longer get the warning?

Edit:
I couldn't figure out a way to fix the calculation (I even resorted to ChatGPT - which suggested lots of things that didn't work).
However, using Thrust instead of ThrustThing gives me behaviour that, as far as I can tell for this case, is basically the same. (It's certainly acceptable anyway.) There is no truncation problem when using Thrust because the calculation isn't necessary; I can just use 1e37 as the angle and the actor jumps in the direction it was facing - which is what I need.

However, I would still like to see a solution if possible to help me understand how to do this kind of thing.

[Player701]

The problem is with this line of code:

Code: Select all

INCY E 0 ThrustThing (angle*256/360, 12, 0, 0);

Ii is used to make an enemy jump towards the player. However, GZDoom warns me that there is a truncation of floating point with it.

This is because the first argument of ThrustThing is of type int (don't ask me why), and since angle is a double, the whole expression also evaluates to a double - and the engine thus rightfully warns you that precision might be lost because you are passing a floating-point value (which a double is) where an integral one is expected.

You can work around this by explicitly casting the result with the int(...) operator. This will make your intentions clear to the engine and remove the warning, but using Thrust is probably a better choice here since it supports floating-point arguments by design.

[Enjay]

Thank you.
I'd guessed that what was probably going on was that the value needed to be an int and, obviously, that calculation will produce values that are not ints. The thing that I didn't know how to do was to force the result to be an int. I tried all sorts of rounding tricks (that didn't work) but I never thought about just doing as you suggested.

However, as you said, Thrust doesn't have that problem, so I'll use that. But it's good to know what to do in other situations where there isn't an alternative command. So, thanks again.

[Enjay]

And a final question I think: I can't find what ZScript is currently versioned to. I think it might be 4.8.2, but I can't actually see it written down anywhere. The ZSCript file in gzdoom.pk3 is set to 4.12, but I know it's beyond that. Maybe that's a sort of "minimum value for the sake of compatibility"?

So, what is the current version of ZScript - and (as a bonus question) where is that information recorded for future reference?




Anyway, I think that's me done with the conversion. Thanks again to all who helped along the way. That's several thousand lines of DECORATE now converted to ZScript. Why? Because it's there.

A weird thing happened right when I thought I was finished though. While working on it, I was loading my ZScript files as loose files from a folder. I got to a point where GZDoom was starting cleanly with no errors and no warnings. However, when I incorporated my files into an actual PK3 along with all the resources that had previously been used by the DECORATE version of the scripts, I suddenly got hundreds of warnings about A_PlaySound being deprecated (which it clearly is, that's not the issue). I wasn't getting those warnings before consolidating all the files. My guess is that something somewhere had some versioning information or defaults that were not as high as those in the consolidated file.

Anyway, it flagged up to me that I needed to replace all the A_PlaySound entries with A_StartSound. Fortunately, in most cases, I had used A_PlaySound without many parameters so that I could do a "replace all" for most of them. However, if anything using A_Playsound had something after the SLOT parameter, I had to edit them manually because the parameters after SLOT don't map across 1:1 to A_StartSound. Compared to all the work I'd done, it wasn't that bad, but when I first saw all the deprecation warnings my heart sank because I thought I was done and I knew that fixing the hundreds of A_PlaySound entries would take another couple or more hours. So, anyway, that "incident" is what prompted the above question about versioning. I realised that I didn't actually know the current version number.


I do have to say that, although this process was a laborious one (I reckon about 36 hours of work in total), I have learned a lot more about ZScript, and I'm more confident with it (which was the main point). The heavier programming elements of it are still beyond me; I'm not a programmer. However, I can work with it and make sense of it much better than I could before.

I also really appreciate RockstarRaccoon's converter tool. It has all the shortcomings that RockstarRaccoon said it would: messing with formatting; randomly stopping working half way through a file; and a whole bunch of other quirks (most of which I got to the point of being able to predict which blocks of code would trigger), but it really took the donkey work out of the job. "All" I had to do was convert the files with the tool, then keep trying to run them with GZDoom until it started without any errors. Of course, with the amount of DECORATE I was converting, getting some of the individual files to work still took about 4-5 hours after the initial conversion.

And I also have to say that I really appreciate the robustness of GZDoom's error checking and the quality of the feedback it gives. It was easy for me to load up the files, get the error messages at the console, leave GZDoom sitting there, find the lines that GZDoom had highlighted as problematic in my files, edit them, press the restart button on GZDoom and just keep doing that over and over (and over and over) until GZDoom finally started. Then all I had to do was the clean up all the deprecation warnings as well (because they don't stop GZDoom from running). I thought I'd done that, which is why the A_Playsound warnings took me by surprise after I thought I was finished. Anyway, the error messages were always accurate and meaningful enough that I could find the right line, figure out the problems (hundreds, maybe thousands, of them over the last few days).

I also got an appreciation of the syntax and robustness of ZScript. Even to a relative layman, I could see that its structure is more rigid and well-defined than DECORATE, (even if a lot of the time for simple code the main difference is just a ; at the end of a line).

[phantombeta]

Most of the time, the ZScript version matches the GZDoom version number. Right now it's 4.14.0.

This is because the first argument of ThrustThing is of type int (don't ask me why)

ThrustThing is an (old) action special, so it basically has to be int
It also comes from Hexen itself, so it had to use byte angles, particularly to be used directly on lines in Hexen format maps.

[Player701]

It also comes from Hexen itself, so it had to use byte angles, particularly to be used directly on lines in Hexen format maps.

Haven't played Hexen in ages, but now I actually remember that special being used there in some levels (Hypostyle comes to mind as the most prominent one). Yeah, then it does make sense - working with floats was too expensive (CPU-wise) back in the day, I guess.

[Enjay]

OK, yes, that makes a lot of sense (the Hexen byte angle thing) thanks.