is automatic decorate to zscript conversion possible?

[bimshwel]

the game supposedly converts decorate to zscript internally when starting up. is there a way to export that converted data? my decorate definition goes back to, if not day 1, definitely the single digits, and there is quite a heap of stuff in there, and I often struggle with getting syntax correct. This is not an urgent matter, but it seemed worth asking about. thank you and good luck.

[phantombeta]

It's not possible, no, at least not through GZDoom itself. It doesn't convert DECORATE to ZScript, they just both get converted down to the same data structures.

[bimshwel]

on this page, https://zdoom.org/wiki/Classes:HellKnight, for example, above the decorate version, is stated
"Note: This is legacy code, kept here for reference only. DECORATE is still supported but no longer used by GZDoom. GZDoom internally uses the ZScript definition above."
How can that be true If zscript also needs to be converted?

[phantombeta]

on this page, https://zdoom.org/wiki/Classes:HellKnight, for example, above the decorate version, is stated
"Note: This is legacy code, kept here for reference only. DECORATE is still supported but no longer used by GZDoom. GZDoom internally uses the ZScript definition above."
How can that be true If zscript also needs to be converted?

All code needs to be converted down to something internally before being used/run. In ZScript's case, it first gets converted into abstract syntax tree nodes by the ZScript parser, which then get converted into intermediary nodes by the ZScript frontend, and then those intermediary nodes get compiled to ZScript VM bytecode by the compiler backend, that backend being the part DECORATE and ZScript share. These intermediary nodes lack any nuance about the code you wrote- Constants have already been replaced with their values, any maths that can be calculated before running the code already has been, variable names in functions are likely already lost, and so on.

[Magdiel012]

on this page, https://zdoom.org/wiki/Classes:HellKnight, for example, above the decorate version, is stated
"Note: This is legacy code, kept here for reference only. DECORATE is still supported but no longer used by GZDoom. GZDoom internally uses the ZScript definition above."
How can that be true If zscript also needs to be converted?

"Internally" here means in the gzdoom.pk3 that comes bundled with GZDoom that has all of the core ZScript definitions. There are definitions for pretty much every Doom/II/Heretic/etc. actor, all written manually.

[Gez]

It's theoretically possible to convert DECORATE to ZScript automatically, I mean there have been Pascal-to-C translators decades ago and the differences between both languages are much larger; but I'm not aware of anyone having done that.

However, note that as written on the wiki, there's no need to convert DECORATE to ZScript when you don't need to.

DECORATE and ZScript can be used simultaneously. There is therefore no need to convert a DECORATE actor to ZScript if you do not intend to use this opportunity to enhance its code with ZScript-specific features. Converting the code from a large project need therefore only be done when it is important, while the more trivial code can remain untouched. Note that while DECORATE actors can inherit from ZScript actors, the reverse is not true; therefore if an actor is converted, any of its parent classes must also be converted; however its children classes can be left alone.

[bimshwel]

That is good to know! I got the impression that there was something inferior and inefficient about still having decorate definitions.
It can be annoying having to keep my older stuff separate from newer stuff that is zscript only, but I suppose I can, if necessary, manually convert bits that would be more convenient as z-scripts.

[Player701]

In short: if it ain't broke, don't fix it. Some things that look pretty hacky in DECORATE can be implemented in a much cleaner way with ZScript, and of course ZScript has a lot of features that aren't available in DECORATE at all. I would recommend using ZScript for new projects though, to avoid needlessly rewriting code whenever you want to make use of some ZScript-only feature.

If you still want to convert your code, a 1-to-1 conversion is generally possible. However, DECORATE syntax is more lax, and you will sometimes have to make corrections to fix parsing errors. See here for a general guide on how to convert DECORATE code to ZScript.

After the initial conversion, further improvements can be made, but it's mostly situational and it's hard to give any specific tips. But here are some of the most common anti-patterns that come to mind - you cannot avoid them due to the limitations of DECORATE, but you can (and perhaps even should) do better when working with ZScript code:

• Repetitive code fragments (refactor to custom functions).
• Use of dummy inventory items, especially in weapons (refactor to variables; note that DECORATE has no proper support for user variables in weapons).
• Use of CustomInventory with Pickup and Use states (use Inventory with virtual method overrides instead).

I of course understand that in the end it all comes down to programmer's (i.e your own) preference, but if you want to make sure your code is easily understood by other people and especially want others to learn from it, try to make use of what ZScript actually has to offer instead of sticking to "DECORATE-style" code. It will make your own life easier, too.

[MartinHowe]

Essentially, DECORATE and ZScript are compiled down to the same virtual machine code, but by totally different routes that don't go anywhere near each other.

Imagine taking a long journey across your country from the Southernmost city to the Northernmost city; the railroad/railway/metro/rt is on the west side of the country and the motorway/autobahn/interstate/a-roads is on the East side. They both end up in the same place but never touch or have any common point of intersection.

[bimshwel]

if you want to make sure your code is easily understood by other people and especially want others to learn from it, try to make use of what ZScript actually has to offer instead of sticking to "DECORATE-style" code. It will make your own life easier, too.

The main thing to learn from my code is how not to do it! But I appreciate the insight given to addressing this question. I may have subconsciously been worrying about all the times in the past where my not-quite-broken code became broken over an update to the main system, as occurred a few times earlier in zdoom 's existence, and frustratingly more recently on my own website when my webhost messed with one thing or another on its end without warning.

perhaps an unorthodox use of this attention, would any of you have similar insight on how to implement a flat 3d model? I asked yesterday but perhaps erroneously asked it as a follow-up to another old question of mine.