Re: [Rails-devel] A question or two about the Rails XML interface.

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

Some answers to your questions:

> The existing code mentions that more than one Start Packet is possible.
> I would want to treat the KK and Hungarian minor-company shares as a
> "second start packet".
> 
> Is declaring a second <StartPacket> in data/1837/CompanyManager.xml
> enough?
> And how can I give each packet a name and have the StartRound class see
it?
> 
> The reason for using two packets is the question of what happens if
> everyone passes.  If the first start packet has items left, the StartRound
> continues but there is a discount of 10 on the next purchase, which is
> cumulative until the price reaches zero and the first player is required
to take
> an item.  But when a purchase is made, the discount resets to zero.
> 
> After the first start packet is gone, though, if everyone passes it will
cause an
> operating round.  But the KK and Hungarian minor company shares are still
a
> "start packet" in the sense that nobody can buy anything else until they
are
> gone.

No, different start packets isn't yet implemented, except for the (currently
unused) name attribute.
The concept was intended for 18US, but I'm not surprised that 1837 also
needs it.

Other games (like 1844) might also need it, so perhaps it is worthwhile to
write generic code for subsequent start packets.
The other option is to hardcode it in GameManager_1837 (perhaps
temporarily).
I'll think about it.  For now I would suggest: just create the two packets,
then we'll see how we best can deal with these.

> While I'm on the subject of CompanyManager.xml -- I suggest adding an
> option like
>         <ExchangesForPresidency company="K1"> to the declarations of state
> companies, to point back to the minor company that becomes the
> president's share (and thus starts the formation of the state company).
This
> way, StateRRFormationRound (see below) needs only the name of the state
> company as an argument.

Hmm, I would rather expect a tag named <ExchangesForPresidency> as part of
the declaration for K1.
Alternatively, <StartsMajor> or something like that might even be a better
name.
But maybe your approach is more practical.  However, I would propose a less
confusing name (at least, to me) like <Precursor> or <StartingMinor>.
 
> * * *
> 
> I also spent several hours looking through 1835's Prussian-formation code.
> I plan to generalize the PrussianFormationRound class, changing its static
> variables to class members (since there are several RRs that will use the
> mechanism and they will overlap in time), and call it
StateRRFormationRound.
> It's going a little slowly because I'm not sure of the exact sequence in
which
> some of the calls take place.
> 
> When this is done it would be possible to use the same code for 1835, but
I
> don't have any plans to touch the 1835 code at all until the whole thing
is
> working for 1837, and even then it would not be a high priority.

Agreed.

> I propose that the timing of conversions be specified in
> data/1837/Game.xml.
> The <Phase> list would get another new type of entry:
> 
>         <StateRR name="KK" action="may_start"/>
>         <StateRR name="KK" action="must_start"/>
>         <StateRR name="KK" action="all_must_merge"/>
> 
> Each of these would appear in the phase list to indicate when the event
> occurs for that company.  Where there isn't a choice of timing (as for the
> Southern National, which must form AND all its minors must merge as soon
> as the first 4-train is purchased), the earlier steps can be skipped;
> "all_must_merge" will do the whole job in that case.

Sounds good, but perhaps we can better create a more generic <Action> tag
for such specials.  
Something like <Action type="formStateRR" company="KK" step="may_start"/>
etc.

I remember phase actions have been discussed in the past, but I'll have to
refresh my memory on that subject.

> For the coal companies, which also must merge into major companies but
> they don't cause the formation of the major companies, I plan a
"lightweight"
> version of the same merge mechanism (since for each one there will be an
> interval where the coal company owner gets asked about merging at the
> beginning of every round, just like the minor companies).  The two will be
> related since I want to present each player with only one dialog for this
> purpose per round, even if it grows so large it needs scroll bars.

Agreed.

Erik.