[Rails-devel] Some (multi-)undo related bugs

[Stefan F. <ste...@we...>]

A rather longish discussion of implementation details to follow. Mainly 
information for Erik.
Stefan

A side-effect of the new game history is that it allows to jump around between 
very different game states, switching round types and phases on the fly.
This acts as a advanced test on the undo mechanism and overall it works very 
well. However there are still some bugs to discover, which might also act as 
examples to avoid confusing the undo/redo mechanism:

* The toolTip on hexes was not updated correctly after undo/redos (still 
showing the tile information from the previous state), as the update was 
controlled only by the tile/token lay UI classes and not the game backend.
I shortly considered a ToolTipModel approach, but I realized that is much 
easier to update the toolTip at the time it is requested by the user.
I would still like to move the code to create the toolTip string from the UI 
GUIHex class to the game MapHex class to reduce the amount of processing and 
calls to the game classes from the UI class. 
Or is there a reason to avoid that, Erik?
It seems to me that now all UI elements update correctly after undo (I 
recently added a PresidentModel to update the president column).

* A more subtle problem arose from a 18EU test: After going back from a major 
turns to a minor ones during the green phase, the minor was suddenly allowed 
to lay a green tile.
This occured as the tileLayPerColour state change triggers a call to the 
operatingCompany  variable inside the OperatingRound instance. This variable 
itself however is not a state variable itself, but gets only initialized from 
the state variable operatingCompanyObject at the begin of the companies' 
action generation. Thus during the undo Rails assume that the tileLayPerColour 
request is still for the major company, as the operatingRound is not updated.

I admit that I have introduced the operatingCompanyObject myself and did not 
think about this problem at that time: The lesson to learn here is to strongly 
avoid working with non-state variables, which simply contain a reference to a 
state variable. This is an wide open door for bugs & troubles a long time 
later.
Either use the state variable directly or encapsulate it to a method call, if 
the state mechanism seems to unwieldy.