Re: [Rails-devel] 1825 patches

[Jim B. <ji...@ko...>]

A followup on operating order in 1825:

Phil>> in 1825 companies always operate in descending par value order.  
Phil>> When two companies share the same par value, they always operate
Phil>> in the order they were formed.  

Jim>> That's not right: throughout the 1825, majors operate strictly in order of
Jim>> formation (NOT par value).

Phil> This amounts to the same thing for all scenarios I can think of and is
Phil> how it's written in the rulebook (the rulebook says companies operate
Phil> in order of 'face value')

No:  formation-order is related to par-value, but it can be very different.   

In 1825, companies become available in flights, organized by par-value.  

Once /any/ company in a given flight is sold-out, then all companies/shares in the next flight become available.  

Unit 1 has 5 flights:  LNWR (100), GWR (90), GER & LSWR (76), SECR (71), LBSC (67)

And,

Phil> the GWR which must form before either the GER or
Phil> LSWR forms.  The tricky bit is catching which of those 
Phil> two forms first and this IS currently handled.

This is all true, but not sufficient.  

When /either/ GER or LSWR sells out, SECR becomes available.  And, once SECR sells out, LBSC becomes available.  

As a result, it's very possible for SECR and LBSC to operate /before/ either GER, or LSWR (but never before both).

In Unit2, there's 3 flights:  LNWR (100), MR & NER (82), GCR & GNR & L&Y (71)

It's /very/ common for only one of MR & NER to form, then sell out, while the other company stands unpurchased.  (Eg, MR forms and sells out, but no one wants NER because of its remote location. )  Then, a few companies in the 3rd flight form (GCR, GNR, and/or L&Y), before the remaining company in flight 2 every forms.  As a result, that flight 2 company operates very late- /not/ in par-value order, at all.

best,
-  jim



However, this doesn't take into account that SECR 
> Only minors operate in descending par value.

SO far away from adding minor companies at the moment but I will bear
that in mind!

> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it
> would be really helpful if this was surveyed again, before marking 1825 playable/experimental.

I will do, I 1825 up until the last week has been the map XML and
nothing more, absolutely nothing was written for it so I've not
bothered checking bug reports since I wasn't expecting anyone to try
launching it!  I'll review these and see if I need to add anything
else that isn't already on my list.  The goal for me at this stage is
to get Unit 1 playable on it's own, from start to finish with all
features covered in the core rulebook.  Once that is done I can start
thinking about mixing in other units/minors/tile packs etc.

> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings.

Yep, all working

> Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...

Currently no, in fact currently the route calculation is totally
broken for 1825 since it allows you to start and end at small towns
AND visit two stations on the same hex, both of which aren't allowed.
So for the moment I'm afraid anyone testing will have to revert to
manual routing.  Route calculation is either 2nd or 1st on my list of
things to fix...right after I work out how complicated receivership is
and which I fancy tackling first

Phil


On 15 September 2010 16:38, Jim Black <ji...@ko...> wrote:
> 
> Phil wrote:
> 
>> in 1825 companies always operate in descending par value order.
>> When two companies share the same par value, they always operate
>> ?in the order they were formed.
> 
> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
> 
> Only minors operate in descending par value.
> 
> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
> 
> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings. ?(That's really important..) ? Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
> 
> best,
> ?- jim
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 



------------------------------

Message: 4
Date: Wed, 15 Sep 2010 17:13:57 +0100
From: Phil Davies <de...@gm...>
Subject: Re: [Rails-devel] 1825 patches
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AANLkTi=6XK...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

Oh, one further item that occurs to me that's worth mentioning for
anyone that is keen to test 1825 (please bear in mind it still has
many issues and is currently only testable from the SVN codebase).

The start round works ass-backwards but functionally correctly to the
physical game.  In the boardgame, you randomise the distribution of
the private companies, then seat yourself around the table in
ascending value of private.

On rails, the method is to ensure you randomise the seating of the
players first, then during the start round, each player will be forced
to buy the appropriate private related to their seating position.
This ends up being the exact same thing but does mean that it's
important you hit that 'randomise seating' button or put people into
the startup screen in the order you have determined seating to be
using whatever external randomisation system of your choice.

Brett: This is the sort of player information I think would be useful
to have on the documentation wiki...can I get access to edit pages
there to add this sort of info?  Or at least someone create a page for
1825 that I have rights over so I can stick down thoughts like this as
they come up?

Phil

On 15 September 2010 16:57, Phil Davies <de...@gm...> wrote:
> Jim,
> 
>>> in 1825 companies always operate in descending par value order.
>>> When two companies share the same par value, they always operate
>>> ?in the order they were formed.
>> 
>> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
> 
> This amounts to the same thing for all scenarios I can think of and is
> how it's written in the rulebook (the rulebook says companies operate
> in order of 'face value')
> 
> In the case of 1825 unit 1 (which is all I've got added so far), the
> LNWR MUST form before the GWR which must form before either the GER or
> LSWR forms. ?The tricky bit is catching which of those two forms first
> and this IS currently handled.
> 
>> Only minors operate in descending par value.
> 
> SO far away from adding minor companies at the moment but I will bear
> that in mind!
> 
>> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it
>> would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
> 
> I will do, I 1825 up until the last week has been the map XML and
> nothing more, absolutely nothing was written for it so I've not
> bothered checking bug reports since I wasn't expecting anyone to try
> launching it! ?I'll review these and see if I need to add anything
> else that isn't already on my list. ?The goal for me at this stage is
> to get Unit 1 playable on it's own, from start to finish with all
> features covered in the core rulebook. ?Once that is done I can start
> thinking about mixing in other units/minors/tile packs etc.
> 
>> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings.
> 
> Yep, all working
> 
>> Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
> 
> Currently no, in fact currently the route calculation is totally
> broken for 1825 since it allows you to start and end at small towns
> AND visit two stations on the same hex, both of which aren't allowed.
> So for the moment I'm afraid anyone testing will have to revert to
> manual routing. ?Route calculation is either 2nd or 1st on my list of
> things to fix...right after I work out how complicated receivership is
> and which I fancy tackling first
> 
> Phil
> 
> 
> On 15 September 2010 16:38, Jim Black <ji...@ko...> wrote:
>> 
>> Phil wrote:
>> 
>>> in 1825 companies always operate in descending par value order.
>>> When two companies share the same par value, they always operate
>>> ?in the order they were formed.
>> 
>> That's not right: ?throughout the 1825, majors operate strictly in order of formation (NOT par value).
>> 
>> Only minors operate in descending par value.
>> 
>> Also, please review the bug incident I filed (I think Erik moved it to feature requests), enumerating many 1825 issues- it would be really helpful if this was surveyed again, before marking 1825 playable/experimental.
>> 
>> I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings. ?(That's really important..) ? Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...
>> 
>> best,
>> ?- jim
>> 
>> 
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>> 
> 



------------------------------

Message: 5
Date: Wed, 15 Sep 2010 09:49:21 -0700
From: brett lentz <bre...@gm...>
Subject: Re: [Rails-devel] 1825 patches
To: "Development list for Rails: an 18xx game"
	<rai...@li...>
Message-ID:
	<AANLkTi=5=W=LTvFmm8OMYUjA-RZe8Gq7=SG8...@ma...>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 15, 2010 at 9:13 AM, Phil Davies <de...@gm...> wrote:
> Brett: This is the sort of player information I think would be useful
> to have on the documentation wiki...can I get access to edit pages
> there to add this sort of info? ?Or at least someone create a page for
> 1825 that I have rights over so I can stick down thoughts like this as
> they come up?

Absolutely.   You should now have rights to edit the wiki.

(Which reminds me, I need to put a link to the wiki on the main homepage.)

> Phil

Anyone else that would like to help contribute to the wiki, please
ping me off-list and I'll upgrade your access.

---Brett



------------------------------

Message: 6
Date: Wed, 15 Sep 2010 22:39:42 +0200
From: "Erik Vos" <eri...@xs...>
Subject: Re: [Rails-devel] 1825 patch
To: "'Development list for Rails: an 18xx game'"
	<rai...@li...>
Message-ID: <81E9E9FF1D56401696A1A83EB3DDD3FE@ERIKVOS4>
Content-Type: text/plain;	charset="us-ascii"

Hi Phil,

Well done. 

On the Q row: I suppose you don't want to allow any tile lays on that extra
'border' row.
That can be done in TileSet.xml:
	<Tile id="0"><!-- Empty space -->
		<Upgrade id="7,8,9"
hex="-Q9,Q11,Q13,Q15,Q17,Q19,Q21,Q23,Q25,Q27"/>
	</Tile>
If you agree, I will commit that patch.

A better solution would, of course, be to have a special blank tile that is
not upgradeable (and looks a bit different too) or to create an option to
make border hexsides open for track in Map.xml. 
Such options does not yet exist, but would be nice to have. Can't promise
doing that soon!

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Wednesday 15 September 2010 17:12
To: Development list for Rails: an 18xx game
Subject: [Rails-devel] 1825 patch

Could someone review and (hopefully, if it's not too broken) apply
this patch for some updates to the 1825 implementation.

There is only one shared component (IE: not in the _1825 game specific
folder and not in the 1825 data folder) that I've hit with these
changes and that's the PublicCompany class and it's interface
PublicCompanyI.  The change I've made here is to add a
formationOrderIndex to the PublicCompany interface with the attendant
getters and setters.  The reason for doing this is that in 1825
companies always operate in descending par value order.  When two
companies share the same par value, they always operate in the order
they were formed.  This value is a simple incrementing integer value
that is a 0 for the first company at a given par, then a 1 for the
next and so on.  This seemed the easiest way to control operating
order for the OR's

Everything else is 1825 specific code so shouldn't affect any existing
games, but I'd certainly be keen on any feedback as to better/worse
ways of doing what I've done so far.

With this patch, 1825 becomes 'somewhat' playable.  The key issues
that would prevent a normal game finishing:

Tile placement: You are allowed to place track running off the board,
just not running into the sea or the blank side of a brown (grey in
rails) hex.  Currently the rails map implementation has no way of
distinguishing between 'legal' off board and 'nonlegal' offboard track
play.  I think this can be got round using map correction as long as
routeawareness and revenue calculation is turned off (the bleed from
the network going outside of the map seems to confuse it if you map
correct and point a tile outside)

Receivership and the ability to sell the presidents share to the pool
are not implemented, this is probably the 'big thing' to get 1825 to a
fully playable state, I've never played a game of the tabletop version
where someone didn't dump some company into receivership so without
that the rails implementation becomes fairly pedestrian.

Route awareness and revenue calculation: Have a variety of issues.
I'm reasonably confident I can fix these with the framework Stefan has
put together, I just haven't got round to looking at what needs doing
yet, so for the moment these two settings default to off.

Phil




------------------------------

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

------------------------------

_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel


End of Rails-devel Digest, Vol 35, Issue 18
*******************************************