DECtoZSC - Patch 1.1 - Basic DECORATE to ZScript converter

[RockstarRaccoon]

adding semi-colons to the end of everything

Well, you literally just described the kinds of things I made it to handle in the first place.

And by that, I mean the original project here just went through every line and gave it a semicolon if it didn't already have something like a bracket precluding that. It's just a time saver when you are trying to take a bunch of DECORATE and turn it into ZScript, made because that was something I was doing a lot of at the time.

[Major Cooke]

Of course I figured that was already done, but I am curious about how you plan on handling A_SetUserVar/Array.

[RockstarRaccoon]

I am curious about how you plan on handling A_SetUserVar/Array.

Honestly, if it hasn't been handled already, I don't have any plans on going back and handling it. This was just a quick little program I threw together to simplify the process when ZScript first came out, simply because I had a lot of code that needed to be converted. My method was this was just having it do the bulk of the work for me, and then trying to get GZDoom to load it over and over and using the bug reports to fix things. The things which came up in the bug Reports most often are the things which I focused on fixing.

If you want, you're welcome to download the Java code and write in a change, or simply make another one that converts the DECORATE into an intermediary data structure and then outputs correct ZScript. As it stands though, this pretty much does 95% of the work for you, so I'd say it's a great time saver as is.

At this point, I've kind of abandoned this project, as it does what I wanted it to, and I don't have the time (lots of paid work right now) or active interest in GZDoom to make things for it. If I did, I'd probably be screwing around with the game code again, like with the automap changes I made...

[Enjay]

- This program does not know or compensate for "var" tags. You will have to fix those manually. I think I could get it to yank them and redo the lines when it closes the Default block as a fix.

Does anyone know how these lines of DECORATE should look in ZScript?

Code: Select all

		var int USER_MechTorso;
		var int USER_MechScript;
		var int USER_MechStand;

Thanks.

[SanyaWaffles]

drop the var keyword and declare them outside the default and state blocks.

[Enjay]

Ah! Perfect. Thank you. I'd tried removing the var, but hadn't lifted them out of the default block.

[Enjay]

I don't know if RockstarRaccoon is still interested in this util, but I have noticed that translations commonly come before points in a file where the util stops putting a ; at the end of lines.

A line like this in decorate:

Code: Select all

TRANSLATION "80:111 = [255,255,0]:[115,43,0]"

often gets converted without a ; and so throws up an error in GZDoom and, very commonly, subsequent lines also end up missing their ;

So, if RockstarRaccoon is still interested in looking at this, the above might provide a clue?
If not, the tool is still very useful.

[Enjay]

Just to add to the above feedback (which, again, may or may not be wanted - I'm not even sure how often RockstarRaccoon still visits), I have given this tool a major workout in the last week (some discussion about it can be found here: viewtopic.php?t=80174 )

I have used the converter tool on many thousands of lines of DECORATE code (maybe 60,000 lines or probably more). The tool has all the problems/glitches that RockstarRaccoon said it would. I'm not complaining, merely noting that it happened (as expected). However, even though every file I tried came up with a glitch of some sort (often many glitches), the tool really does most of the heavy lifting and GZDoom's ability to pinpoint exactly where the problems were (which file files, and on which lines), made finding and correcting the problems straight forward. The vast majority of the time, the mistake was pretty obvious, as was the fix. It's just that with so much code, there were lots of glitches to deal with. That's on me as much as anything. Again, I'm still not complaining.

I did actually start to develop a "sixth sense" as to which code was likely to throw up problems. Sometimes, I would know exactly which lines were going to be problematic, at other times, I just had a "feeling" but wasn't sure exactly.

As I said before, translations often seem to lead to the tool giving up on putting ; at the end of lines, but not always. Sometimes it seems to parse them just fine. It seems to be more likely to cause a problem for complex translations, especially if they are split over several lines.

e.g. this is likely to cause a problem - weirdly, it doesn't always happen immediately, but further down in the actor, or even on the next one.

Code: Select all

    TRANSLATION "112:127 = [203,0,0]:[12,0,0]",
    "192:207 = [87,178,248]:[0,29,149]",
    "240:247 = [0,17,109]:[0,1,32]"

Also, I think spaces at the end of lines can cause problems.

e.g. lines like this seem to often cause a problem:

Code: Select all

GIB1 EFGH 5 

It's not obvious, but there is a space after the 5 (which was clumsy of me in the original DECORATE). This would tend to generate code like this:

Code: Select all

GIB1 EFGH 5 ();

The brackets after the 5 are a problem, and GZDoom won't start until they are removed. There seem to be a few different cases where such brackets can end up in the code incorrectly. I haven't figured them all out. I *think* maybe comments directly after the number might also cause it.
e.g.

Code: Select all

GIB1 EFGH 5//this is a comment

However, I don't think that any of the above happen 100% reliably - perhaps because of something else going on in the file - but they are common. In fact, stray () at the end of lines was one of the most common errors I got.

Sometimes DamageType entries would appear with the specified damage type not given ""
i.e.

Code: Select all

damagetype fire;

instead of

Code: Select all

damagetype "fire";

A similar thing happens with inventory icons. This DECORATE code...
e.g.

Code: Select all

inventory.icon ARTIFLAR

...would not be given "" around ARTIFLAR
Again, possibly clumsy DECORATE leads to this (i.e. if the DECORATE did not have "" (which works), then the generated ZScript won't (and that doesn't work).

I also found an actor type that never gets converted properly, and always messes up what comes after it: empty actors that inherit from something else.

e.g.

Code: Select all

ACTOR MyCoolActor2 : my MyCoolActor1
{}

Will generate this:

Code: Select all

CLASS MyCoolActor2 : my MyCoolActor1 { 
	Default {
	}
{}

Which is borked (an extra { near the end), and everything after it will fail too.
Why would someone make such an actor? In my case, identical actors but with different models allocated to them in MODELDEF.
Sometimes other minimal inherited actors (i.e. similar to the one above but, perhaps, changing only one line) may have also caused problems, but I am less sure about that.


All that being said, I am extremely grateful for the tool. It isn't perfect; RockstarRaccoon never promised that it would be (indeed, they said it wouldn't be), but it did a lot of the dull, laborious, tedious conversion tasks for me (which is what RockstarRaccoon promised it would do) and, even though I spent a lot of time fixing up the results, it would not even have been possible for me to convert so much code without this util.

So, the conclusion is a big thank you.