Re: Multiple ESMs and ESP support
Posted: 14 Jul 2012, 20:07
Phew, finally feeling better, and I actually found enough spare time to return to this project.
Okay, here's what I have been thinking up how to continue with the task at hand. Earlier in this thread, I had mentioned several points that will need to be tested/improved/modified in a broader context (i.e. with many plugins, NIF files etc. in use). My main goal when posting this was to summarize those points where supporting multiple plugins introduces additional complicatons (compared to a single master configuration), partially based on bits of code I had seen during my early hacking attempts. Just wanted to get these points out in a somewhat centralized way so they can be addressed before the project enters the release candidate stage. (There's a nice example how it should not happen. Before the Linux Kernel went stable, there were 15! development versions of V0.99, mainly because new issues kept emerging no one thought of earlier.)
- Scripts and nif files are indeed a separate subsystem and can be updated independently of my branch.
- Any GMST fixes that might still be necessary can be fixed when the need arises, i.e. when game rules are actually being implemented. Similarly, Dialogue fixes that might be required can be added as a part of the dialogue subsystem; before some code that actually needs it is available, any kind of fixes are purely theoretical.
- The terrain issue concerning unclean landscape seams can be fixed independently of the multi-esX code as well; my current hotfixes prevent crashes and make everything look reasonably well. Maybe it is better to keep building on my existing branch, than making extra branches from my branch.
- Merging references and tracking changes (i.e. some preliminary support for game saves) actually seems to be one of the more important things. As already mentioned, it seems to touch issue #28 (i.e. when to load cells and references), and I expect that it requires some refactoring of code at different points in the cell streaming code.
So much for my thoughts, and here's what I propose I could to next.
- I will generate (and post) a few test plugins that specifically trigger conflicts related to the points mentioned above. This should make further testing/fixing testing much easier.
- I still need to test a few more things related to moving references between cells and make sure it does not crash on load (haven't checked yet if some more exotic tags are already supported or not).
In a nutshell, after fixing what might still need to be fixed, I'll polish the code, merge with the latest master branch, and send a pull request, so that you can work with it without having to branch from my branch - which is possible but tends to make things more complicated. (Plus, from what I have seen during the previous months, code that is unfinished but somehow works a bit can be pulled to the master branch if it is sufficiently stable.)
When this is done, I am willing to have a deeper look into the "moving references" issue, trying to support this uglyness in the file formats (and maybe reopening #28?). I'll also look into other topics and see if I can provide help.
Okay, here's what I have been thinking up how to continue with the task at hand. Earlier in this thread, I had mentioned several points that will need to be tested/improved/modified in a broader context (i.e. with many plugins, NIF files etc. in use). My main goal when posting this was to summarize those points where supporting multiple plugins introduces additional complicatons (compared to a single master configuration), partially based on bits of code I had seen during my early hacking attempts. Just wanted to get these points out in a somewhat centralized way so they can be addressed before the project enters the release candidate stage. (There's a nice example how it should not happen. Before the Linux Kernel went stable, there were 15! development versions of V0.99, mainly because new issues kept emerging no one thought of earlier.)
- Scripts and nif files are indeed a separate subsystem and can be updated independently of my branch.
- Any GMST fixes that might still be necessary can be fixed when the need arises, i.e. when game rules are actually being implemented. Similarly, Dialogue fixes that might be required can be added as a part of the dialogue subsystem; before some code that actually needs it is available, any kind of fixes are purely theoretical.
- The terrain issue concerning unclean landscape seams can be fixed independently of the multi-esX code as well; my current hotfixes prevent crashes and make everything look reasonably well. Maybe it is better to keep building on my existing branch, than making extra branches from my branch.
- Merging references and tracking changes (i.e. some preliminary support for game saves) actually seems to be one of the more important things. As already mentioned, it seems to touch issue #28 (i.e. when to load cells and references), and I expect that it requires some refactoring of code at different points in the cell streaming code.
So much for my thoughts, and here's what I propose I could to next.
- I will generate (and post) a few test plugins that specifically trigger conflicts related to the points mentioned above. This should make further testing/fixing testing much easier.
- I still need to test a few more things related to moving references between cells and make sure it does not crash on load (haven't checked yet if some more exotic tags are already supported or not).
In a nutshell, after fixing what might still need to be fixed, I'll polish the code, merge with the latest master branch, and send a pull request, so that you can work with it without having to branch from my branch - which is possible but tends to make things more complicated. (Plus, from what I have seen during the previous months, code that is unfinished but somehow works a bit can be pulled to the master branch if it is sufficiently stable.)
When this is done, I am willing to have a deeper look into the "moving references" issue, trying to support this uglyness in the file formats (and maybe reopening #28?). I'll also look into other topics and see if I can provide help.