Huh. Finally duplicated that bug that jbluestein brought up
here. (I couldn't duplicate it previously since although the setup was adequately explained, the actual sequence of events relied on a demo to a hold I didn't have).
Definitely not fixed in latest build, and not surprising: the actual requirements to duplicate it are rather nasty. To trigger it, you have to remove a piece of edge briar that is connecting two groups of briar. This is difficult, because most of the time, a true edge simply won't be connected in that manner (immature briar created via pits doesn't count in this case, since they're not true edges).
However, this is the way it was likely happening in the demo: you have to trigger a recalc first by cutting some piece of connected briar anywhere in the room (must be mature, unless it's a piece of briar next to a pit that has become immature again). This recalculates all the briar as normal, sorting the briar into normal components and edges.
But until next growth, we have some possible problems on our hands. It's now easily possible for two groups of briar to only be connected by some immature briar. That piece of briar could be a true edge, or it could be an edge that used to be mature briar. In either case, it doesn't matter: the recalc changed it into a pure edge, and thus doesn't have an entry in the briarComponents list. However, it was still a piece of briar that allowed GetConnectedTiles to add the briar on the other side to the main group.
If we remove this edge, it won't force a recalc (because it's an edge and doesn't have a component entry, so we assumed this was safe). So even though the groups are no longer connected, without a recalc we have no way of splitting the two briar groups up.
Anyways.
Two things need to be done, it would seem.
1) Deleting edge tiles must force a recalc. This is pretty easy to fix: just set
this->bRecalc to true in the
plotted subroutine when an edge is cut. We do this because it's more than possible to get us into a situation where a true edge is the only thing that's connecting two groups of briar, even if we preserved briarComponents entries.
2) Even with the above fix, it's probably still a good idea to keep entries that should've been in briarComponents before, so long as they're still connected. To do this, I've been trying these lines:
Code Snippet 1
CCoordIndex_T<USHORT> oldBriarIndices;
std::vector<CCoordSet> oldBriarComponents;
oldBriarIndices = this->briarIndices;
oldBriarComponents = this->briarComponents;
Code Snippet 2
//This is the current state of this briar root's connected component.
this->briarEdge.push_back(edges);
//Before we subtract edges from briarComponent, we need to remove
//all previous components from the coord set.
edges -= oldBriarComponents[oldIndex-1];
briarComponent -= edges;
this->briarComponents.push_back(briarComponent);
This way, the edges coord set has any valid Components removed from it before we subtract it from the new briarComponent, so we should end up with the correct set of tiles in the end.
===
Again, after installing both of these fixes into Build 48's source code, I'm not seeing any demo breakage in my myriad of briar rooms or Under the Library, and the few quick briar test rooms I created to attempt to recreate the bug under fixed conditions now seem to be working fine, so looks like the fix works on my end. (I realise that 15 minutes of quick demo browsing and room rechecking is not hardcore testing of this fix, but it's passing the first round of testing, so that's enough to at least submit the patch for further scrutiny)
Hope that helps.
[Last edited by TFMurphy at 09-20-2007 06:28 AM]
is a considerably more stylish way to express sarcasm than 
, because everybody uses 
The thing is that TCB wasn't working before I upgraded either, so I didn't see any need for doing a backup. And my original 3.0 file is looong gone. This time I updated from one patch to another.
