Re: [GD-General] Scripting Systems

[Brian H. <ho...@py...>]

> 1. We need some sort of Lint for Lua. This is hard to implement
> because you can dynamically create table members. It's advertised
> as a feature but when I type "nname" instead of "name" it's an
> error not a new member. 

Right, but it doesn't know that.

> guessing they don't either, but isn't there a better way to handle
> this? (I know I can trap the __index method but I'm talking about
> finding errors before runtime)

Run-time is the only way to do it.  Lua is a dynamically typed 
language, and since it doesn't even comprehend the idea of user 
defined types, "type checking" is kind of a no-op.  

What we'd need is a preprocessor that uses a convention where any 
uninitialized element accessed out of a table constructor or 
declaration is definitely bad.

v =3D { x =3D 0, y =3D 0, z =3D 0 }
v.zz =3D 3 --<< BZZZT!

> 2. Debugging is a pain, although we have designed a solution. We
> are implementing a small, simple http protocol and hooking a script
> debugger to it. The game communicates to the debugger via http so
> we can debug PS2, GCN and PC scripts. 

That's either crafty or gross, I'm not sure yet. =3D)

> 3. Incremental builds. We have converted our scripts to game
> objects (not to be confused with OO object programming). Each
> function is therefore unique and can be compiled and re-uploaded to
> the VM on-the-fly and so you can effectively pause the game in the
> debugger and replace a value, table or funciton anytime.

That's exactly what we're doing as well.

> make for some interesting bugs in it's own right, but without it
> you end up having to play the game for minutes just to get back to
> a place where you want to test something. 

Yep.

Sounds like we're in the same boat but without a solution =3D|

Brian