Including mounted objects in MissionGroup.save()

#1 what about using a sqlite db for persistence? Load/save player data direct from the database during entity load (during onAdd?) Inventory system was based upon a very old MMOKIT from Dream Games...

#2 Would that be overkill for just something like quicksave? I'm not sure about the specifics of database stuff.

It's a tricky problem... Maybe some form of nested entity creation? Like when you save a SimGroup with objects declared 'inside' it, they end up being put in the group. Maybe you could modify things such that objects created 'inside' the definition of a non-SimGroup object were mounted to it instead (and when saving an object, it writes all of its mounted objects inside its own declaration).

Though that might require modifying some pretty low-level code... though the work has been done in some form or another, because that behaviour exists with SimGroups.

There's probably a simpler way than that, actually - I just can't think of it :P.


Oh right... maybe just expose mMount.object to scripts and have that saved off? Then in onAdd you just mount yourself to the object that you were loaded with.
Catch: object IDs probably won't be the same when saving as after loading. So maybe that approach only works with named objects.

#3 I just like databases (I teach AGT1, Databases at NHTV in the Game Application and Design program). sqlite is fairly light-weight and easily integrated. In fact, I don't really hard code datablocks values anymore, pulling data at load-time from a table...

#4 @Cyberkada: Having a comprehensive database might be a bit much for my immediate needs, but once integrated into the app, I could see it being very useful. I'll look into that sqlite. I've used DBs a lot, but only the flat-file type in this kind of app.

About saving mounted objects in onAdd() - who's onAdd() is that? If the object is then unmounted during the course of a mission, would it need to be "unsaved" ?

Currently I have maybe two or three object classes where I'm interested in restoring mounted items on a mission load. The idea of exposing the mMount.object, or maybe the mMount members to script sounds good. Also, I don't think I'll need to store any specific objects (that is, by name); I can probably get away with just the class names of the mounted items.

@Daniel: The nested-style save for mounted objects you describe is exactly the right idea. Maybe if I stare at the code long enough, it will come to me how to do it!

#5 Looks like this feature is being implemented in T3D - good show, GG! Not sure how they'll go about doing it. I've been thinking of revamping mounting for a while now... it's really annoying when I think of something and then GG comes out and says they're doing it in T3D :P.

Quote:The nested-style save for mounted objects you describe is exactly the right idea.

On thinking about it, the named-items route seems to be easier, but the nested-items route seems like it would be more robust, intuitive and flexible. Thing is, I'm not that familiar with how objects are saved into .mis files (which I assume is how you save missions - by saving the MissionGroup into a .mis file). So I guess the idea would be to not add mounted objects to the MissionGroup, but when an object in the group is saved, it saves all the objects mounted to it.

It'd also be really, really nice to have a visual interface for mounting within the world editor, if mounting is to be made an integrated part of world-editing. [Hint hint, GG ;)]

#6 try a temp file of some sort that would function as a holding place for player settings (similar to the prefs.cs file). When the player saves, the names of mounted items could be stored their and then reloaded when the mission is resumed (give or take some psuedo code)

#7 Cyberkada, please I have to speak with you.
Please read the last message of your own post, and answer me there if you want:

http://www.torquepowered.com/community/blogs/view/14616


Thanks =)