Exciting EDF Improvements

[Quasar]

While I've been without a home internet connection for almost a week now, I've been working on EE a *lot*. I've been knocking out some long-scheduled improvements to EDF.

1. HEREDOC syntax: Anywhere you can put a string, you can now also put a heredoc. What is a "heredoc?" It's a document provided inline with surrounding code. It could for example be code in another language, or just plain text data. EDF uses Windows Power Console's heredoc syntax, opening them with a @" and closing them with a "@ at the end of a line.
An example (totally an example, this is not a real scripting language...) might look like this:

frame foo
{
   action = @" for(i = 0; i < 3; ++i) CallSomeScriptFunc(); "@
}

2. Keywords for action function parameters. That's right, no more remembering stupid numbers when you want to set arguments on frames. Now you can use values such as "monster" or "add" or "nomomentum".

3. Action function parameter syntax improvement in cmp frames. Example:

frame foo
{
   cmp = "TROO | A | * | 5 | SetTics(105, 128) | @next"
}

Works together with the new keyword system.

4. Function-valued variables. I am modifying libConfuse to allow function values for options. Example:

frame foo
{
   action = SetTics(105, 128)
}

EDIT: I forgot one!
5. Cascading namespace resolution for values in frame args/misc fields. If a name is not explicitly qualified, it will no longer simply be interpreted as an integer. It will first be looked for in the following namespaces in the given order:
thingtypes, frames, sounds, strings, bex pointers, keywords
I have the ability to add further namespaces to this sequence if they are needed in the future. As I mentioned, you can still explicitly qualify a name, for example if there are conflicts (a frame and thing named the same thing and you want the frame, for example). To do that, you just do what you always did - thing:foo or frame:foo, etc.

So, pretty snazzy stuff, huh?

[SoM]

Nice! Now for the full documentation on the wiki...

Anyone? Heh

[esselfortium]

Nice. Frame definitions are still kind of wordy, even with CMP (in comparison with decorate, where if no codepointer or only one codepointer is needed, you can define an entire sequence of frames in one line, like "TROO AABBCCDD 8 A_Chase" or something like that), but this looks cool nonetheless, even though I don't understand all of it :P

[printz]

Hehehehahahah, big stuff. I'll be able to make super-dynamic monsters when blocks of code replace simple functions...

Is it that the main difference between a Heredoc (which sounds a lot like Heretic and Heresiarch, I think it's on purpose) and a string are the possibility of ENTERs and the larger capacity?

While we're at it, I should tell you that Eternity's code interpreter is not as lax with statement separators as it says in guidelines. I cannot use semicolons inside args or spritenames+= {} blocks as well as I can't use commas in frame {} blocks. There surely may be other cases as well.

esselfortium said:

Nice. Frame definitions are still kind of wordy, even with CMP

Why care if it may be possible to insert blocks of indefinitely sized code in frame data?

[esselfortium]

printz said:

Why care if it may be possible to insert blocks of indefinitely sized code in frame data?

Because sometimes I don't want or need to insert a block of code, I just want to tell a monster to cycle through 30 frames of its death animation without having to do a ton of copying and pasting and changing little numbers on each line. :P

[Quasar]

printz said:

Hehehehahahah, big stuff. I'll be able to make super-dynamic monsters when blocks of code replace simple functions...

Is it that the main difference between a Heredoc (which sounds a lot like Heretic and Heresiarch, I think it's on purpose) and a string are the possibility of ENTERs and the larger capacity?

While we're at it, I should tell you that Eternity's code interpreter is not as lax with statement separators as it says in guidelines. I cannot use semicolons inside args or spritenames+= {} blocks as well as I can't use commas in frame {} blocks. There surely may be other cases as well.

Why care if it may be possible to insert blocks of indefinitely sized code in frame data?

Actually I think heredoc is pronounced as "here" "doc", as in a document that's here. But yes, you're right. heredocs interpret everything inside literally, including line breaks, spaces, tabs, escaped characters, and even quotation marks. This means they can contain any sort of text.

Actually, libConfuse syntax only allows commas inside list-type options and in function call parameter lists. Lists in EDF include the spritenames array, args lists inside frames, and the individual lines of a sound sequence command list. Commas and semicolons are strictly not interchangeable, and whereas semicolons are strictly optional and are actually ignored, commas are required between the elements of lists and between function parameters. Sorry if the docs were not clear enough on this. They're all due for rewrite and for import into the wiki :)

So to sum up:

Legal:

spritenames += { FOO1, FOO2, FOO3 }
ifenabledany(DOOM, HERETIC)

Illegal:

// These give parser error "unexpected token"
spritenames += { FOO1 FOO2 FOO3 }
spritenames += { FOO1; FOO2; FOO3 }

// These give parser error "syntax error in function call"
ifenabledany(DOOM HERETIC)
ifenabledany(DOOM; HERETIC)

If these do NOT work as expected, please explain precisely how and I'll investigate :) It's always possible there are glitches that my regression tests have missed.

[printz]

esselfortium said:

Because sometimes I don't want or need to insert a block of code, I just want to tell a monster to cycle through 30 frames of its death animation without having to do a ton of copying and pasting and changing little numbers on each line. :P

Yeah, there's more work, but I work around that by only using cmp, one line one frame and tightly grouping the frame blocks.

But death animations are really the easier part. Never had trouble. More trouble I had with Jumped frames. Thus ONLY IN CASE blocks of code are implemented (enough hype w/them, what was posted was only an idea...), jumped frames will be much easier to read.

[printz]

Shouldn't there be a -fast tics attribute for frames, to make the fierce -fast demon case customizable?

[Quasar]

Indeed there should be, or at least some way to specify this behavior. This is an outstanding issue. If you look in the source file g_game.c in function G_SetFastParms, you'll see this:

   // TODO: Heretic support?
   // EDF FIXME: demon frame speedup difficult to generalize
   int demonRun1  = E_SafeState(S_SARG_RUN1);
   int demonPain2 = E_SafeState(S_SARG_PAIN2);

I skipped over solving the problem when implementing EDF and its been neglected since then. Since you drew my attention to it, however, I'll see about fixing it right now ;)