Sign in to follow this  

flexible way to save unique entity data between script calls

This topic is 3296 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Im looking for a flexible way to save data out (efficiently) from a lua script (e.g. a scripted finite state machine) on a per entity basis, between subsequent RunScript() calls... (however this isnt as simple aproblem as it sounds!) Ill explain a little bit of context.. For my game i have a CUsableObject class. Any instance of this class has a pointer to one of several CUsableObjectTemplate instances, each of which contains unique presets (like a certain name e.g. "OBJ_USABLE_DOOR", mesh "Door.x" scriptName "DOOR_OPEN_CLOSE.lua"). This gives me a really simple flexible way of creating new 'usable objects' (by just instantiating a new CUsableObjectTemplate object with different mesh/script presets etc). The problem i had was trying to keep CUsableObject very generic. The problem is that lets say i have two CUsableObjectTemplate objects. One has presets for a door and the other has presets for say. a computerPanel. I need to record for the door say.. several bools, e.g. currentlyOpen (true/false), currentlyOpening(true/false), currentlyClosing(true/false). However these completely dont apply to a 'computer panel' object. So the problem is i dont want to just jam boolean member variables into the CUsableObject class. I would also like to avoid just inheriting several new classes (eg. CDoor, CPanel) from CUsableObject, as this limits extensibility without new specifically coded classes. Obviously, the script for a door could internally contain global vars for the members mentioned above (open / currentlyopening etc), and the computerPanel could have equally appropriate ones within its script(bootingUp, On, Off.. or whatever) The problem is, many door and computerpanel instances could be calling this update script, each with different values for those globals, at any one time. I think i need to 'save' these variables from the luaScript to a CUsableObjectInstance between script calls! (i mean how is one instance of a door going to remember if it was say currentlyOpening or currentlyClosing when the script executes again next frame... I was wondering if i could do this with a luabind::object... Since it simply references a table containing all script 'globals'.. could i tell an instance to call a script, and then fill a luabind::object with the current globals, then next frame, set the globals within a script to the values stored within this 'savedglobals' object, then execute as normal? so for example each CUsableObject could just have a Luabind::object mGlobals, meaning it would work for all types? (im fairly new to lua and luabind!!) EDIT: hmm on second thoughts im currently only using one global lua_State. So even if i have two seperate luabind::objects and call getGlobals() on that same lua_State at different points in time, both of them persistently store and update the values... so as far as i see it i either a) need a seperate lua_State* per instance, and load/run the script seperately per instance (although this surely seems overkill, and just.. ugh... i mean.. its the SAME script so it just seems odd..) Alternatively could i give each CUSable Object a std::vector of pairs (say variable name paired with some 'struct' that is a union?) if ive read about them correctly a union can be cast as several different types? (eg. bool / float char etc). But this would allow me to have a consistent interface across all CUsableObjects..jsut one vector of these structs called say mScriptData. Then set the vars inside the script per entity, per call.. Which seems the worst of the two bad ideas lol... (somehow setting vars in a lua script every frame seems.. i dunno... ugh). [Edited by - NovaBlack on December 2, 2008 11:50:26 AM]

Share this post


Link to post
Share on other sites

This topic is 3296 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this