http://wiki.openmw.org/index.php?title= ... the_source
the 'git submodule update --init' will get you your shiny.git clone git://github.com/zinnschlag/openmw.git
cd openmw
git submodule update --init
This has bitten me too.
the 'git submodule update --init' will get you your shiny.git clone git://github.com/zinnschlag/openmw.git
cd openmw
git submodule update --init
That is only after loading the ESX files. During the load process just copy and delete manually. I suspect we need to keep track of cell changes during the load process. Maybe a separate global table (listing source cell, destination cell and reference)?- I need to make sure that references moved into new cells are loaded with this new cell instead of the original one. This is more difficult than it sounds - if we were to move full ownership to the new cell, the result might be a duplicate of the corresponding object. There is supposed to be support for moving references between cells in the engine now, but I haven't found the corresponding lines yet.
Yeah, that is unfortunate. I had hoped that the ESX loading would be finished sooner. And because of other complications we had to do the store rewrite much earlier than I had planned, which finally lead to this situation. That's why I proposed splitting your task up and getting parts into the master branch early (would have prevented most of the problems you have now).Unfortunately, recent changes in the master branch did, again, break my work. Just recently, the file reclists.hpp was removed, being replaced/merged by store.hpp. After what I thought to be a regular merge, about 30% of my hacks (all in reclists.hpp) were gone, and I had to do what I had just finished a second time. All hacks outside of reclists.hpp/store.hpp have been restored. However, something has been changed in the internal workings of the global object store, which I haven't fully understood yet, so - you know the game - it will take longer than expected. (I actually hoped I could have everything ready until Christmas before this!)
I assume you are referring to my task reorganization proposal above. Its perfectly okay to merge the code for loading only certain record types (and ignoring the rest). Basically do all the non-special cases and ignore the special case records for now.There's another point I would like to bring up. Where should we actually draw the line between this task (multiple plugins) and secondary points (e.g. dialogue merging)? As this topic (multiple plugins) touches many existing subsystems, drawing this line isn't easy. I suggest that we could draw a line when all references are interpreted correctly, and when all (well, most) plugins are loaded without errors. This should allow to pull my branch to master without too much additional delay (read: before some other commit breaks my hacks again).