Partition: forkNode() issues.

[searing]

From Steve:

partition.forkNode doesn't seem to work. If I use forkMove to make a move it works fine, but if I use forkNode three times to do out the same move, it doesn't seem to work. I made a queen spot empty, then put a queen on the spot above, then did a getReachableIndices, and it seems that the the algorithm thought that the queen was still where I left it. It didn't return any reachable indices in the direction I tried to move from.

Let me know what you think

---

I will look into it this afternoon when I have time, but for now, keep in mind that forkNode does not actually modify any data. It should return a new list of Partition objects which have the updated data. The list is required because a split may occur, creating multiple partitions.

If you try:

myPartition.forkNode(args1);
myPartition.forkNode(args2);
myPartition.forkNode(args3);

what you're really doing is creating 3 new partitions with the same parent, like this:

      myPartition
    /      |      \
args1    args2    args3

Of course, there could also be a bug in there. I just want to make sure it's an error with the implementation and not with the use.

[Dr-Steve]

  List<Partition> _TP1 = _state.forkNode(BQindex, NodeState.EMPTY);
  _temP1 = _TP1.get(0);
  List<Partition> _TP2 = _temP1.forkNode(_move, NodeState.BLACK);
  _temP2 = _TP2.get(0);
  //Get shots you can make from the first possible move
  _shots = _temP2.getReachableIndicies(_move);

I have been grabbing the new partition after the forks then forking the new one.

[searing]

I'm testing that code now. This is odd - it seems to correctly mark the _move index as BLACK, but it doesn't mark the original index as EMPTY.

[searing]

I found the issue. It had nothing to do with NodeSet. The Partition was removing the changed node from the set of enclosed nodes. This causes the partition to mark it as BLOCKED. Thus, every change would cause something to get BLOCKED. This has been fixed.