DECtoZSC - Patch 1.1 - Basic DECORATE to ZScript converter

[RockstarRaccoon]

UPDATE - Just Patched it as of 5/12 to fix some minor bugs and shortcomings, so it will spit out more accurate ZScript files. Most notably, it self-corrects the occasional ";;" or ") ()" at the end of a line, understands that actors might not have states, and it puts quotes around RenderStyles.


So, as everyone in the Discord knows, I've been writing a quick and dirty Java program to convert a pile of DECORATE code into ZScript for me, with the intent on making it public, because, you know, there are a lot of people with projects that were written in DECORATE and could be better if they could use ZScript insread... SO HERE IT IS!

This is a Zip File containing the JAR and the (incredibly sloppy) source code, as well as a sample file to test it on.
You run it by tossing it in the command line as "java -jar <jarfile here> <.DEC File> [options]"
OR (new!) you can use the .bat file I included, which you pass a directory to, to automatically go through a while folder at once.
Upon running, it will create a (mostly accurate) rewrite of the DECORATE file, using the filename of whatever you threw in with the ".txt" or ".dec" replaced with ".zsc". (I advise against using any file names that don't have a 3 character suffix, because I was sick and lazy when I wrote the file-extension changer, and just had it replace the last 3 characters)
If you want it to output what it comes up with to the command line directly, use the "-debug" option.
If you want it to not write a file, use the "-nofile" option.

Some notes:
- This is a really sloppy program, so I make no promises about it. It shouldn't create any real problems, because it's just JAVA reading one text file and writing another, which is one of the most basic functionalities, but I'm still going to go with the usual "this is free software and I make no garuntee that it works properly" disclaimer. The worst that I think will happen though is either a) it won't run on some systems, or b) it will output bad ZScript.

- I tested this with a couple of ZDoom's built-in DECORATE files, and it worked with them, but it's very sloppy, and I didn't exactly write it to be robust. I can't say what errors the code it will output might have, but probably stuff like not having parentheses after an actor_function in the middle of a state block, or putting a semicolon in the wrong place. I CAN say that the ZScript files it outputs are accurate enough that it will save you a buttload of time when you DON'T have to rewrite the whole thing by hand, and I have a really nice butt, so...

- Oh, and this will totally fuck with your bracket placement, but it should still come up legal.

- If anyone wants to like, rewrite this thing, or improve upon it, I encourage this. I wrote this because I needed it for something, and I spiffed it up and am making it public because I know the community will benefit from having access to it. All I ask is that you like, mention that Raccoon wrote the original, or whatever.

KNOWN BUGS:
- After running this on some DECORATE files from a project, I noticed that it will sometimes stop parsing properly mid-file. This will be apparent, because it stops putting in semicolons. I'm not yet sure why, though I suspect it has something to do with a case it wasn't built for. I suggest putting the DECORATE code after wherever it stared into its own file and running the converter again, if it's too much left to just do it manually.
- - This happens less now after I patched it.

- 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.

- this program fucks up any time you have an actor without states, because I forgot to program it to handle that. FIXED

- this program ignores Damage Type definitions, because I forgot to have it handle that. It would be better if it either ignored them, or spat them out as a separate thing.

- this program doesn't understand that, while it's ok to not surround things like Damagetypesand RenderStyleswith quotes in DECORATE, it's not ok in ZScript.
- - I have it sticking quotes around RenderStyles in most cases now.

- A_Setuservar and A_SetuserArray don't convert properly either, unless you add in ZScript to make them function like they do in DEC.

- For an unknown reason, this program will sometimes add a '()' to the end of a line where there is already a closing parentheses. I suggest running a find-and-replace command to replace ") ()" with ")" as a quick fix. FIXED

- For an unknown reason, this program will sometimes end a line with 2 semicolons instead of 1. I suggest running a find-and-replace command to replace ";;" with ";" as a quick fix. FIXED

- Should snip the DOOMED numbers in the Actor declarations, but doesn't.

- Doesn't know to replace "Damage" with "DamageFunction"

[RockstarRaccoon]

...well don't talk about how you're going to use this or need help with it all at once...

[Rachael]

Perhaps the people who noticed it so far either have nothing to say, or there are just yet people who haven't noticed it. Either way, try not to get too impatient about it.

Nevertheless, the more tools the better in my opinion - and this one will certainly have a place in many people's toolboxes. There's been people wanting something like this for a long time, so I do consider this to be a valuable contribution to the community.

If it's not too complicated, I might see about converting it from Java to C so that it can be compiled and run without Java, since that's something a lot of people do not like. But if there's any complexity at all in it, this idea may not work for me.

[RockstarRaccoon]

Perhaps the people who noticed it so far either have nothing to say, or there are just yet people who haven't noticed it. Either way, try not to get too impatient about it.

I know, I'm just joking around.

Nevertheless, the more tools the better in my opinion - and this one will certainly have a place in many people's toolboxes. There's been people wanting something like this for a long time, so I do consider this to be a valuable contribution to the community.

Glad to hear you appreciate it! Like I said, I wrote it because I needed it for Membrane, and I wanted to share it because other people needed it too.

If it's not too complicated, I might see about converting it from Java to C so that it can be compiled and run without Java, since that's something a lot of people do not like. But if there's any complexity at all in it, this idea may not work for me.

I wasn't aware the anti-Java crowd was a big thing in this community, but I suppose I should have guessed. Major Cooke was saying something about making it in LUA, because then it could be a SLADE plugin, but I'm not comfortable enough with LUA to do that. I used to teach C++, so I could easily convert this to a C / C++ type program if I came back to it, I just used Java because that was easy to throw something together in that could run on any computer.

If such a rewrite is performed, however, it should be done much more elegantly than this 250 line brute-force mess. For instance, there are a lot of unneccesary parts of this, or parts which could have been done in a way that was more likely to come up with the right answer. It's a good tool, but it was thrown together in a couple hours by someone who was sick at the time.

[Graf Zahl]

I wasn't aware the anti-Java crowd was a big thing in this community, but I suppose I should have guessed.

The main problem is that such tools are very hard to integrate into existing toolchains.
Imagine an editor like SLADE wanting to use such a tool as a conversion worker. Having the Java requirement requires the user to download and install some large distribution package aside from the editor itself.

Major Cooke was saying something about making it in LUA, because then it could be a SLADE plugin, but I'm not comfortable enough with LUA to do that.

Actually I have to say that Lua is one of the most awful programming languages around. Its sole saving grace is the small memory footprint for embedding, if it wasn't for that it could die in agony if you ask me.

[RockstarRaccoon]

Actually I have to say that Lua is one of the most awful programming languages around. Its sole saving grace is the small memory footprint for embedding, if it wasn't for that it could die in agony if you ask me.

Hah! My agreement is the reason I'm not experienced with Lua. XD

[Blue Shadow]

A tool like this is of no use to me, since I prefer converting my code manually. Besides, things like this...

This is a really sloppy program, so I make no promises about it. It might totally explode on you. You better not run it if you don't want to die along with everything you know and love. (ok, in reality, it'll most likely just crash when you try to run it, or write a corrupted file. It's not that complicated and it's in Java.)

... doesn't fill me with confidence about using the tool, really.

Perhaps the people who noticed it so far either have nothing to say, or there are just yet people who haven't noticed it. Either way, try not to get too impatient about it.

I know, I'm just joking around.

Well, you did bump your own thread asking for feedback a day and a half later, which is enough to attract a moderator's attention. It's like intentionally crossing a red light and then being pulled over for it, and telling the police it was not intended.

[Rachael]

And plus, no moderator on this forum buys the whole "I am just joking around" excuse. That's the most overused and obvious excuse in history and it's a surprise that anyone thinks it actually still works.

[RockstarRaccoon]

This is a really sloppy program, so I make no promises about it. It might totally explode on you. You better not run it if you don't want to die along with everything you know and love. (ok, in reality, it'll most likely just crash when you try to run it, or write a corrupted file. It's not that complicated and it's in Java.)

... doesn't fill me with confidence about using the tool, really.

Ah, right, I was being kind of silly / loopy when I wrote that. I should change it to something like "I make no promises about the stability of this program, though it's Java, so it should be safe to run."

And plus, no moderator on this forum buys the whole "I am just joking around" excuse. That's the most overused and obvious excuse in history and it's a surprise that anyone thinks it actually still works.

Um... Well, ok, I'm sorry that I sounded so serious to you. I thought I was being funny...

[RockstarRaccoon]

Today I wrote a .bat script to go through all the files in a folder and run the program on them. Found a couple of odd points where it crashes mid-file, but fortunately, because of the way I wrote it, it saves the ZScript as it goes and for some unknown reason dumps the rest of the DECORATE in there un-changed upon crashing.no wait, it continues parsing but does it wrong. I think it thinks it's no longer in an actor or something.

Adding the note about the bug to the post and the .bat file to the zip.

Edit: Also, because the thing on the wiki about converting from Dec to ZSC doesn't have anything about the "var" attribute, I didn't put it in there.

Edit: Ok, I'm just making a list of known bugs and potential fixes.

[RockstarRaccoon]

Just released a major patch which fixes the most gaping problems. (namely the double quotes and double parentheses) Now it REALLY saves time when you need to convert a ton of DECORATE to ZScript.

[Apeirogon]

So I must "install" java to use it?!

[Enjay]

I'll need to give this a go when I get a chance. I was quite interested in a DECORATE to ZScript converter. Having some of my own DECORATE auto-converted will help me learn some of the features of ZScript.

[Apeirogon]

Reports from the field use

Sometimes convertor make this

Code: Select all • Expand view

CLASS TheSpiderMastermind Replaces SpiderMastermind : ACTOR {


instead of

Code: Select all • Expand view

CLASS TheSpiderMastermind : ACTOR Replaces SpiderMastermind  {


And it dont know how handle this, and a like, case

Code: Select all • Expand view

      XVIL Q -1;
Stop    }}    


Sometimes it miss where begins default block

Code: Select all • Expand view

CLASS DeadCacoDemon2: DeadCacoDemon1 {
   Default {
   }
{Health 200 States{Spawn:
        CCD2 B -1
        Stop   
      }}      


Sometimes it mess with damage factor

Code: Select all • Expand view

   Default {
 
CLASSgeFactor "Head", 0.0 : ACTOR {
   Default {
   }
   States


Sometimes it refuse to convert actors to zscript and drop it in half path. Mostly this happens with BIG files with much of an actors.
But most of this cases can be solved if you copy-paste failed actor to new decorate file and throw it in converter again.

Overall, most of a dirty work, like place semicolon and (), it complete in seconds. Rate in 3.5 stars out of 5.

[Major Cooke]

Only today was I made aware of this. Had I seen it before, I would've been all over and on top of it.

I gave up on LUA. It's not friendly at all and its departure from regular Java/C style coding really shoots it down into an undesirable level let alone.

I personally couldn't care less if I'm required to download something Java related just so I can run the code, because that versus hand converting everything...

Now, I haven't tested it yet. But I will be here soon in a bit.
I will say that my two biggest time-taking issues are adding semi-colons to the end of everything, and converting A_SetUserVar/Array to direct assignments. Even if you cheat a little and just have it go from:

Code: Select all • Expand view

A_SetUserVar(user_something, 1)

to

Code: Select all • Expand view

{ user_something = 1; }

That alone would be a godsend. Those are the two biggest time spenders that I have to deal with.

I'll be giving this a shot soon.