Parsing array names.

[Tyhm]

this.#L[0] is the 0th index of "this.#L", not the 0th index of "this.level13.graal". I rather think it should be the other way around, such that I don't have to write up either a different section of coding for each level or swapping arrays or hashing everything into one huge array, none of which are particularly efficient if memory serves - either a waste of code space or a waste of memory (for the temp "current" array or the hash indices)...

[Jeff]

Agreed.

I've had terrible trouble with things like this.

[Kaimetsu]

To change it would be to change the entire foundation of scripting. Allowing variable names to be specified by strings would make the engine far slower, because Graal would need to interpret the script dynamically - it would need to be converted to bytecode 20 times a second so that '#s(blah)' could reliably be converted to the correct token for 'this.somevar'. Sure, there could be optimisations, but it all amounts to one big headache for Stefan.

Perhaps it would be better to make a function, like:

var([insert string here])

Returns the variable with name equal to the string, so you could go:

var(this.#L)[4]=123;

That way it would be a special case handled by a special function, instead of the principle being applied to the entire scripting engine.

[Tyhm]

Wow. And I thought Stefan's solution (classic oldschool memory access - one array, table of addresses) gave me a headache...

[Kaimetsu]

Well, I guess I am making assumptions about how the scripting engine works. If I'm wrong about it and the change really would be quite simple then cool, no problem. I was under the impression that variable names are discarded at psuedo-compilation and thus that big changes would be needed to make it possible. Even still, though... What about basic error checking? What about conflicts?

Let's say my string list is like so:

string=this.var

In my script is the following:

showimg #s(string),somepicture.png,3,5;

Does it throw an error because the person has tried to use a string where the index should be? If not, we cut out on a large part of the static error detection process. What about this:

say2 #s(string);

In the normal interpretation this would be fine - there'd just be a box saying 'this.var'. If your changes were made then what would happen? say2 would be handed a variable instead of a string, and it wouldn't know what to do with it. Would all the functions of this type need to be altered? I don't know, but it'd be a bad thing if they did.

If strings can suddenly sometimes be variables then static error checking/compilation etc are thrown out of the window. It's much nicer if there's a function that takes a string and returns a variable - only one function needs to be written and nothing else needs to be changed.

[adam]

Originally posted by Tyhm
Wow. And I thought Stefan's solution (classic oldschool memory access - one array, table of addresses) gave me a headache...

>.< I do that all the time.

*then again I do the real oldschool memory thing in my digi electronics and microprocessor class*