Wow, is it already this late in 2013? I seriously underestimated how much two missing weeks in December (i.e. the pre-holiday season) can mess with a plan - I even missed the Mayan apocalypse
. Ah well, a plan is just a list of things that don't happen.
Some things did happen, though. I have finished fixing my branch, and I have also added support for deleting references by plugins (which was a fast thing - yes, not everything is infinitely complicated). Last weekend, I mostly worked on my plan to implement plugins moving references between cells, and I expect I will find some time next weekend to do it.
What we need to support are the following cases:
1) A plugin moves a reference from a parent cell to another cell. Should be straightforward.
2) A second plugin moves the *same* reference to yet another cell. This is not quite as straightforward, as there must only be one instance of this reference. (And it is the reason why there were "compatibility plugins" required for some combinations.)
3) A plugin makes a duplicate of an existing reference and tries to move the duplicate to a new position, but somehow ends up moving the original, leaving the copy in place of the old reference. This is the source of a nasty "vanishing references" bug in Morrowind that is almost impossible to track down - but fortunately, I have found the right plugin combination to reproduce it reliably. If I can make my branch reproduce this behaviour, it is a good sign that I got everything right. If I can find a way to fix it, it's even better - otherwise, I'll make it a task/bug on the tracker.
And that's all I have to say for now; more to come next weekend, when I am back at my development system.
Oh yeah, I almost forgot: A happy new year to everybody!
@zini: let me just attempt to lay out my plan for that nasty thing with moving references:
- Morrowind implements moving references by introducing an "MREF" tag before the actual reference data (plus some extra data fields for the target cell). I *believe* (i.e. haven't tested it yet) that moved references are always found at the top of the reference list, so we might actually parse it at boot time.
- I have mostly understood how the store rewrite works, including the static/dynamic split and the cell store. Now, here's my idea how to track moved references. We introduce two extra lists (maps?) per cell, one for tracking references moved from "this" cell to a different cell. If another plugin decides to mess with the same reference without knowing about the history of this specific reference, the code knows where the reference is currently residing, and can move the actual reference again. (e.g. plugin 1 moved reference from "this" to "other", plugin 2 moves reference from "this" to "yet another". However, the reference in "this" was already deleted by plugin 1, so we actually need to know that the reference to be deleted currently resides in "other", and has to be deleted over there.)
- The second list is used to store references moved into "this" cell. I am not sure if these references need to be made "active" (as it is called in the code) prematurely, i.e. before the cell itself goes active, but if this is the case, we definitely need another list for these references (i.e. what you suggested as a global list, just locally, i.e. on a per-cell base). Fortunately, moving references seems to be comparably rare (unless you consider "high-traffic" cells such as Balmora or Seyda Neen), so the additional work required to track this should be manageable.
Now that you have mentioned a global list of "special" references, we may actually need this to track persistent references or other kinds of "special" references. I have recently produced a few save files (.ess) just to get an idea on which cells are preloaded by Morrowind (in OpenMW, loading Bloodmoon.esm preloads several cells on Solstheim, so the basic ability seems to be there). But this can be definitely split from the main topic.
Since the task was just pushed forward yet another target version , I think I'll try and do as many of these sub-tasks as possible next weekend (I don't have planned anything more important... yet). And then, I'll try a new merge and hope that no more major revisions are required, so we can pull what is there to the master branch.