Re: [Rails-devel] Bug Report 1830 Rails1.7.2

[Erik V. <eri...@xs...>]

Stefan, below I'm returning one sub-issue back to you...

> -----Original Message-----
> From: Mike Bourke [mailto:com...@ip...]
> Sent: Wednesday, April 18, 2012 7:27 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Bug Report 1830 Rails1.7.2
> 
> While playing a game of 1830 (simple Option) recently, I noticed a pair of
> subtle bugs in the game system. Log files for these bugs are not available
but
> saved games are, and I have verified that the bugs are reproducible using
the
> specific techniques described below.
> 
> Bug #1: Problem ending company Op round when president has been forced
> to sell shares.
> 
> Details: The B&O president has just been forced to sell shares in order to
> raise the capital for a diesel. Play then moves to the newly-launched C&O,
> but the game freezes. C&O never gets to lay track, the map window (top
> left) reads "lay token" and "no token" and both choices are greyed out, as
> are the buttons at the bottom of the map window ("Done", "undo", "redo").

This kind of behaviour is typical of an uncatched exception.

> However, as soon as "save game" is performed, the problem clears itself.
> 
> To reproduce this bug:
> 
> 1. load 1830_20120415_0220_M4.rails.
> 2. In the game report, locate and click on the entry that reads "B&O does
not
> pay a dividend", then "play from here."
> 3. In the map window, click on "buy train". Note the relative order of L&N
> and C&O shares.
> 4. Sell 2 shares of PRR, 1 share of NYC, and (critical) 1 share of L&N.
Note that
> the relative order of L&N and C&O shares have changed because of the sale
> of shares.

But this is not (yet) reflected in the OR window.  See below.

> 5. Click "done".

And indeed an exception appears on the console:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at
rails.ui.swing.MapPanel.scrollPaneShowRectangle(MapPanel.java:113)
	at
rails.ui.swing.ORUIManager.setMapRelatedActions(ORUIManager.java:238)
	at rails.ui.swing.ORUIManager.updateStatus(ORUIManager.java:1677)
	at rails.ui.swing.ORUIManager.updateStatus(ORUIManager.java:1520)
	at rails.ui.swing.GameUIManager.updateUI(GameUIManager.java:562)
	at
rails.ui.swing.GameUIManager.processAction(GameUIManager.java:329)
	at rails.ui.swing.ORWindow.process(ORWindow.java:229)
	at rails.ui.swing.ORUIManager.processAction(ORUIManager.java:434)
	at rails.ui.swing.ORPanel.actionPerformed(ORPanel.java:912)

ORUIManager line 238 has:

                        mapPanel.scrollPaneShowRectangle(
                                NetworkVertex.getVertexMapCoverage(map,
companyGraph.vertexSet()));

and the rectangle passed is null, which causes the exception.
As a quick fix I'm now checking the rectangle in
MapPanel.scrollPaneShowRectangle, and do nothing if it is null. 
This fixes the immediate problem.  

I don't know if NetworkVertex.getVertexMapCoverage() returning a null
rectangle should be considered a bug.  I must leave that to Stefan.

There still is the underlying issue that the game engine does not change the
OR order immediately. 
In the game engine, the OR order is only checked at the point that a new
company turn is about to start.
Independently, the UI checks after every OR action if another company has
got the turn, and if so, it checks the current operating order and recreates
the OR panel grid if it has changed.
So there is no direct link between engine and UI on the OR order.  I
wouldn't be surprised if this disconnect would turn out not to be fully
undo-proof.

> Bug #2: Incorrect display of company names when returning to an earlier
> action and clicking "play from here".
> 
> Details: shortly thereafter in the same game, the L&O took its op round.
> Despite the "unlimited tiles option being turned on, the game would not
> permit a standard yellow city tile (57) to be placed at location H4, the
L&O's
> home base. This appears to be due to an incomplete processing of past
> actions in the "play from here" function, specifically stock movement
> resulting from the forced sale of shares.
> 
> To reproduce this bug:
> 
> 1. load 1830_20120415_0224_M2.rails
> 2. In the game report, locate and click on "M2 sells 1 10% certificate of
NYC to
> pool for $50", then "play from here".
> 3. In the Map window, note that the relative order of L&N and C&O shares
is
> the same as before the B&O president sold a share of the L&N even though
> the game report shows this event as having occurred.

That must also have been the case the first time that this action has been
performed.
At this point, the operating order has not yet been checked, so it is reset
to the old one, both in the game engine and in the UI.

> 4. In the Map Window, click "done".

And now the game engine (correctly) thinks that C&O has the turn, but the UI
does not reflect that, and appears confused in the following steps.
It is not clear to me why the UI order does not change in this case.
Perhaps it is related to the fact that game playing has stepped back to a
point in the middle of emergency money raising, rather than before that
process, as in the first problem.

> 5. Game will not permit L&N to lay a tile in it's home base. The game is
> highlighting valid tile lays for the C&O (which SHOULD operate now) and
will
> permit either of those tiles to be layed.
> 6. If you lay a tile, click "no token", and buy a diesel, it is the C&O
who gains
> the train. Click "done".
> 7. Play then moves to the C&O according to the (incorrect) map window
> display, and all actions appropriate to the L&N's turn (tile lay at H4,
purchase
> of a diesel etc).

One possible approach could be to make the OR order an independent state
variable in the game engine, and have any change immediately trigger an UI
order update.
That's a similar approach as I have recently used to address player order
changes in start and stock rounds.

As emergency money raising is handled in a sub-round of the StockRound type,
I don't think that it is feasible to change the OR order immediately in the
UI. 
But the current approach to check the order at the start of a new turn
should remain sufficient.  

I'll continue sorting it all out later.

Erik.