openmw.org

setUp() is in private part already, erase() still in interface, bug is resolved.

2. The erase functions are pointless. We do not erase records. What we will have to do at some point is to wipe the whole dynamic ESM store (when loading a saved game). And as usual the player record requires special treatment. Not sure yet how to deal with it. I expect even uglier hacks. Anyway er...

Basically task is done, but it desperately needs review and intense testing. Code base in my 'store' brach on github. When everything becomes okay, I'll create pull request after 0.19 release (next/master merge, rebase).

I have a question about dynamic records ids: should it always be generated or it make sense to left an option to adjust it? Cells container throws exception on id collision, but other aren't so strict: search starts in dynamic, so it is possible to override existing esm/p values.

I'm a bit confused with World::createRecord(ESM::Cell &) - should it actually exist? I remember Zini mentioned it won't hurt to have dynamic storages for every record class, but I don't think it makes sense for data that is hard to create properly in-game.

P.S. Sorry for it takes so long.

Why not just download ogre, mygui and bullet sources from respective sites and compile them? Using wheezy myself.

In addition to bugtracker. Since dynamic and static storage may have different containers, I'd prefer to hide currently public members at all. But to make this it is good to know what exactly we're expecting from store. Searching records, ofc. What else? Iterating through entire collections is used ...

Actually, purpose of this thread is to describe some solutions made that affects record saving debug, because I'm unable to distinguish wrong things from improvements. First, it is MGEF MEDT subrecord flags - they're adjusted on load with some data, so it differs from original. Is it correct to save...

ElderTroll wrote:Also, has greye been around lately?

Sure, but still have to do university stuff right now, so progress goes slowly with my task.

Don't see a reason to use pathgrids with navmeshes in any way except for patrol waypoints.