Hi 'Roo:
I think the best way to describe how it works is to think about it this way. With load image, you can load images stored in an external file (As opposed to using data statements in code). Same goes with objects, music etc. Unity simply allows you to put
actual program logic in external files.
I can imagine Unity would fit into Quikly how scripts are used in FPSC. Imagine a game maker where, once you've laid down your level, you can then write a little bit of code to control how something moves, a trigger is activated, or how a level is won. Normally, you can't do this with DBPro. All code is garbled, compiled nad assembled into machine code - you can't just load a string of code and run it. Well, with scripting you can
Try the FPSC demo (if there is one?) and you can see a good example of scripts in use in a game maker there.
Individual questions...
Quote: "1: Does it allow control over EVERYTHING - IE users could manipulate things they didn't mean to, cause program crashes, etc? Because that could be a nightmare when writing a file to hdd for example. Or for multiplayer games people could use it for "action replay" style cheats to make themselves invinsible etc? I think a complete lack of control over how something could be modified is a scary prospect to me, but perhaps I'm envisioning this wrong?"
Nope. The Lua environment which scripts run in is completely detatched from the DBPro environment. All your users do is write functions, code etc. You then write bits of DBPro/Lua code which link the two. For example, if in Quikly somebody attached the following script to a portal entity (this is just hypotheses):
This would call a Lua script written by yourself (a sort of API, if you will), which then passes a message back to DBPro telling the DBPro app that the game should be won:
function WinGame()
SendMessage("GameWon")
end
And in your dbpro main loop you'd have this little loop checking for GameWon messages and acting accordingly
while lua next()
if lua message desc() = "GameWon" then end
endwhile
As you can see you're completely free to let users do what they want. There are a few DBPro commands available in Lua, in case you fancy writing AI in Lua and want to do it the dodgy way, but they're just your primitives - position / rotate object etc. and - don't quote me on this - but I think you can remove functions from Lua at run time anyway (there's most likely a way given how functions are stored - if you want I can research more).
Quote: "2: How would a user know how dbpro was referring to everything? For example they may wish to move an enemy but don't know what object number or limb number to use?"
Pretty much answered above - you can do it how you want. If you want to store object numbers in Lua globals then people could ge hte relevant numbers from there. I recommend however completely separating 3D from Lua - and instead provide a few hook functions like I showed above.
Quote: "3: Presumably picking something up and moving it via LUA would mess up Newton collisions and physics? 99% of what is moved in Quikly is done using physics..."
Same as above. Just write the movement routines yourself
Quote: " I'm just trying to find a reason to use it instead of writing my own scripting language read from a text file which I'd have full control over"
The main plus point is Lua is a complete, commercial quality language available from the get go. It's fast, small and very easy to get set up. You can write your own if you want, but to get all the parsing and execution stuff written would take ages - especially for a language as extensive as Lua (OOP, dynamic arrays, complex iteration etc) - I've tried myself!
