Scripter 0.5

[Eddy-B]

Okay, Scripter verrsion 0.5 will be on the shelves soon. I've already fuxed te reported bugs, and am now considering the syntax of the extra commands i'm planning to add.

• Victory conditions -- how should they look?
  VICTORY LOS, "Destroy all enemies"
• Disasters -- same question
  CREATE QUAKE AT ( 12, 23 ) SIZE 2
• Other mission setting, like
  SET DAYLIGHT = YES / NO / MOVING  ? or should it be DAYNIGHT or NORMAL or ... ?

any suggestions ? those ^ are just examples,, i'll take the best sugestion i see.

[Sirbomber]

I guess those are alright, but what if we want "custom" objectives?
As for the disasters, make sure volcanos take care of all the "LavaPossible" things.
Don't forget defeat conditions.

[TH300]

`SET DAYLIGHT = YES / NO / MOVING' is fine.
`VICTORY LOS, "Destroy all enemies"' is also ok. Make sure that multiple victory conditions can be added.
I don't like `CREATE QUAKE AT ( 12, 23 ) SIZE 2' too much. You can create vehicles and structures, not disasters. Maybe use `DISASTER' instead of `CREATE' here or just leave it out. `SIZE' could come before `AT'. (btw. use `AT' everywhere or nowhere or it will be confusing, and use it at the same position in all commands)
Then we could have `ERUPTION ...', `METEOR ...',`VORTEX ...' and `ELECTRIC STORM ...' (?).
 

[Eddy-B]

I was planning to add "AT" as a transparent directive: it can be added but does not do anything; the compiler just skips the word.. so that way the user can add it just to improve readability.
The same goes for brackets/parantheses by the way: they are ignored BUT they MUST match, you cannot leave a parameter list 'open' or have too many closing brackets.


Please check the wiki on what i plan to add in version 0.5:  random numbers, the use of variables and some extra settings.

[BlackBox]

I don't like `CREATE QUAKE AT ( 12, 23 ) SIZE 2' too much. You can create vehicles and structures, not disasters. Maybe use `DISASTER' instead of `CREATE' here or just leave it out.

I think either way is fine. Create makes sense because internally when you call one of the Set* functions for disasters it creates a unit internally (disasters are technically units inside the game, you can create them using (internal) unit creation functions if you want).

Also regarding the victory conditions: I think you're getting ahead of yourself a little bit.

You should implement triggers first. You need a way to both create a trigger, and a way to specify the callback function:

Code: [Select]

// in a player block. You could assume playerNum = the current player block, or -1 if it's in the global section
COUNT TRIGGER ( StructureFactory >= 1 ) GotSF

// and then the trigger function.
BEGIN GotSF
    // code here...
END

GotSF could possibly represent both the trigger variablename and the procedure.
The StructureFactory >= 1 is basically a shorthand for saying "fires when # of SF's is greater than or equal to 1". If you wanted you could allow the user to expand that somewhat, maybe use a keyword instead of >= or whatever.

Then for victory conditions it could be a matter of:

Code: [Select]

VICTORY CONDITION GotSF, "Build a structure factory"

or something similar.

How does all that sound?

[Eddy-B]

sounds okay.
I've been working on random number generation yesterday. First part is done already (having scripter create a random number -- i don't know what good it will do, but u never know). The second part hangs with the use of variables. I do not want the user to insert a RANDOM right into a function call, but have him assign a variable, then use that in function calls. This way i can keep my code for parameter evaluation easier

[BlackBox]

I have an idea that might make writing your parser a lot easier (and would make it a lot more capable).

Ever heard of lex / yacc? (or their modern counterparts, flex and bison, i'll use these names to describe them herein). They're often used to create the text parsing sections of compilers.

You write source for the flex / bison engines and they generate C(++) code that makes up the actual parser.

It works in this way:
- flex is known as a 'lexical analyser', what it does is read the input (in your case it would be the script source) and parses it into 'tokens' by using regular expressions.
- bison is a parser generator, which uses the tokens that come from the flex part of your program to build up 'sentences' which your code can then use and make sense out of.

So to put it this way, i'll take an example from the example script that comes with the Scripter:

Code: [Select]

SET MAP="eden04.map"

Flex would generate code that slices this string up into different pieces. for example, you might have it slice it up like so:

4 'tokens' in this string:
- A 'keyword' token, in this case "SET"
- A 'variable' token, in this case "MAP"
- An 'operator' token, "="
- A 'value' token, "eden04.map"

This output which is broken up is then parsed by Bison generated code that makes sense out of it. Bison uses a 'grammar file' as input to generate its parser, which might tell it a rule like this:

Code: [Select]

Read the next line in the file. Look for a keyword token. This keyword token must be followed by, in this order, a variable token, an operator token, and then a value token. Then, send each piece of data to the core of the program where it knows what to do.

(of course, it is not written in english, it uses what's called an "LALR"

The flex/bison files are interspersed with C(++) code which then actually does the work, for example in the last instance you might have it call a function with a prototype like this:

Code: [Select]

void handleLine(char *keyword, char *var, char *operator, char *value);

And it might get called like this, in the preceding example:

Code: [Select]

handleLine("SET", "MAP", "=", "eden04.map");

It could get more powerful than this if you start defining generic rules so you can insert things like 'expressions' on the right hand side of the operator. That way it would make expressions like

Code: [Select]

SET MAP=ConvertToString(GetVariable(VAR_MAPNAME))

if you wanted, just like C++ supports.

If you're interested, look at http://www.codeproject.com/cpp/introlexyacc.asp

[Eddy-B]

looks interresting - but i've already written a parser like that.

I have functions for reading words, and i'mparsing them as they come in.

[Hooman]

Heh, sounds like Eddy's project is simple enough to make a hand written parser. I think lex and yacc might be a bit overkill. Well, I guess they could make things easier, but if the grammar is under development, I find those tools to be a pain to use unless I'm programming on a Linux/BSD machine.

of course, it is not written in english, it uses what's called an "LALR"

Btw, LALR(1) is the class of languages that YACC can recognize. You specifcy your language with a CFG (Context Free Grammar), which hopefully describes a language which fits into the LALR(1) class of languages. If it doesn't, then YACC will complain at you about either shift/reduce conflicts or reduce/reduce conflicts when it tries to compile your grammer into a C file.

It's also a pain to resolve those conflicts if you don't know how an LALR parser works. If you're not prepared to learn the parsing algorithm, you might be better off using something other than YACC when designing your own grammar.

But that aside, I was thinking Lex and YACC too.  



Btw, how are you writing your parser Eddy? Is it a hand written top-down recursive descent parser? Or are you using some kind of tool? Or maybe taking on the task of writing your own bottom up parser?

 

[Eddy-B]

it's a hand-written simple parser

It 'pops' the first word from the line and checks it with IF's.
Once i've mached it, it goes to the appropriate routine that pops more params and handles them further.

domething like:

Code: [Select]

getWord(cmd);
if (cmd=="SET") handleSet();
...

bool handleSet() 
{
  if (!getEqualSign()) return false;  //error
  getWord(param);
  if (param=="MAXTECHLEVEL") ...
//etc...
}

^ that is typed in on-the-fly by the way.. :-/

anyway .. i hope that clears it up a bit.