Macro Editing For Doom64 (Update)

[Kaiser]

I've brought this up on my forums but I also wanted to bring this up here as well.

For a while I ran into a dilemma with Macro editing in Doom Builder 64. The current implementation on how it's done is very poor and confusing to work with so I am considering going with an alternative to editing Macros but I need your opinion.

What I would like to do is instead of editing Macros in the editor, you will working with something similar to ACS, meaning, you work off of a text-based script file and then use a tool to compile that script into Macro data. Bare in mind that this ISN'T ACS but rather an alternative to using the editor. This is good for several reasons:

* Allows other editors to support Doom64 without having to implement a built-in macro editor
* Most people are used to editing out of text-based script files
* Easier (for me) to implement and support
* Saves me a lot of headaches since I don't know the editor's code base NOR C# that well
* Allows people to quickly grasp how Macros work (current implementation in Doom Builder 64 is very technical)
* A prototype of this tool already exists (just requires a few tweaks here and there)

But anyways I need your opinion, you guys prefer to use a text-based script file for creating Macros or are you guys comfortable with using the built-in Macro editor in Doom Builder 64?

[esselfortium]

What you've shown me of the text-based system looks a lot easier to create and edit macros with than the current macro setup dialogs, which are rather awkward and limiting. This should be a pretty big improvement for usability.

[Gez]

I don't see any downside to it. In effect, it becomes a fourth script type (after ACS, FraggleScript, and Strife convos) which gets its own compiler tool.


Similar to the SCRIPTS lump for ACS, would there be a remaining "source" lump appended after the binary MACROS lump? If not, a MACROS lump is easy enough to decompile of course. If there is one, how would it be called? MACROSDEF maybe?

[Kaiser]

here's an example of the tracer trap you see at the beginning of Dark Entires:

//
// this is a comment!
//

macro 1
{
    Ceiling_MoveToHeight(35, 256);
    Ceiling_MoveToHeight(2, 192);
    wait; // wait on the current action executed

    Delay(45);

    loop(14) // loop 14 times
    {
        Thing_SpawnTracer(1);
        Delay(20);
    }

    Ceiling_MoveToHeight(35, 384);
    Ceiling_MoveToHeight(2, 320);
}

Gez said:

I don't see any downside to it. In effect, it becomes a fourth script type (after ACS, FraggleScript, and Strife convos) which gets its own compiler tool.


Similar to the SCRIPTS lump for ACS, would there be a remaining "source" lump appended after the binary MACROS lump? If not, a MACROS lump is easy enough to decompile of course. If there is one, how would it be called? MACROSDEF maybe?

For time purposes, it'll remain as a binary lump. I don't see the need of a SCRIPTS-like lump though, plus MACROS are easy enough to be decompiled or converted into SCRIPTS with little effort

Though what I've realized is that if I do move forward with this, then there are the possibilities of using linedef specials to do opcodes, which can lead to supporting variables, branching, and whatnot.

[Koko Ricky]

I'm mentally sighing right now. I'd like to do some Doom 64 editing but I have no idea what anyone is talking about in this thread. I often feel like I'm getting in over my head when I think about doing anything beyond the most basic mapping.

[Kaiser]

Hopefully this text-based scripting format should be easier to edit and create macros. If you know ACS then this should be a breeze to do.

[Kaiser]

Bumpity bump

I am about to roll out this new compiler tool called BLAM "Basic Line Action Macro". It behaves somewhat like ACC except that it doesn't support expressions or statements.

The source code is available but the tool itself hasn't been officially released. Once it does get released I'll make an update to Doom Builder 64 to recognize the tool so users can start using it in the editor.

SVN for Blam: http://doom64ex.svn.sourceforge.net/viewvc/doom64ex/branches/2.3/src/blam/


A test script is found in /bin/. Feedback is welcomed

[DaniJ]

Nice. Extra points for GPL'ing this :)

I'm currently reading the source and noticed the -d (|-decompile) option - is that fully implemented? Now to run some tests and perhaps re-compile conversions with the original game data lumps...

Edit:
Semantically, the way the "functions" are defined in common.txt seems somewhat adverse to the way the program is intended to be used. Given that the intention is to present modders with an ACS-like editing interface it seems somewhat back to front for common.txt to define those in terms of bytecode snippets. I would have expected those functions to be defined within BLAM itself instead of requiring an #include common line at the start of each script.

[Kaiser]

DaniJ said:

Nice. Extra points for GPL'ing this :)

I'm currently reading the source and noticed the -d (|-decompile) option - is that fully implemented? Now to run some tests and perhaps re-compile conversions with the original game data lumps...

-d and -i works. -decompile isn't implemented and I need to take that out of PrintUsage() (leftover crap from KSSC)

DaniJ said:

Semantically, the way the "functions" are defined in common.txt seems somewhat adverse to the way the program is intended to be used. Given that the intention is to present modders with an ACS-like editing interface it seems somewhat back to front for common.txt to define those in terms of bytecode snippets. I would have expected those functions to be defined within BLAM itself instead of requiring an #include common line at the start of each script.

The 'base' syntax for defining macros is simply <linetype> : <tag>; The contents from common.txt is there to make things more legible and easier to use. It was easier/faster for me when implementing the parsing system and simplifies the syntax/token checks.

It's not intended to be like ACC but since the macro system fully relies on line actions, there's no need to implement fancy function types/names.

[DaniJ]

I can surely understand wanting to keep it simple.

However, I stand by what I said about the common include. Passing that overhead on to the user (and every script source file written in future), when it could be relatively easily incorporated into the compiler tool just seems unnecessary (your parser looks capable of supporting it and you already have statements with arguments)..