Re: [Rails-devel] Buying trains

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

That's not valid XML, but I understand what you mean.  You probably refer to
the 18EU minor free 2-trains. An extra 'sellable="no"' attribute would fix
such a train.

An important difference is, however, that that the 1825 built-in trains are
expensive and must be paid for before these trains can run.

I suppose it will become a mix of XML and some special code in
PublicCompany_1825.

 

Erik.

 

Van: Chris Shaffer [mailto:chr...@gm...] 
Verzonden: donderdag 17 maart 2011 14:58
Aan: Development list for Rails: an 18xx game
Onderwerp: Re: [Rails-devel] Buying trains

 

For built in trains, which also exist in the 18MEX minors, how about
<BuyFromCompany="no"/>.


--
Chris

Please consider the environment before printing this e-mail.



On Thu, Mar 17, 2011 at 4:20 AM, Erik Vos <eri...@xs...> wrote:

My remarks on train buying in Rails (see inclusion below) came hidden behind
a post on a different topic, which is probably why these remarks has not
drawn any attention.
It's about how to incorporate complex features like double-sided train cards
(like the 2/1G in 18VA) and trains that come with privates (18GA). I would
add now: built-in trains, as some 1825 minors have.

The new TrainCertificate objects would normally be hidden and created
automatically from existing XML code like
       <Train name="2" majorStops="2" cost="80" amount="6" />

For double-sided trains I would propose something like (for 18VA):
       <TrainCertificate name="2/1G" cost="100" quantity="6">
               <Train name="2" majorStops="2"/>
               <Train name="1G" majorStops="1">
                       <Score towns="yes"/>
               </Train>
       </TrainCertificate>
Perhaps one or more additional attributes could to be added to denote Mine
and CMD access and scoring details, but actually I think these details are
so game-specific that these might as well be hardcoded.  In any case, I
leave that to Stefan Frey to decide and work out.

In the above case, the price is in the <TrainCertificate> tag, but in 18Scan
it will be in the <Train> tags because there the two trains on one card have
different prices.
(And I would replace the ambiguous 'amount' by the explicit 'quantity'
throughout. Perhaps also 'cost' by 'price'?).

I'm not yet sure how to incorporate the 18GA OSR special property (extra
2-train).  It's not a SpecialProperty in the Rails sense of the word, as
it's invocation isn't a separate user action; it happens automatically at
some point, as a side effect of another action.

Part of the new approach to train buying would be, that new Train objects
are created when acquired by a company, not at the start of the game. That
nicely fits with how the 18GA OSR SP works.
The extra 2-train creation could be entirely hardcoded,  or we could add a
TrainCertificate to the <StartPacket><Item> or the <Company> tags.  I'm
looking for a solution that would also cover the built-in trains of some
1825 minors.

I'm also not yet sure if this approach will keep old saved files backwards
compatible, although that would be a goal.  But at some point we'll have to
bite the bullet.

Ideas welcome. Otherwise I'll work it out by myself (later).

Erik.

> -----Oorspronkelijk bericht-----> Van: Erik Vos
[mailto:eri...@xs...]
> As an example, I've already concluded that my suggestion to Adam about the
> 18GA OSR free 2-train is too simple and will not work that way.  And there
is
> another looming problem with trains: the two-way train certificates as
exist
> in e.g. 18VA and 18Scan.  My current thinking is that we need to separate
> buyable trains from actual trains throughout. The former could be named
> TrainCertificates. For example: an 18Scan 4/3+3-train certificate would
then
> be linked to two actual trains.  At buying time, the player must decide
which
> train is actually bought, and that train is acquired by the company; the
other
> one is lost.  Similarly in 18GA, a extra 2-train certificate would not
normally be
> buyable, but be linked to the OCR private.
> Once this idea has been programmed, all usual cases would still be
> configurable in the XML.  For 18GA, extra Java programming will then be
> required only to accomplish the automatic transfer of the train, either to
the
> company or to the scrapheap, at the time that the private is bought by a
> company (even that could be made configurable, but I'm reluctant to add
> code to the generic code base that's applicable to one game only).




----------------------------------------------------------------------------
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel