rails-devel — List for discussion of Rails development

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation hangs game

[Stefan F. (web.de) <ste...@we...>]

Erik,
just a follow-up, which I forgot to report from my code review:
In the brown section of the stock market, several certificates can be bought 
in one step. Actually the UI and the action in principle seem support that. 

However even if one buys several shares, only one gets moved into your 
possession, but you still have to pay the full price :-( 
On first glance the issue could stem from the fact that the action only allows 
to store the id of one certificate bought. 
This is the flip-side of the sell shares action, which works for several 
shares, but does not store any ids.

Most likely it is easier for you to fix that as you know those actions much 
better and it might have sideeffects to the changes for 1835 with all those 
special certificates.

Stefan

On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> Stefan,
>
> Thanks for your analysis. Yes, I agree that Rails should be further
> hardened in the aspects you mentioned.
> Anyway, I think I'll remain in bug-fixing-and-hardening mode for some time!
>
> Erik.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Wednesday 23 June 2010 23:35
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
> duringCGRformation hangs game
>
> Erik,
> I agree that Baden is more obvious case/bug and thus easier to fix and
> identify. In that case only the ordering of a stack/list was not observed
> during undoing or transfer. Thus it was for example to the fix of the
> PriceTokenMove, where the stack order is stored and allows the undo to
> preserve the previous ordering.
>
> The case from Aliza's savefile is less obvious, much more tricky, as it has
> to
> combine several conditions to create the problem.
>
> In that case three major ingredients are involved:
> 1) Actions on interchangeable objects
> 2) The first action stores only the object property, whereas the other
> action
> stores the object id
> 3) Undoing the first action and redoing it, chooses a different object
>
> Your suggestion will only work if the first action chooses the object in a
> deterministic way (thus for example from an ArrayList). However the
> portfolio
> class contains some HashMaps and on the first glance I suspect that in some
> cases actions retrieve their objects from those non-deterministic
> collections. In that case this has to be replaced by an ordered collection,
> before the undo mechanism makes sense.
>
> My take is to try to learn from that and try to build several layers of
> protection:
>
> A) Everything in Rails that changes any state should work
> deterministically.
>
> This includes cases that operate on objects, which are interchangable (like
> share certificates, trains, tokens, tiles).
> For non-interchangable object this already a prerequisite for the automated
> testing.
>
> B) Interchangable objects should be identified by an identifiers. Actions
> working on those should use those identifiers instead of the object
> properties. (Thus do not store selling 20%, but which certificates
> exactly).
>
> This also helps in the case of certificates with different share values.
>
> C) Undo of actions should keep the ordering of objects, including the
> ordering
> of interchangable objects.
>
> Another idea might be to store the undo actions in the save files and
> replay
>
> those after the reload.
>
> All this is not done in one step and requires a deeper code review, but I
> suspect that similar problem might be responsible for some of the
> unaccounted
> broken save files. Obeying rule B) might also required breaking the save
> file
> compatibility, so this might be a good task for Rails 2.0?
>
> Stefan
>
> On Wednesday 23 June 2010 21:39:42 Erik Vos wrote:
> > Stefan,
> >
> > Superficially the Baden issue looks similar. The problem there was that a
> > buy from IPO always took the top share. Undo does mix up the share order,
> > but another problem was even worse: moving the Baden shares from
> > Unavailable to IPO reverses the share order!
> >
> > I have fixed the Baden case by giving all certificates a sequence number
> > (index) per company, and checking that a buy from the IPO always takes
> > the one with the lowest index. This makes at least IPO buy actions
> > independent of the list order.
> >
> > >From a first glance to Aliza's problem I'm not sure how far the above
> > > can
> >
> > explain that issue. If I'm right, problems have also been reported about
> > token order errors after Undo. Perhaps we should think about ways to make
> > Undo exactly restore any previous list order, for instance by recording
>
> the
>
> > old list index in the Move.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Sunday 20 June 2010 20:11
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during
> > CGRformation hangs game
> >
> > Erik:
> > some follow up on the issue with the broken save file in Aliza's bug
> > report: As I had the hope I could easily make the file at least
>
> reloadable,
>
> > I believe
> > I found a trace to the potential problem:
> >
> > The save file breaks at the following action:
> > Action 378 delft: SellShares: 1 of 10% CPR at $110 apiece
> >
> > But delft should still have the share, as he bought CPR twice before (at
> > actions 238, 244) and sold only once (action 323).
> >
> > The problematic action is the following:
> > Action 330 azure: BuyCertificate: CPR 10% share from Pool price=$110
> >
> > which gets executed on the reload as:
> > 2010-06-20 19:58:33 DEBUG  Action (azure): BuyCertificate: CPR 10% share
> > from
> > Pool price=$110
> > 2010-06-20 19:58:33 DEBUG  >>> Start MoveSet(index=330)
> > 2010-06-20 19:58:33 INFO   azure buys a 10% share of CPR from delft for
> > $110.
> > 2010-06-20 19:58:33 DEBUG  Done: Move PublicCertificate: CPR 10% share
>
> from
>
> > delft to azure
> >
> > Thus Rails assume that the certificate bought stems from delf instead
> > from the
> > Pool! It seems that action does not correctly identify the certificate
> > bought. I checked that this is defined by the certificate ids.
> >
> > Thus I guess, that due to some undo the stack of certificates got mixed,
> > either those in the IPO or in the possession of Delft (similar to the
>
> Baden
>
> > issue in 1835). Thus in the game played the other certificate in the
> > possession of Delft was sold to the Pool in 323 and then on the reload
> > Rails
> >
> > moves the wrong one out of Delft portfolio at action 330 instead getting
> > that
> > out of the Pool.
> >
> > I hope this is of some help, however I do not know how to resolve that
> > issue
> >
> > easily, as I do not know, what is required to keep the ordering of
> > certificates in portfolios "undo-robust". It might be the better solution
> > in
> >
> > the long run to identify the certificates by their properties (thus share
> > percentage and previous owner) and be agnostic about which one exactly to
> > take.
> >
> > At least one should check that the current owner of the certificate is
> > identical to the previous owner implied by the action, but this does not
> > fix
> >
> > the reload problem.
> >
> > I have attached two trimmed save files, one before and one after the
> > error occurs.
> >
> > Stefan
> >
> > On Sunday 20 June 2010 14:54:55 Stefan Frey wrote:
> > > Aliza:
> > > thanks for the savefile.
> > > Most of the issues have to be addressed by Erik, but for the revenue
> > >
> > > calculation I can give some feedback:
> > > > (1)  When I undo a tile lay and do something else, the route is not
> > > > recalculated.  If I don't pay attention and calculate manually, I get
> > > > the run from the previous OR.
> > >
> > > Unfortunately I cannot recreate the issue you report here:
> > > I have the same problem with reloading the file, thus I wonder if the
> >
> > issue
> >
> > > occured anytime during the game or only at the specific time you
> >
> > originally
> >
> > > saved the game?
> > >
> > > Do you remember what was the case (but I fear some questions are too
> > > detailed):
> > >
> > > - You were in the revenue phase already, did undo and went to lay tile
> > > directly (as the company did not have any token)? Or have you done
> > > twice
> >
> > an
> >
> > > undo? Was a special tile lay of a private company involved? Which
>
> company
>
> > > was operating?
> > >
> > > - After undoing, did the revenue run disappear (as it should)?
> > >
> > > - Did the system calculate the revenue run (thus you got the messagebox
> > > with the run), but did not take the new (different) tile lay into
> > > account?
> > >
> > > - Or did simply nothing happened at all, thus the old revenue value was
> > > still entered?
> > >
> > > I was able to confuse the tile/token laying mechansim by undos somehow,
> >
> > but
> >
> > > even in those cases the revenue calculation still worked. But maybe
> > > fixing those errors might fix the (potentially missing) activation of
>
> the
>
> > > revenue calculation as well. I will look into that.
> > >
> > > Stefan
>
> ---------------------------------------------------------------------------
>
> > >--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > > lucky parental unit.  See the prize list and enter to win:
> > > http://p.sf.net/sfu/thinkgeek-promo
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>
> >--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
>- --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformationhangs game

[Stefan F. (web.de) <ste...@we...>]

Erik,
I know it is still a lot of underspecified ideas. It is good to know that it 
does not raise immediate and spontaneous rejection. 
And the best way to address concerns is to provide working and readable code 
examples, thus that will be something I will work on.

The step-by-step approach is two-fold:

1) Working on smaller bits (StartRound or ShareRounds instead of 
OperatingRound) or special classes

2) Keeping the new structure side-by-side to the existing code and only 
activate it for the test case 1870 in the beginnig. This is easy to do, as 
there are several hooks to activate different classes for game and round 
management.

After that you can still decide to follow that path or not, considering the 
implementation examples.

A few comments / replies to encourage more discussion:

* My own first idea was to use a specific trigger interface and require 
triggers to be explicitly defined. But I realized that the moves are 
excellent triggers and the Moveset a very good place to pass the messages.
Moveset could still delegate the task to a TriggerManager, if a better 
separation is required.

And I want low-level triggers, to avoid that every (high-level) implementation 
has to remember to call the trigger.

Take the example: A candidate in the long run ist the function that checks if 
a company is floated. Every (high-level) method that moves shares out of IPO 
has to check if the company has floated. If the trigger is used, this is done 
automatically. This would also cover special cases in games, which are not 
yet implemented.

(However it might be optimal to provide a generic version of ObjectMove to 
simplify that).

* I agree, the break-up into actions/action controllers and the separate 
sequence control provides the granularity/modularity that is required to 
configure the flow of actions by an XML file. But the XML file itself is for 
sure the end and not the start of the process. 

And you are right: The sequence manager should take care of the different 
types of action (availablity and conditionality). Currently I see three major 
classes of actions:
A) Required
B) Optional, but in sequence
C) Optional, always available 

The basic OR consists of:
1) Tile Lay - B
2) Token Lay - B
3) Train Run and Payout Decision - A
4) Buy Trains - B
5) Buy Privates - C

I intend to have two modes for the action availibility:
Beginner mode: Always offer the next A or B action
Expert mode: Offer all actions in sequence until the next A action or the next 
player/company takes over.

The current client of Rails currently supports only beginner mode, thus 
everything is offered in sequence and one has to inform Rails that one 
intends to not lay a tile or token. 
In the expert mode at the start of the turn tile lay, token lay and payout 
decisions would all be available. In fact Rails would already suggest the 
current optimal run and after each tile/token lay update the best run 
accordingly. A choice of a later action deactivates the earlier actions. 
(Thus a token lay would make further tile lays impossible.) Lemmis moderator 
is an example of the expert mode. 

This does not mean that I intend to change the client now, but I intend to 
make the backend compatible for future enhancements.
Stefan


On Saturday 26 June 2010 16:01:51 Erik Vos wrote:
> See below.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Saturday 26 June 2010 00:24
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
> duringCGRformationhangs game
>
> A) Triggerable Events
> 18xx games have a major class of triggers: Purchases of trains can change
> the
> (game) Phase, which themselves (potentially) impact any dimension of the
> game
> play.
>
> Rails implements that already with the Phase/PhaseManager class.
> But digging deeper, nearly every 18xx has some actions, which have
> side-effect, but are not (full) phase changes. Even in 1830 there is at
> least
> one example: The purchase of the first train by public B&O closes the
> private
> B&O.
>
> A very striking case is the destination run in 1870. Each tile lay a public
> company can trigger this sequence of several actions for any other company.
>
> On the first glance I believe there should be a a trigger / triggerable
> interface combination. But Rails already has a potential trigger
> infrastructure in the state/move objects. Thus triggerable objects should
> define the potential moves/state changes and register themselves to those
> changes.
>
> [EV] Perhaps a better example is the existing Phase.addObjectToClose()
> method, which in fact provides a register-for-callback function. It's
> currently used to close/remove some specific privates, bonuses and bonus
> tokens; in this case, on phase changes only. Indeed I already had in mind
> for some time to extend this function for wider use.
> Closeable could be extended to (or become a subinterface of) Triggerable.
>
> [EV] I doubt if it would be wise to overload State/Move with such new
> functionality. It's low-level, and IMO should stay so.
>
>
> B) Round/Turn Sequence and Queuing
> The sequence of rounds and that of activities inside of rounds is currently
> managed inside the classes implementing the executing logic. There is no
> (additional) framework/classes controlling the sequence alone.
> Any interruption of the standard sequence requires some tweaks to make that
> happen. And one has to be carefull to make it undo-proof.
>
> There are several examples already in Rails for such interruptions
> (especially
> the treasury shares and merger rounds). 1870 would add for example share
> protection here, which changes the sequence inside a stock round.
>
> A general framework (call it SequenceManager) which controls the sequence
> of
>
> rounds and turns (activities inside a round) would make thoses cases
> easier. New rounds/turns would register themselves with the
> SequenceManager, which should also support the queueing of rounds/turns
> (take merger rounds as example, which might occur only after the round/set
> of rounds is finished). It also manages the consequences of undoing those
> sequence changes.
>
> [EV] This reminds me of an idea that Brett and I have discussed several
> years ago (should be in the archive): to make the [OR] actions and their
> sequence configurable (in Game.xml). Some actions can only be done in the
> proper sequence, like tile/token laying. Some steps are optional or
> conditional (e.g. must have the money to lay a token). Some can be executed
> at any time (private buying). An XML structure should be designed to cover
> all such possibilities.
>
> [EV] Currently, sequence management is shared between the rounds and the
> game manager. I don't know how that could be pulled out into a separate
> structure, and whether it should, but it might be an idea worth further
> consideration.
>
>
> C) Splitting of the Round Classes
> The two subclasses of Round are currently the swiss army knives of Rails:
> StockRound and OperatingRound are the main generator and consumer of
> actions
>
> (in addition they are responsible for the correct sequence of activities
> during Rounds, see above).
>
> This has some benefits (espcially synergies with respect to joint variables
> and commonly used methods), but would work not very well with the more
> flexible structure suggested in B. To gain the full benefits breaking up of
> the round classes into smaller sub-units is required, at least from my
> point
>
> of view.
>
> My suggestion here is to use an action type as the atomic unit for such a
> split. Thus for example a LayTile action works in parallel with a
> LayTileController, which generates the action and processes the actions.
>
> The final configuration would look like that (somehow simplified):
>
> A (simplified) OperatingRound controls the sequence by adding the different
> Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.
>
> The SequenceManager would activate the controllers according to the defined
> sequence. The controllers would generate actions and process the responses
> from the UI. After executing their actions the controllers would deregister
> themself from the SequenceManager.
>
> [EV] How about the fact that several different actions types might be
> allowed simultaneously? Such as private buying and loan taking, that in
> many games can be done at all times during an OR turn?
>
> How does a destination run in 1870 work?
> This special (game specific) object is triggerable by TileMoves and checks
> if
> the conditions for a destination run is met: If so, it adds itself (or if
> possible a modified Revenue and LayToken controller) to the SequenceManager
> with the instruction that those actions are queued at the end of the turn
> of
>
> the acting company.
>
> [EV] OK, this kind of answers my question above. However, I would rather
> trigger it by the LayTileController finding that the action is/can be/has
> been executed, rather than the TileMove, which is only the physical
> execution phase. See my comment above.
>
> I have already some ideas, how that structure offers better support for
> optional actions and special properties, but I want to focus on the general
> ideas first.
>
> So what are you comments? All of this will for sure not be done in a single
> step, but only step-by-step.
>
> [EV] I wonder to what extent this can be done 'step by step'. In particular
> C) will be hard to do stepwise.
> I would propose to start with a pretty isolated case, like the 18EU start
> round. Or the 1835 start round, which has old code that needs an overhaul
> anyway.
>
> [EV] It's too early to give a final answer to your ideas, but it all sounds
> rather good, and, as said, partially fits with ideas I already had. But you
> are going a lot further, and I can't yet quite oversee everything. An
> actual working case might make it much clearer.
>
> Erik.
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 playtest report - Rails 1.3

[Stefan F. (web.de) <ste...@we...>]

Erik:
only a few short replies. I think the choice is up to the one implementing it. 
My preference is B > A >>> C

Option C) is in my opinion the worst. Forwarding the network information to 
the client only requires the network graph object. But this object has 
references to all vertices and edges (with further references). One would 
have to recode the whole network graph (which would still be larger than the 
list of all possible tile lays) and then define new methods working on that. 

The encoding of A could also be two of identifiers (hexes and tiles) and a 
bitset (orientation). 

My current approach in the map correction does not fully delegate everything 
to the backend, it is more a hybrid type. It only delegates the validity 
checks and provision of the available options to the server. The update of 
the UI is still done by the client controller itself and not via state 
changes/model updates in the server. The model state only changes after the 
action is fully defined/executed. (This also implies that the undo affects 
the full action and does not undwind partial steps).
From my point of view this still allows clearer separation of responsibilities 
without creating additional states.

Stefan

On Saturday 26 June 2010 13:55:32 Erik Vos wrote:
> Stefan,
>
> A third option could be:
>
> C) In addition to the "simple" LayTile of my proposal (only listing
> reachable hexes), send the current routes in some form or shape from server
> to client, and let the UI use these routes to sort out all laying
> restrictions. I don't know if sending route information is practical,
> though.
>
> About your options:
>
> A) In practice, I suppose it would be a (uuencoded serialized) List of
> Lists of something. Not sure what space that would take.
> Basically you're right that size would't be excessive. Just two additional
> remarks:
> - in my experience, it always pays off to keep traffic small,
> - don't forget that there will be a lot more stuff to transport from server
> to client. To name the probably biggest thing: all Observer updates.
>
> B) Partial actions I have been weeding out consistently since the early
> days, but I understand we now have them back already...
> (Yes, I remember we have had some discussions about that in the past).
> One drawback would be that more state needs be maintained (I suppose that's
> what you refer to as complexity).
> Another reason I'm somewhat concerned about this approach is that it might
> pose restrictions on further developments.
> One use case I have in mind is a future PBEM version. Will the users have
> stand-alone clients, exchanging messages over a slow channel, or will they
> all have full-blown Rails versions, sending mails to each other and/or to
> some central moderator? Most likely it'll be the latter, and then my
> concern is moot, but I'm not sure. Perhaps is just a matter of intuition.
>
> Facing a choice, my current order of preference would be A, C, B.
>
> Erik.
>
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Friday 25 June 2010 23:05
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3
>
> Erik:
> I have some doubts that splitting the support of the tile lay between the
> UI
>
> and the server is optimal. Especially if both have to do route
> calculations.
>
> To allow lightweight clients in the long run (think a browser), that part
> should be server only.
>
> I think there are two alternative options to consider:
>
> A) Are you really convinced that the message size for a complete list of
> possible tile lays and orientations is excessive? Assume that you have 20
> hexes with 6 tiles each to replace. That is 120 combinations and each hex
> and
> tile can be identified by 2 bytes. A bitset for the 6 orientations would be
> another 1 byte. Thus overall a 600 bytes message. Even ten times larger
> should work.
>
> B) The client could ask the sequentially about the available options: First
> the server supplies a list of hexes, the UI selects the hex, the server
> response with available tiles, after tile selection, possible orientations
> are transmitted.
> I used this approach of partially completed actions for the map correction
> action, however for a different reason.
>
> Between the two approaches I am personally indifferent, B) is somehow more
> complex to implement, but has the advantage that all logic stays in the
> backend.
>
> >From a network point of view solution A) is preferred, if the restricting
>
> factor is latency, B) to solve bandwidth issues.
>
> Stefan
>
> On Friday 25 June 2010 15:16:25 Erik Vos wrote:
> > [EV] Yes, in principle you are right on the client/server task division.
> > But in this case, it would mean that the server would need to send to the
> > client a full list of all tiles in all valid orientation that can be laid
> > in any layable hex. Although that would be the right thing to do in
>
> theory,
>
> > it would overload the client/server communication a bit, to my taste.
> >
> > LayTile is already prepared to carry a list of layable hexes. My
>
> preference
>
> > would be to use only such a list, and leave sorting out the valid tiles
>
> and
>
> > orientations to the UI. Most of that is based on the current map and the
> > static tile upgrade specifications (any static info is always available
> > to the UI). Then the only missing info in the client is about any allowed
>
> lays
>
> > in unreachable hexes (already passed in special LayTile actions) and any
> > reachable but disallowed hexes (partly covered in special code, partly
> > yet uncovered, I think). Starting to use that list of layable hexes might
> > fix the latter hole.
> >
> > However, this might imply that route evaluation should finally be done
>
> both
>
> > (and separately) in the server and the client. IMO the server should be
> > able to do a full validation of everything it gets from the clients (even
> > if we only partially implement such validation). But I'm not sure how you
> > think about that....
> >
> > Erik.
>
> ---------------------------------------------------------------------------
>- --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformationhangs game

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

See below. 

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Saturday 26 June 2010 00:24
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo
duringCGRformationhangs game

A) Triggerable Events
18xx games have a major class of triggers: Purchases of trains can change
the 
(game) Phase, which themselves (potentially) impact any dimension of the
game 
play.

Rails implements that already with the Phase/PhaseManager class. 
But digging deeper, nearly every 18xx has some actions, which have 
side-effect, but are not (full) phase changes. Even in 1830 there is at
least 
one example: The purchase of the first train by public B&O closes the
private 
B&O.

A very striking case is the destination run in 1870. Each tile lay a public 
company can trigger this sequence of several actions for any other company.

On the first glance I believe there should be a a trigger / triggerable 
interface combination. But Rails already has a potential trigger 
infrastructure in the state/move objects. Thus triggerable objects should 
define the potential moves/state changes and register themselves to those 
changes.

[EV] Perhaps a better example is the existing Phase.addObjectToClose()
method, which in fact provides a register-for-callback function. It's
currently used to close/remove some specific privates, bonuses and bonus
tokens; in this case, on phase changes only. Indeed I already had in mind
for some time to extend this function for wider use.
Closeable could be extended to (or become a subinterface of) Triggerable.

[EV] I doubt if it would be wise to overload State/Move with such new
functionality. It's low-level, and IMO should stay so.


B) Round/Turn Sequence and Queuing
The sequence of rounds and that of activities inside of rounds is currently 
managed inside the classes implementing the executing logic. There is no 
(additional) framework/classes controlling the sequence alone. 
Any interruption of the standard sequence requires some tweaks to make that 
happen. And one has to be carefull to make it undo-proof.

There are several examples already in Rails for such interruptions
(especially 
the treasury shares and merger rounds). 1870 would add for example share 
protection here, which changes the sequence inside a stock round.

A general framework (call it SequenceManager) which controls the sequence of

rounds and turns (activities inside a round) would make thoses cases easier.
New rounds/turns would register themselves with the SequenceManager, which 
should also support the queueing of rounds/turns (take merger rounds as 
example, which might occur only after the round/set of rounds is finished). 
It also manages the consequences of undoing those sequence changes.

[EV] This reminds me of an idea that Brett and I have discussed several
years ago (should be in the archive): to make the [OR] actions and their
sequence configurable (in Game.xml). Some actions can only be done in the
proper sequence, like tile/token laying. Some steps are optional or
conditional (e.g. must have the money to lay a token). Some can be executed
at any time (private buying). An XML structure should be designed to cover
all such possibilities.

[EV] Currently, sequence management is shared between the rounds and the
game manager. I don't know how that could be pulled out into a separate
structure, and whether it should, but it might be an idea worth further
consideration.


C) Splitting of the Round Classes
The two subclasses of Round are currently the swiss army knives of Rails: 
StockRound and OperatingRound are the main generator and consumer of actions

(in addition they are responsible for the correct sequence of activities 
during Rounds, see above).

This has some benefits (espcially synergies with respect to joint variables 
and commonly used methods), but would work not very well with the more 
flexible structure suggested in B. To gain the full benefits breaking up of 
the round classes into smaller sub-units is required, at least from my point

of view.

My suggestion here is to use an action type as the atomic unit for such a 
split. Thus for example a LayTile action works in parallel with a 
LayTileController, which generates the action and processes the actions.

The final configuration would look like that (somehow simplified):

A (simplified) OperatingRound controls the sequence by adding the different 
Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.

The SequenceManager would activate the controllers according to the defined 
sequence. The controllers would generate actions and process the responses 
from the UI. After executing their actions the controllers would deregister 
themself from the SequenceManager.

[EV] How about the fact that several different actions types might be
allowed simultaneously? Such as private buying and loan taking, that in many
games can be done at all times during an OR turn?

How does a destination run in 1870 work?
This special (game specific) object is triggerable by TileMoves and checks
if 
the conditions for a destination run is met: If so, it adds itself (or if 
possible a modified Revenue and LayToken controller) to the SequenceManager 
with the instruction that those actions are queued at the end of the turn of

the acting company.

[EV] OK, this kind of answers my question above. However, I would rather
trigger it by the LayTileController finding that the action is/can be/has
been executed, rather than the TileMove, which is only the physical
execution phase. See my comment above.

I have already some ideas, how that structure offers better support for 
optional actions and special properties, but I want to focus on the general 
ideas first. 

So what are you comments? All of this will for sure not be done in a single 
step, but only step-by-step. 

[EV] I wonder to what extent this can be done 'step by step'. In particular
C) will be hard to do stepwise. 
I would propose to start with a pretty isolated case, like the 18EU start
round. Or the 1835 start round, which has old code that needs an overhaul
anyway.

[EV] It's too early to give a final answer to your ideas, but it all sounds
rather good, and, as said, partially fits with ideas I already had. But you
are going a lot further, and I can't yet quite oversee everything. An actual
working case might make it much clearer.

Erik.

Re: [Rails-devel] 1835 playtest report - Rails 1.3

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

Stefan,

A third option could be:

C) In addition to the "simple" LayTile of my proposal (only listing
reachable hexes), send the current routes in some form or shape from server
to client, and let the UI use these routes to sort out all laying
restrictions. I don't know if sending route information is practical,
though.

About your options:

A) In practice, I suppose it would be a (uuencoded serialized) List of Lists
of something. Not sure what space that would take. 
Basically you're right that size would't be excessive. Just two additional
remarks:
- in my experience, it always pays off to keep traffic small,
- don't forget that there will be a lot more stuff to transport from server
to client. To name the probably biggest thing: all Observer updates.

B) Partial actions I have been weeding out consistently since the early
days, but I understand we now have them back already... 
(Yes, I remember we have had some discussions about that in the past).
One drawback would be that more state needs be maintained (I suppose that's
what you refer to as complexity).
Another reason I'm somewhat concerned about this approach is that it might
pose restrictions on further developments. 
One use case I have in mind is a future PBEM version. Will the users have
stand-alone clients, exchanging messages over a slow channel, or will they
all have full-blown Rails versions, sending mails to each other and/or to
some central moderator? Most likely it'll be the latter, and then my concern
is moot, but I'm not sure. Perhaps is just a matter of intuition.

Facing a choice, my current order of preference would be A, C, B.  

Erik.


-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Friday 25 June 2010 23:05
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3

Erik:
I have some doubts that splitting the support of the tile lay between the UI

and the server is optimal. Especially if both have to do route calculations.

To allow lightweight clients in the long run (think a browser), that part 
should be server only.

I think there are two alternative options to consider:

A) Are you really convinced that the message size for a complete list of 
possible tile lays and orientations is excessive? Assume that you have 20 
hexes with 6 tiles each to replace. That is 120 combinations and each hex
and 
tile can be identified by 2 bytes. A bitset for the 6 orientations would be 
another 1 byte. Thus overall a 600 bytes message. Even ten times larger 
should work.

B) The client could ask the sequentially about the available options: First 
the server supplies a list of hexes, the UI selects the hex, the server 
response with available tiles, after tile selection, possible orientations 
are transmitted.
I used this approach of partially completed actions for the map correction 
action, however for a different reason.

Between the two approaches I am personally indifferent, B) is somehow more 
complex to implement, but has the advantage that all logic stays in the 
backend.

>From a network point of view solution A) is preferred, if the restricting 
factor is latency, B) to solve bandwidth issues.

Stefan

On Friday 25 June 2010 15:16:25 Erik Vos wrote:
> [EV] Yes, in principle you are right on the client/server task division.
> But in this case, it would mean that the server would need to send to the
> client a full list of all tiles in all valid orientation that can be laid
> in any layable hex. Although that would be the right thing to do in
theory,
> it would overload the client/server communication a bit, to my taste.
>
> LayTile is already prepared to carry a list of layable hexes. My
preference
> would be to use only such a list, and leave sorting out the valid tiles
and
> orientations to the UI. Most of that is based on the current map and the
> static tile upgrade specifications (any static info is always available to
> the UI). Then the only missing info in the client is about any allowed
lays
> in unreachable hexes (already passed in special LayTile actions) and any
> reachable but disallowed hexes (partly covered in special code, partly yet
> uncovered, I think). Starting to use that list of layable hexes might fix
> the latter hole.
>
> However, this might imply that route evaluation should finally be done
both
> (and separately) in the server and the client. IMO the server should be
> able to do a full validation of everything it gets from the clients (even
> if we only partially implement such validation). But I'm not sure how you
> think about that....
>
> Erik.



----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo duringCGRformation hangs game

[Stefan F. (web.de) <ste...@we...>]

Erik:
I agree that hardening Rails is important, and I believe that this includes 
improving the internal structure: Before starting the route calculation I was 
looking into some core mechanisms in Rail and I would like to return to this 
task now:

In the process of planning the changes required for 1870, I realized that some 
additional structures would help to deal with some of challenges, that new 
18xx might bring to the table. 

I will shortly outline my ideas, before I make more detailed suggestions 
and/or provide some prototype implementation. I hope for some feedback?

The proposals are mainly independent, but they link with each other well.

A) Triggerable Events
18xx games have a major class of triggers: Purchases of trains can change the 
(game) Phase, which themselves (potentially) impact any dimension of the game 
play.

Rails implements that already with the Phase/PhaseManager class. 
But digging deeper, nearly every 18xx has some actions, which have 
side-effect, but are not (full) phase changes. Even in 1830 there is at least 
one example: The purchase of the first train by public B&O closes the private 
B&O.

A very striking case is the destination run in 1870. Each tile lay a public 
company can trigger this sequence of several actions for any other company.

On the first glance I believe there should be a a trigger / triggerable 
interface combination. But Rails already has a potential trigger 
infrastructure in the state/move objects. Thus triggerable objects should 
define the potential moves/state changes and register themselves to those 
changes.

B) Round/Turn Sequence and Queuing
The sequence of rounds and that of activities inside of rounds is currently 
managed inside the classes implementing the executing logic. There is no 
(additional) framework/classes controlling the sequence alone. 
Any interruption of the standard sequence requires some tweaks to make that 
happen. And one has to be carefull to make it undo-proof.

There are several examples already in Rails for such interruptions (especially 
the treasury shares and merger rounds). 1870 would add for example share 
protection here, which changes the sequence inside a stock round.

A general framework (call it SequenceManager) which controls the sequence of 
rounds and turns (activities inside a round) would make thoses cases easier.
New rounds/turns would register themselves with the SequenceManager, which 
should also support the queueing of rounds/turns (take merger rounds as 
example, which might occur only after the round/set of rounds is finished). 
It also manages the consequences of undoing those sequence changes.

C) Splitting of the Round Classes
The two subclasses of Round are currently the swiss army knives of Rails: 
StockRound and OperatingRound are the main generator and consumer of actions 
(in addition they are responsible for the correct sequence of activities 
during Rounds, see above).

This has some benefits (espcially synergies with respect to joint variables 
and commonly used methods), but would work not very well with the more 
flexible structure suggested in B. To gain the full benefits breaking up of 
the round classes into smaller sub-units is required, at least from my point 
of view.

My suggestion here is to use an action type as the atomic unit for such a 
split. Thus for example a LayTile action works in parallel with a 
LayTileController, which generates the action and processes the actions.

The final configuration would look like that (somehow simplified):

A (simplified) OperatingRound controls the sequence by adding the different 
Controllers (LayTile, LayToken, Revenue, BuyTrain) to the SequenceManager.

The SequenceManager would activate the controllers according to the defined 
sequence. The controllers would generate actions and process the responses 
from the UI. After executing their actions the controllers would deregister 
themself from the SequenceManager.

How does a destination run in 1870 work?
This special (game specific) object is triggerable by TileMoves and checks if 
the conditions for a destination run is met: If so, it adds itself (or if 
possible a modified Revenue and LayToken controller) to the SequenceManager 
with the instruction that those actions are queued at the end of the turn of 
the acting company.

I have already some ideas, how that structure offers better support for 
optional actions and special properties, but I want to focus on the general 
ideas first. 

So what are you comments? All of this will for sure not be done in a single 
step, but only step-by-step. 

Stefan


On Friday 25 June 2010 11:15:35 Erik Vos wrote:
> Stefan,
>
> Thanks for your analysis. Yes, I agree that Rails should be further
> hardened in the aspects you mentioned.
> Anyway, I think I'll remain in bug-fixing-and-hardening mode for some time!
>
> Erik.

Re: [Rails-devel] 18EU minor initial sale round bugs

[Phil D. <de...@gm...>]

When we are playing face to face, we still say 'pass' when passing on a declining option and the whole process to is is called an auction. Both mine and Chris' approach is perfectly valid, it's just a semantic issue really.

Does the localisation functionality help us here?

On 25 Jun 2010, at 22:19, "Stefan Frey (web.de)" <ste...@we...> wrote:

> I wish you were right about implementation times ;-)
> 
> But what is more worrying is the long-time impact of such marginally improving
> changes that still potentially make the system more complicate.
> 
> I would not do that without a general use case (here I believe that there will 
> be other cases, where the backend can instruct the client that this action 
> type will have a different label for the user).
> Most likely it will already simplify the case of "select, no bid".
> 
> At least I can write those e-mails simultan to watch world cup, which is 
> unfortunately not possible for serious coding.
> 
> Stefan
> 
> On Friday 25 June 2010 22:51:02 Chris Shaffer wrote:
>> I get the feeling we've already spent more time discussing it than it would
>> have taken to implement it.
>> 
>> At any rate, if any of the developers other than Erik would care to make
>> the change, it would be appreciated.  I note that the UI is already
>> complicated by the implementation of the "select, no bid" option and this
>> would simply be extending that option to the following players.
>> 
>> --
>> Chris
>> 
>> Please consider the environment before printing this e-mail.
>> 
>> On Fri, Jun 25, 2010 at 1:39 PM, Erik Vos <eri...@xs...> wrote:
>>> I consider it an immaterial difference in rules wording, that does not
>>> merit complicating the UI. But apparently opinions differ. I won't oppose
>>> such a change, but I have better things to spend my time on.
>>> 
>>> Erik.
>>> 
>>> ------------------------------
>>> *From:* Chris Shaffer [mailto:chr...@gm...]
>>> *Sent:* Friday 25 June 2010 22:22
>>> *To:* Development list for Rails: an 18xx game
>>> *Subject:* Re: [Rails-devel] 18EU minor initial sale round bugs
>>> 
>>>  [EV] Indeed. I don't actually see why "Pass" would not cover "Decline
>>> to
>>> 
>>>> bid" as well. I don't see any need to make that distinction.
>>> 
>>> It is problematic to explain rules when the interface does not match the
>>> terminology in the rules.  "Pass" has a specific meaning that is
>>> different from "decline to bid."
>>> 
>>> I'm not sure why there would be resistance to having Rails match the game
>>> rules?  What good reason could there be for desiring a conflict in
>>> terminology?
>>> 
>>> --
>>> Chris
>>> 
>>> 
>>> 
>>> -------------------------------------------------------------------------
>>> ----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU minor initial sale round bugs

[Stefan F. (web.de) <ste...@we...>]

I wish you were right about implementation times ;-)

But what is more worrying is the long-time impact of such marginally improving
changes that still potentially make the system more complicate.

I would not do that without a general use case (here I believe that there will 
be other cases, where the backend can instruct the client that this action 
type will have a different label for the user).
Most likely it will already simplify the case of "select, no bid".

At least I can write those e-mails simultan to watch world cup, which is 
unfortunately not possible for serious coding.

Stefan

On Friday 25 June 2010 22:51:02 Chris Shaffer wrote:
> I get the feeling we've already spent more time discussing it than it would
> have taken to implement it.
>
> At any rate, if any of the developers other than Erik would care to make
> the change, it would be appreciated.  I note that the UI is already
> complicated by the implementation of the "select, no bid" option and this
> would simply be extending that option to the following players.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Fri, Jun 25, 2010 at 1:39 PM, Erik Vos <eri...@xs...> wrote:
> >  I consider it an immaterial difference in rules wording, that does not
> > merit complicating the UI. But apparently opinions differ. I won't oppose
> > such a change, but I have better things to spend my time on.
> >
> > Erik.
> >
> >  ------------------------------
> > *From:* Chris Shaffer [mailto:chr...@gm...]
> > *Sent:* Friday 25 June 2010 22:22
> > *To:* Development list for Rails: an 18xx game
> > *Subject:* Re: [Rails-devel] 18EU minor initial sale round bugs
> >
> >   [EV] Indeed. I don't actually see why "Pass" would not cover "Decline
> > to
> >
> >> bid" as well. I don't see any need to make that distinction.
> >
> > It is problematic to explain rules when the interface does not match the
> > terminology in the rules.  "Pass" has a specific meaning that is
> > different from "decline to bid."
> >
> > I'm not sure why there would be resistance to having Rails match the game
> > rules?  What good reason could there be for desiring a conflict in
> > terminology?
> >
> > --
> > Chris
> >
> >
> >
> > -------------------------------------------------------------------------
> >----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1856 bugs in Rails 1.3 -- undo during CGRformation hangs game

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

I discovered today in 1835 that if you are 1 below the cert limit,
rails will not let you purchase one of the 20% shares because it
thinks it is two certificates.  I suspect this is a similar sort of
issue.  It sounds like there are a few niggles where cert and share
are considered interchangeable which will lead to problems with games
where a cert can be more or less than 10% of a corp

[EV] No, this was a long standing coding error that only now has come to
light: the (two) additional shares were counted in stead if the (one)
certificate. Fixed.

Erik.

Re: [Rails-devel] 1835 playtest report - Rails 1.3

[Stefan F. (web.de) <ste...@we...>]

Erik:
I have some doubts that splitting the support of the tile lay between the UI 
and the server is optimal. Especially if both have to do route calculations. 
To allow lightweight clients in the long run (think a browser), that part 
should be server only.

I think there are two alternative options to consider:

A) Are you really convinced that the message size for a complete list of 
possible tile lays and orientations is excessive? Assume that you have 20 
hexes with 6 tiles each to replace. That is 120 combinations and each hex and 
tile can be identified by 2 bytes. A bitset for the 6 orientations would be 
another 1 byte. Thus overall a 600 bytes message. Even ten times larger 
should work.

B) The client could ask the sequentially about the available options: First 
the server supplies a list of hexes, the UI selects the hex, the server 
response with available tiles, after tile selection, possible orientations 
are transmitted.
I used this approach of partially completed actions for the map correction 
action, however for a different reason.

Between the two approaches I am personally indifferent, B) is somehow more 
complex to implement, but has the advantage that all logic stays in the 
backend.

From a network point of view solution A) is preferred, if the restricting 
factor is latency, B) to solve bandwidth issues.

Stefan

On Friday 25 June 2010 15:16:25 Erik Vos wrote:
> [EV] Yes, in principle you are right on the client/server task division.
> But in this case, it would mean that the server would need to send to the
> client a full list of all tiles in all valid orientation that can be laid
> in any layable hex. Although that would be the right thing to do in theory,
> it would overload the client/server communication a bit, to my taste.
>
> LayTile is already prepared to carry a list of layable hexes. My preference
> would be to use only such a list, and leave sorting out the valid tiles and
> orientations to the UI. Most of that is based on the current map and the
> static tile upgrade specifications (any static info is always available to
> the UI). Then the only missing info in the client is about any allowed lays
> in unreachable hexes (already passed in special LayTile actions) and any
> reachable but disallowed hexes (partly covered in special code, partly yet
> uncovered, I think). Starting to use that list of layable hexes might fix
> the latter hole.
>
> However, this might imply that route evaluation should finally be done both
> (and separately) in the server and the client. IMO the server should be
> able to do a full validation of everything it gets from the clients (even
> if we only partially implement such validation). But I'm not sure how you
> think about that....
>
> Erik.

Re: [Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

I get the feeling we've already spent more time discussing it than it would
have taken to implement it.

At any rate, if any of the developers other than Erik would care to make the
change, it would be appreciated.  I note that the UI is already complicated
by the implementation of the "select, no bid" option and this would simply
be extending that option to the following players.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Jun 25, 2010 at 1:39 PM, Erik Vos <eri...@xs...> wrote:

>  I consider it an immaterial difference in rules wording, that does not
> merit complicating the UI. But apparently opinions differ. I won't oppose
> such a change, but I have better things to spend my time on.
>
> Erik.
>
>  ------------------------------
> *From:* Chris Shaffer [mailto:chr...@gm...]
> *Sent:* Friday 25 June 2010 22:22
> *To:* Development list for Rails: an 18xx game
> *Subject:* Re: [Rails-devel] 18EU minor initial sale round bugs
>
>   [EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
>> bid" as well. I don't see any need to make that distinction.
>>
>
> It is problematic to explain rules when the interface does not match the
> terminology in the rules.  "Pass" has a specific meaning that is different
> from "decline to bid."
>
> I'm not sure why there would be resistance to having Rails match the game
> rules?  What good reason could there be for desiring a conflict in
> terminology?
>
> --
> Chris
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] 18EU minor initial sale round bugs

[Stefan F. (web.de) <ste...@we...>]

Chris:
The good reason is that internally all cases are covered by the identical 
action, called "pass". So not surprising that the button triggering the 
action is labelled "pass". Similar to buy and sell actions ;-).

But I think that adding a field "alternativeLabel" to the Null Action (maybe 
even to superclass PossibleAction) might come in handy in such situations, 
where the game labels semantically identical actions differently.

Stefan


On Friday 25 June 2010 22:21:58 Chris Shaffer wrote:
> > [EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
> > bid" as well. I don't see any need to make that distinction.
>
> It is problematic to explain rules when the interface does not match the
> terminology in the rules.  "Pass" has a specific meaning that is different
> from "decline to bid."
>
> I'm not sure why there would be resistance to having Rails match the game
> rules?  What good reason could there be for desiring a conflict in
> terminology?
>
> --
> Chris

Re: [Rails-devel] 18EU minor initial sale round bugs

[brett l. <bre...@gm...>]

On Fri, Jun 25, 2010 at 1:21 PM, Chris Shaffer <chr...@gm...> wrote:
>> [EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
>> bid" as well. I don't see any need to make that distinction.
>
> It is problematic to explain rules when the interface does not match the
> terminology in the rules.  "Pass" has a specific meaning that is different
> from "decline to bid."
>

Can you elaborate on what the specific difference is and how this
difference impacts the play of the game?


> I'm not sure why there would be resistance to having Rails match the game
> rules?  What good reason could there be for desiring a conflict in
> terminology?
>
> --
> Chris
>

---Brett.

Re: [Rails-devel] 18EU minor initial sale round bugs

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

I consider it an immaterial difference in rules wording, that does not merit
complicating the UI. But apparently opinions differ. I won't oppose such a
change, but I have better things to spend my time on.
 
Erik.


  _____  

From: Chris Shaffer [mailto:chr...@gm...] 
Sent: Friday 25 June 2010 22:22
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 18EU minor initial sale round bugs



[EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
bid" as well. I don't see any need to make that distinction.



It is problematic to explain rules when the interface does not match the
terminology in the rules.  "Pass" has a specific meaning that is different
from "decline to bid."

I'm not sure why there would be resistance to having Rails match the game
rules?  What good reason could there be for desiring a conflict in
terminology?

--
Chris

Re: [Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

>
> [EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
> bid" as well. I don't see any need to make that distinction.
>

It is problematic to explain rules when the interface does not match the
terminology in the rules.  "Pass" has a specific meaning that is different
from "decline to bid."

I'm not sure why there would be resistance to having Rails match the game
rules?  What good reason could there be for desiring a conflict in
terminology?

--
Chris

Re: [Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

Yes, I think this is a good summation.  Similarly, the log file should
reflect the new text rather than saying that players have passed.

You are correct that this is not a show stopper.  However, in my experience,
when teaching new players 18EU, the distinctions between auction and
purchase can be somewhat confusing.  Proper use of the terms to match the
rulebook helps with their understanding. This is even more important when
using Rails as a PBEM client, since the teacher is not there in-person to
explain the rules to the new players.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Jun 25, 2010 at 12:53 PM, Stefan Frey (web.de)
<ste...@we...>wrote:

> Chris:
> I already fixed the first bug (players were still able to bid after pass
> after
> an auction started for that item) a few days ago.
>
> >From my understanding the second "bug" is only the label of the button:
> During the first round (where an auction is still possible) the button with
> label "pass" should be called "decline to bid".
>
> In the later rounds (where buying is possible) the label for the pass
> button
> should be changed to "decline to buy", if one wants to mimick the rule
> phrases here too.
>
> It is easy to change that, but I must admit, that I never had any problem.
> I always assumed that the auction only starts, when the first bid is
> raised.
> Thus for me even the button for the auctioneer could be relabelled to
> "select
> and pass" and I would still assume that the auctioneer could decide to
> enter
> the auction later.
>
> Stefan
>
>
> On Friday 25 June 2010 19:23:17 Chris Shaffer wrote:
> > It does give that to the person who selects the minor.  It does not offer
> > "no bid" to the following players, who should be offered the same option.
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> > On Fri, Jun 25, 2010 at 10:20 AM, Phil Davies <de...@gm...> wrote:
> > > I was fairly sure that EU gave you a 'start, no bid' option to start an
> > > auction without bidding
> > >
> > > Phil
> > >
> > > On 25 Jun 2010, at 17:50, Chris Shaffer <chr...@gm...>
> wrote:
> > > > I've recently submitted two bug reports for 18EU that I thought I
> would
> > >
> > > mention here.
> > >
> > > > First, when a minor is initially offered, a player should be offered
> > > > the
> > >
> > > options to "bid" (thus starting an auction) or "decline to bid."
> > > Instead, players are offered "bid" or "pass."  This is also recorded in
> > > the game log as a pass.  The rules are clear that declining to start an
> > > auction does not constitute a pass.
> > >
> > > > Second, after an auction is started, a player who subsequently passes
> > >
> > > should not be allowed to re-enter the auction.  Rails allows players to
> > > do this.
> > >
> > > > --
> > > > Chris
> > > >
> > > > Please consider the environment before printing this e-mail.
> > >
> > >
> -------------------------------------------------------------------------
> > >-----
> > >
> > > > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > > > lucky parental unit.  See the prize list and enter to win:
> > > > http://p.sf.net/sfu/thinkgeek-promo
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > >
> > >
> -------------------------------------------------------------------------
> > >----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > > lucky parental unit.  See the prize list and enter to win:
> > > http://p.sf.net/sfu/thinkgeek-promo
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18EU minor initial sale round bugs

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

>From my understanding the second "bug" is only the label of the button:
During the first round (where an auction is still possible) the button with 
label "pass" should be called "decline to bid". 

In the later rounds (where buying is possible) the label for the pass button

should be changed to "decline to buy", if one wants to mimick the rule 
phrases here too.

It is easy to change that, but I must admit, that I never had any problem.
I always assumed that the auction only starts, when the first bid is raised.
Thus for me even the button for the auctioneer could be relabelled to
"select 
and pass" and I would still assume that the auctioneer could decide to enter

the auction later.

[EV] Indeed. I don't actually see why "Pass" would not cover "Decline to
bid" as well. I don't see any need to make that distinction.

Erik.
 

Re: [Rails-devel] 18EU minor initial sale round bugs

[Stefan F. (web.de) <ste...@we...>]

Chris:
I already fixed the first bug (players were still able to bid after pass after 
an auction started for that item) a few days ago.

From my understanding the second "bug" is only the label of the button:
During the first round (where an auction is still possible) the button with 
label "pass" should be called "decline to bid". 

In the later rounds (where buying is possible) the label for the pass button 
should be changed to "decline to buy", if one wants to mimick the rule 
phrases here too.

It is easy to change that, but I must admit, that I never had any problem.
I always assumed that the auction only starts, when the first bid is raised.
Thus for me even the button for the auctioneer could be relabelled to "select 
and pass" and I would still assume that the auctioneer could decide to enter 
the auction later.

Stefan


On Friday 25 June 2010 19:23:17 Chris Shaffer wrote:
> It does give that to the person who selects the minor.  It does not offer
> "no bid" to the following players, who should be offered the same option.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
> On Fri, Jun 25, 2010 at 10:20 AM, Phil Davies <de...@gm...> wrote:
> > I was fairly sure that EU gave you a 'start, no bid' option to start an
> > auction without bidding
> >
> > Phil
> >
> > On 25 Jun 2010, at 17:50, Chris Shaffer <chr...@gm...> wrote:
> > > I've recently submitted two bug reports for 18EU that I thought I would
> >
> > mention here.
> >
> > > First, when a minor is initially offered, a player should be offered
> > > the
> >
> > options to "bid" (thus starting an auction) or "decline to bid." 
> > Instead, players are offered "bid" or "pass."  This is also recorded in
> > the game log as a pass.  The rules are clear that declining to start an
> > auction does not constitute a pass.
> >
> > > Second, after an auction is started, a player who subsequently passes
> >
> > should not be allowed to re-enter the auction.  Rails allows players to
> > do this.
> >
> > > --
> > > Chris
> > >
> > > Please consider the environment before printing this e-mail.
> >
> > -------------------------------------------------------------------------
> >-----
> >
> > > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > > lucky parental unit.  See the prize list and enter to win:
> > > http://p.sf.net/sfu/thinkgeek-promo
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > -------------------------------------------------------------------------
> >----- ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

p.s. technically, if you select "no bid" you are not starting an auction.
Only if a player places a bid of 100 or more is there an auction.  If no
player starts an auction, the minor is offered for purchase to each player
in turn and there is no auction.  So the sequence should be (assuming 3
player game)

Player 1 selects minor

Player 1 place bid 100 or greater to start auction, then each player in turn
bid or pass until all but one pass; exit
-- OR --
Player 1 decline to place bid; then

Player 2 place bid 100 or greater to start auction, then each player in turn
bid or pass until all but one pass; exit
-- OR --
Player 2 decline to place bid; then

Player 3 place bid 100 or greater to start auction, then each player in turn
bid or pass until all but one pass; exit
-- OR --
Player 3 decline to place bid; then

No auction
Player 1 offered purchase at 90 or decline
Player 2 offered purchase at 90 or decline
Player 3 offered purchase at 90 or decline
Player 1 offered purchase at 80 or decline
...

Players only "pass" if an auction is started at 100 or greater, and that
should cause them to be removed from consideration for that minor.  In all
other cases they "decline" and remain in consideration for that minor.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Jun 25, 2010 at 10:23 AM, Chris Shaffer <chr...@gm...>wrote:

> It does give that to the person who selects the minor.  It does not offer
> "no bid" to the following players, who should be offered the same option.
>
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Fri, Jun 25, 2010 at 10:20 AM, Phil Davies <de...@gm...> wrote:
>
>> I was fairly sure that EU gave you a 'start, no bid' option to start an
>> auction without bidding
>>
>> Phil
>>
>> On 25 Jun 2010, at 17:50, Chris Shaffer <chr...@gm...> wrote:
>>
>> > I've recently submitted two bug reports for 18EU that I thought I would
>> mention here.
>> >
>> > First, when a minor is initially offered, a player should be offered the
>> options to "bid" (thus starting an auction) or "decline to bid."  Instead,
>> players are offered "bid" or "pass."  This is also recorded in the game log
>> as a pass.  The rules are clear that declining to start an auction does not
>> constitute a pass.
>> >
>> > Second, after an auction is started, a player who subsequently passes
>> should not be allowed to re-enter the auction.  Rails allows players to do
>> this.
>> >
>> > --
>> > Chris
>> >
>> > Please consider the environment before printing this e-mail.
>> >
>> ------------------------------------------------------------------------------
>> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> > lucky parental unit.  See the prize list and enter to win:
>> > http://p.sf.net/sfu/thinkgeek-promo
>> > _______________________________________________
>> > Rails-devel mailing list
>> > Rai...@li...
>> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>

Re: [Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

It does give that to the person who selects the minor.  It does not offer
"no bid" to the following players, who should be offered the same option.

--
Chris

Please consider the environment before printing this e-mail.


On Fri, Jun 25, 2010 at 10:20 AM, Phil Davies <de...@gm...> wrote:

> I was fairly sure that EU gave you a 'start, no bid' option to start an
> auction without bidding
>
> Phil
>
> On 25 Jun 2010, at 17:50, Chris Shaffer <chr...@gm...> wrote:
>
> > I've recently submitted two bug reports for 18EU that I thought I would
> mention here.
> >
> > First, when a minor is initially offered, a player should be offered the
> options to "bid" (thus starting an auction) or "decline to bid."  Instead,
> players are offered "bid" or "pass."  This is also recorded in the game log
> as a pass.  The rules are clear that declining to start an auction does not
> constitute a pass.
> >
> > Second, after an auction is started, a player who subsequently passes
> should not be allowed to re-enter the auction.  Rails allows players to do
> this.
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> ------------------------------------------------------------------------------
> > ThinkGeek and WIRED's GeekDad team up for the Ultimate
> > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> > lucky parental unit.  See the prize list and enter to win:
> > http://p.sf.net/sfu/thinkgeek-promo
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] 18EU minor initial sale round bugs

[Phil D. <de...@gm...>]

I was fairly sure that EU gave you a 'start, no bid' option to start an auction without bidding

Phil

On 25 Jun 2010, at 17:50, Chris Shaffer <chr...@gm...> wrote:

> I've recently submitted two bug reports for 18EU that I thought I would mention here.
> 
> First, when a minor is initially offered, a player should be offered the options to "bid" (thus starting an auction) or "decline to bid."  Instead, players are offered "bid" or "pass."  This is also recorded in the game log as a pass.  The rules are clear that declining to start an auction does not constitute a pass.
> 
> Second, after an auction is started, a player who subsequently passes should not be allowed to re-enter the auction.  Rails allows players to do this.
> 
> --
> Chris
> 
> Please consider the environment before printing this e-mail.
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.  See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 18EU minor initial sale round bugs

[Chris S. <chr...@gm...>]

I've recently submitted two bug reports for 18EU that I thought I would
mention here.

First, when a minor is initially offered, a player should be offered the
options to "bid" (thus starting an auction) or "decline to bid."  Instead,
players are offered "bid" or "pass."  This is also recorded in the game log
as a pass.  The rules are clear that declining to start an auction does not
constitute a pass.

Second, after an auction is started, a player who subsequently passes should
not be allowed to re-enter the auction.  Rails allows players to do this.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] 1835 playtest report - Rails 1.3

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

See below.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Sunday 20 June 2010 14:41
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1835 playtest report - Rails 1.3

Erik:
to continue the discussion, see my comments / questions:

> The rule enforcing for tile laying in Rails has not changed (yet).
> Enforcement is on my list, but it requires a more drastic change of the
> current UI implementation. It will also consider the various approaches
> (permissive, restrictive, semi-restrictive), with the default set
> accordingly
> for each game.
>
> [EV] A permissive check would be easy to add. All that's needed is adding
a
> call to a method that returns if a given track on a given hexside is part
> of a route (to be inserted in GUITile around line 115). The other
> approaches would require some more coding but need the same method call.

What currently stops me somehow from implementing it there is the more
general 
question, if those validity checks should be part of the UI-code or better 
handled by the backend?
Most likely for the current implementation it does not matter, but in the 
longer run (at least for my understanding) the backend should provide the 
information about valid tile lays for the UI. This information should be 
passed to the UI via the action objects?
I have not searched the archive of the development for the issue of 
client/server separation exactly, so I do not know, what your planning
there, 
but I would have guessed, that you prefer to have as much in the backend as 
possible.

[EV] Yes, in principle you are right on the client/server task division.
But in this case, it would mean that the server would need to send to the
client a full list of all tiles in all valid orientation that can be laid in
any layable hex. Although that would be the right thing to do in theory, it
would overload the client/server communication a bit, to my taste. 

LayTile is already prepared to carry a list of layable hexes. My preference
would be to use only such a list, and leave sorting out the valid tiles and
orientations to the UI. Most of that is based on the current map and the
static tile upgrade specifications (any static info is always available to
the UI). Then the only missing info in the client is about any allowed lays
in unreachable hexes (already passed in special LayTile actions) and any
reachable but disallowed hexes (partly covered in special code, partly yet
uncovered, I think). Starting to use that list of layable hexes might fix
the latter hole.

However, this might imply that route evaluation should finally be done both
(and separately) in the server and the client. IMO the server should be able
to do a full validation of everything it gets from the clients (even if we
only partially implement such validation). But I'm not sure how you think
about that....

Erik.

Re: [Rails-devel] Prussian token lays

[Phil D. <de...@gm...>]

I can't read :p

But my lack of capacity to read rules at least found a bug so I'll
claim that as a victory :)

Thanks for the quick fix, sounds like there is a lot of headway being
made on squashing bugs for 1835!

Phil

On 25 June 2010 11:29, Erik Vos <eri...@xs...> wrote:
> This indeed was a matter of adding the PR home hex. Fixed now.
> By the way, in the (English) rules (IV.1) Berlin *is* specified as the
> Prussian home city.
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Friday 25 June 2010 11:11
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Prussian token lays
>
> The Prussian home base is Berlin, the original home of the M2 minor.
> However, this is not yet specified in the XML, so that could be the cause of
> your problem.
> I'll sort it out!
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 25 June 2010 10:44
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Prussian token lays
>
> Where is the Prussians home base for the calculation of token lays?
>
> Currently rails doesn't let the Pr lay a token (the option is provided
> but clicking the button does nothing) but I wondered how the cost for
> Pr tokens is calculated.  I cannot find this clarified in the rules.
>
> Phil
>
> ----------------------------------------------------------------------------
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ----------------------------------------------------------------------------
> --
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Prussian token lays

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

This indeed was a matter of adding the PR home hex. Fixed now.
By the way, in the (English) rules (IV.1) Berlin *is* specified as the
Prussian home city.
Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Friday 25 June 2010 11:11
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] Prussian token lays

The Prussian home base is Berlin, the original home of the M2 minor.
However, this is not yet specified in the XML, so that could be the cause of
your problem.
I'll sort it out!

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Friday 25 June 2010 10:44
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] Prussian token lays

Where is the Prussians home base for the calculation of token lays?

Currently rails doesn't let the Pr lay a token (the option is provided
but clicking the button does nothing) but I wondered how the cost for
Pr tokens is calculated.  I cannot find this clarified in the rules.

Phil

----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


----------------------------------------------------------------------------
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel