If I understood the procedure correct, I'll still need write access at github before I can push my own branch (they call it the "list of collaborators" or something), so here's my github account name: mark76 (same as here). If this should not be required, I must have missed it.
Anyway, back to the main issues. My last post (30 minitues before leaving to said conference) was not as detailled as it could have been, so let's try it again: Multiple esm/esp files touch pretty much everything, without actually introducing a new subsystem; it's more like a boundary condition/design issue that requires specific hacks throughout the engine. I have added basic support for loading multiple esX files (as selected by the launcher, which works out-of-the-box), and verified that *most* stuff works as expected:
- Newly created objects introduced by separate plugins work as expected.
- Modified objects mostly work as expected (but see below for exceptions).
- Deleting entries from a parent file seems to work as expected (but it required a hack in recstore.hpp, to delete entries from the individual lists).
- Undeleting previously deleted entries also seems to work as expected, without having to hack 20-30 individual "loadxxxx.cpp" files or refactoring something else.
In the testing phase, some issues emerged. Textures on Solstheim were hopelessly wrong. I knew from my own project that each plugin introduces a separate list of terrain textures, so I tried if I could quickly port this (which works now, but required some more hacks between the esm parser, the recstore, and the texture loader). Then I got more assertions on Solstheim due to some "i > size"-type conflict within the landscape loader. I had a deeper look at the code and found that (in a nutshell) the terrain importer is doing something involving neigboring cells, and does not take into account yet that the neighboring cell may use a different terrain palette. And this is where I stopped for now, as it got complicated. It looks nice, but I'll need help by the terrain gurus to finish this aspect.
In fact, I know of (at least) six existing subsystems that may need to be adapted for one reason or another to support multiple plugins (dialogue, NIF renderer, landscape textures, GMSTs, references, scripting), and this list might not even be complete. The basic code is in place, it seems to be sufficiently stable to push it on the repository for other people to toy with (and maybe pull it into the main branch, so that we can address a bigger list of beta testers). Then we can collaborate to get the additional work required done. And that's what I meant in my last post - it is almost possible to start working on the individual subsystems mentioned above. It may still become somewhat messy, though, with many different hacks required throughout the engine. The way I see it, I mostly know what needs to be done in these subsystems, and other people can help in finding out how to actually implement this.
This also explains why I haven't tried to push something earlier - I knew that *some* things had to be addressed/checked to prevent semi-random crashes, and I'm not the type of person who pushes something that is known not to work.
One final point that will need to be addressed at some point is the ability to read and write (and select) save files, which are essentially just plain old plugin files. I did not find anything specific to this in the code (except for some save-related hacks in ESMReader::open), so I was wondering what kind of plans for this feature do already exist. And this is what I meant with my question whether anything related to this does already exist - moved references is just the most complicated aspect of this. Right now, my plan is to tackle this feature (i.e. reading/writing saves) next, as it is the point that should require the most work.
I'll push my own branch to the repository when I get write access (and after integrating the most recent changes from the main branch). I'll post some more details on what needs to be done in the individual subsystems in the issue tracker in a few minutes. Feel free to have a look at it, and if you see something you can resolve/help resolving quickls, feel free to say so.
And that's it, essentially. Feel free to correct me if you have a different opinion on any of these points
.
GCC is way too permissive on some declarations and functions constructions, moreover some code generation in Linux is memory-leak free, where in windows it is not, because of the way the stack and return calls are handled (subtile and very frustratic at debug time).
