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 |