RE: [GD-General] Scripting Systems
Brought to you by:
vexxed72
|
From: Timur D. <ti...@cr...> - 2004-01-31 01:35:11
|
Lua is wonderful language when used nicely :)
But can stab you in the back for small errors...
I don't think it even possible to find a solution for "missing" members,
After all Lua as most script languages are weak typed, and this benefit
you ease of real-time member modification against rigid but safer C++
strong typing.
Restricting things like v.zz =3D something; just doesn't make sense...
this is a perfectly valid way in LUA to make a new elements in the
table, one of the core functionalities, and if you disable v.zz =3D ...
you will not be able to do v["zz"] =3D .... And so on...
Usually this kind of errors can be easily catched in run-time, reported
to user and can be fixed without even closing the game, (if game support
reloading of scripts)
As for debugging... I never actually even used our build in lua
debugger.. fastly adding log, reloading scripts and seeing what's
happening is usually simpler, and if scripts become so complex that you
have to really debug them, then I guess you'll need to revisit the way
you use Lua, as it very inefficient and error prone (Due to reasons you
mentioned) to do large chunks of code in it.
P.S.
v =3D { x =3D 0, y =3D 0, z =3D 0 } -- This is a code you NEVER want to =
see
inside your frequently executing functions, Lua is fast, but at the
moment GC kicks in you pretty much screwed, don't sure about latest Lua
GC but in previous versions GC time was depended on the amount of
globally allocated lua objects, and for game it can be very large
amount...
You would probably want, to make a special function that will dump lua
stack on every Lua allocation, and try to go and eliminate Any
allocatins which occur when game running normally (without too many game
events occurring).
I managed to get 0 lua allocations when game is just running (when you
not shooting, or doing special things...),
Without doing so , ~50ms stalls every few seconds, can be quite usual..
_____________________
Timur Davidenko.
Crytek (www.crytek.com)
-----Original Message-----
From: Brian Hook [mailto:ho...@py...]=20
Sent: Thursday, January 29, 2004 2:47 AM
To: gam...@li...
Subject: Re: [GD-General] Scripting Systems
> 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.=20
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=20
language, and since it doesn't even comprehend the idea of user=20
defined types, "type checking" is kind of a no-op. =20
What we'd need is a preprocessor that uses a convention where any=20
uninitialized element accessed out of a table constructor or=20
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.=20
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.=20
Yep.
Sounds like we're in the same boat but without a solution =3D|
Brian
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7
|