Doom Marine
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > Exciting EDF Improvements
 
Author
All times are GMT. The time now is 16:49. Post New Thread    Post A Reply
Quasar
Moderator


Posts: 4615
Registered: 08-00


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:

code:
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:

code:
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:

code:
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?

Last edited by Quasar on 04-03-08 at 21:04

Old Post 04-03-08 20:39 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
SoM
azerty YAY!


Posts: 266
Registered: 03-02


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

Anyone? Heh

Old Post 04-03-08 20:43 #
SoM is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
Cumulonimbus Antagonistic Posting


Posts: 5268
Registered: 01-02


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

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

Old Post 04-03-08 21:42 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 6845
Registered: 06-06


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?

__________________
Your Doom today *** Projects in progress: Automatic Wolfenstein (almost released) * AutoDoom

Last edited by printz on 04-03-08 at 22:58

Old Post 04-03-08 22:32 #
printz is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
esselfortium
Cumulonimbus Antagonistic Posting


Posts: 5268
Registered: 01-02



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

__________________
essel.spork-chan.net - doom stuff, artwork, and music by esselfortium

Old Post 04-03-08 23:12 #
esselfortium is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 4615
Registered: 08-00



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:
code:
spritenames += { FOO1, FOO2, FOO3 } ifenabledany(DOOM, HERETIC)


Illegal:
code:
// 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.

Old Post 04-04-08 05:50 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 6845
Registered: 06-06



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.

__________________
Your Doom today *** Projects in progress: Automatic Wolfenstein (almost released) * AutoDoom

Old Post 04-04-08 07:14 #
printz is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
printz
CRAZY DUMB ZEALOT


Posts: 6845
Registered: 06-06


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

__________________
Your Doom today *** Projects in progress: Automatic Wolfenstein (almost released) * AutoDoom

Old Post 04-04-08 12:52 #
printz is online now Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 4615
Registered: 08-00


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:

code:
// 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 ;)

Old Post 04-06-08 00:39 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 16:49. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Special Interest > Eternity > Exciting EDF Improvements

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory