Welcome to the ZDoom Forums!

Is there any sort of interface that draws up a graphical representation of what some DECORATE/ACS scripts will do? Like SBARINFO, so's I can preview how it's going to appear without having to run the archive constantly? Is that possible?

No. How should that be possible? Unlike SBARINFO these formats do not define a graphical layout.

Sorry; just looking at all this coding and stuff is confusing me. It's probably going to take a while to orient myself to it.

best route is to become acquaintanced (on a side note, "acquaintanced" is apparently not an english word?) with what you wish to use (for example, to play with hudmessage until you have a strong grasp of it,) and then plan things out in advance and simply assume that your own competence and the engine's will be enough (still a good idea to test frequently; however, you don't need to test every single line)

don't know how relevant this would be, but graf's posts aren't angry like they may sound, emotion just translates poorly into text

I hereby officially declare "acquaintanced" to be an English word!


Some things that I find help the workflow in the absence of a WYSIWYG editor:

- Keep the text editor window open that you're working on and run the folder of your mod, only compressing into a pk3 once you're about to upload.

- Make sure your text editor highlights beginning and end parentheses. (Leafpad doesn't do this, it screws me over constantly, do as I say not as I do)

- To test, Hit Winkey+R and type in (or even better, paste from a comment in the file you're working on) the command to run your mod in ZDoom. Saves you the trouble of switching over to that window and losing your place on the DECORATE file.

- Relatedly, have ZDoom default to running in a window so you don't lose your sense of visual continuity by abrupt switches to and from testing.

- Anytime you have to jump to something, name it as a new state (but be careful you don't screw up any "loop" calls). No jump offset should ever be more than 3.

- Keep your tabbing consistent.

- That said, add as much white space between sections of code as you need or want.

- Have a few favourite placeholder sprite names so you don't have to fuss about graphics before you've got the code right. Mine are BAL1A and BAL7A.

Heh, I tend to use GZDB to launch my pk3's for decorate testing.

It took me a while to get used to how DECORATE worked as well, with the sprite names and states and how they worked when you compressed multiple states into a line... I'd recommend taking a look at some of the default monsters, like ZombieMan, and seeing how they behave with the default code. You can also use the A_Log command to print a message to the console to see where an object is in its script, too.

Now you mention it, a program to interpret DECORATE and allow someone to step through it line by line would be useful too - anyone feel like taking it up?

One thing that helps for me is go into ZDoom's autoexec.cfg and put the following lines: If you get a recursion error (I am guessing it's a bug I just never bothered reporting it), you can just type "restart" and the alias will be remade and you can do it again.

Then you can see your changes live without exiting and starting ZDoom over and over again (particularly nice with GZDoom, where the OpenGL init can take a few seconds).

Then edit and tweak your DECORATE file, save, run dectest and decmap in the console, test it, repeat over and over again. It helps if you create a map with the DECORATE object you are testing already spawned, that makes things hugely faster.

Wiw wrote:Is there any sort of interface that draws up a graphical representation of what some DECORATE/ACS scripts will do? Like SBARINFO, so's I can preview how it's going to appear without having to run the archive constantly? Is that possible?

This is not exactly what you have in mind, but it does have a GUI of sorts.
http://zdoom.org/wiki/DecX





By today's standard it is fairly old. So use at your own risk.