FIeldscript syntax.

[halkun]

Ok, now that we have at count about four implementations of fieldscript floating about. I think we need a unified human readable way the laguage is suppoed to go.

I'm all for an #include directive to allow alasing of variables. I don't want them declared in script, I would like to command sequence as close to the bytecode found in the file.

I also like curly brackets.

Borrowing from Lasyan, Should varibles be something like this?

Code: [Select]

if (<03>[32] == 19){pc(0)}

This means bank 3, address 32, that can of course be aliased in an #include where we can have something like <mapjump> that defines the mapjump files.

Code: [Select]

if ($gold == 2872){...}

is that workable?

In my script dumper, I include an "alias" command for repeating scripts, though it would seem that the script slot location is important. If the script is in slot 3 or above it seems to be on "on touch" or something.

Also scritp 0 has two states, I define that as an init script and a base script.

Here's a dump from what I have from my program.

Code: [Select]

 #################### Entity 0 (dic) ####################                                                                                ENTITY(0) = dic                                                                                dic (script 0){      INIT:1ba:    prtyp(0)1bc:    ret      BASE:1bd:    ret}                                                                                dic (script 1){1be:    ret}                                                                                alias dic (script 1 to 31)                                                                                #################### Entity 1 (cloud) ####################                                                                                ENTITY(1) = cloud                                                                                cloud (script 0){      INIT:1bf:    char(0)1c1:    pc(0)1c3:    ret      BASE:1c4:    xyzi(0,0,0,0,0,0,0,0,1,0)1cf:    ret}                                                                                cloud (script 1){1d0:    ret}                                                                                alias cloud (script 1 to 31)

In the end would like the addresses to be labels that can be refrenced with the JMP* commands.

Comments are '#' ... What are your thoughts....

 

[Synergy Blades]

While we're at it, we could do with a standard set of opcodes (and capitalisation thereof). I've seen a fair number of variations so far.

 

[Cyberman]

I suppose we could borrow #define as well from the C preprocessor.

IE
Code: [Select]

#define dic ENTITY(0)#define cloud ENTITY(1)

The first 4 scripts may be predefined events.
IE 0 = Load/Initialization.
1 = Click on

etc.

 

[sfx1999]

Why not use enumerations for that?

 

[Cyberman]

Err you are enumerating a macro?
I'm not sure what you are suggesting.


Or are you refering to the entity thing?
Entity 0 - N (at least 1 entity exists).
So you are infering to
Code: [Select]

enum entities dic, cloud;

instead of using #define to make a macro of this?
I'm not positive but I don't think you can use enumerated data types that way.
Especially when you are substituting it for a non integer type such as an object (Entity in this case).
Since Entitys are objects or collections of data and functions ... I'm fairly sure this isn't a good idea.
ENTITY(0) merely states which clump of 32 scripts to start with. (IE in this case the first).
Otherwise you would need to do ENTITY(dic) instead of ENTITY(0) this negates the idea of just using dic script(0) (you would end up with
Code: [Select]

ENTITY(dic) script(0)

which ... looks like crap and isn't much clearer).

Anyhow other things whilst thinking about this since the entities are really an array of sorts we probably should be using []'s instead of ()'s
IE ENTITY[0] then we can just use ENTITY[0][0] for entity 0 script 0. If one did
Code: [Select]

#define Init [0]#define dic ENTITY[0]dic Init{   Constructor:      prtyp(0);      return;   Base:      return;}

This is a lot clearer to me at least what's going on.
Of course I could have totally misguessed what you were talking about sfx1999 if so OPPS!

Sorry if so.

Cyb

 

[gigaherz]

My thoughts (assuming this syntax would be used to define a script [de]compiler):
1. If comments are #, then #define is a comment, so at least make comments be ##.
2. In my opinion, #directives aren't "clean" and they get confusing sometimes. My opinion would be to use either
Code: [Select]

define dic=Entity[0];

or
Code: [Select]

alias dic=Entity[0];

or
Code: [Select]

const dic=Entity[0];

3. <bank>[address] structure is compact, but might get really confusing, why not make it bank[3], bank[3] or bank<3>

4. To keep a common syntax style, and given C's [] means "subscript", it would be good to keep all of them in a similar way, like Entity[0], Script[0], Bank[3], Address[32], etc... Also with some (possible) compact forms like Bank[3][32] maning Bank[3], Address[32]

5. If you want to do entity enumerations, you could just do some simplified syntax like entities { dic, cloud } (with optional =number if they weren't sequential)

Now, one alternative syntax that looks funny but might be harder to code in:

Code: [Select]

# comment# <> defines a subscript, {} defines a namespace, everything inside {} refers to whatever preceeded italias init=0; #integer aliasalias dic=entity<0>; #entity alias<dic>script<init>{#define init and base scripts for 'entity<0>script<0>'  init {...}  base{...}}entity<2>script<1>init { ... } #defines just the init partentity<2>{script<3>=script<1>} # copy script<1> to script<3>#also you could do <> ranges, might go like <4..20> or <4->20>, and if you wanted to make it even more complex: <1..3,5..12,15,18>...  bank<3>address<32> ...

Yes, I like <> more than [], maybe because it's easier to access them in my spanish kbd.

 

[Synergy Blades]

Code: [Select]

if ($gold == 2872){...}

I think this is a good idea, a few questions; do we know the layout of the banks/addresses already, and what to do about creating aliases for things like plot progression variables which aren't exactly easily described in a short variable name? Anyway, if they've not been done, we could map them out seperately, and merge them together. Something as easy as gold is fairly easy to spot in something like delmin1 where you need 300,000 gil (hex 0x493E0) to buy the mansion...

Code: [Select]

if(<60>[17] == 4){   if(<60>[15] >= 93E0)   {   (buying mansion script here)...

 

[Cyberman]

Hmmm there was a dicusion of the maping etc. in the tech forum but no details were moved to the wiki.
I suggest searching the tech forum for the pertinent posts?
Cyb