rails-devel

[Rails-devel] 1825 patch

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

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

Re: [Rails-devel] 1825 patch

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

Patch applied.  Thanks!

---Brett.



On Wed, Sep 15, 2010 at 8:12 AM, Phil Davies <de...@gm...> wrote:
> 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
>
>

Re: [Rails-devel] 1825 patch

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

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

Re: [Rails-devel] 1825 patch

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

Erik,

I hadn't really decided what to do with that row long term. I was
running a test game and found some odd behaviour when I used map
correction to rotate a tile so that it pointed one end of it's track
off map (the most obvious is that the next company to operate cannot
lay a tile!) I added the extra row as a quick get out and that worked,
honestly I forgot to remove it before submitting a patch!

Actually, yes, if you could apply that fix you suggest, for the moment
having this spare row works, I'll need to do something a bit more
permanent when I get round to adding in Unit 2 since it will use that
row but I can think about it when we get to that point!

Phil



On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:

> 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

Re: [Rails-devel] 1825 patch

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

I have create a white tile -10000 that has now replaced tile 0 for the
Q-row, and marked it as not upgradable. It is not completely invisible, as
the map background turns out to be a bit off-white. If anyone can detect
that colour's RGB value, I can apply it to this new tile too.

By the way, Paul, don't you need some of these extra tiles at the left-hand
side of Unit 1 as well?

While at tile tweaking, in the 18EU map I have also replaced tile -10 by the
-3007 (Y) and -3008 centered city tiles, that I had created specially for
18EU, but apparently overlooked to use them in the map. The Y label is now
visible, as requested by John Galt.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 16 September 2010 02:11
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Erik,

I hadn't really decided what to do with that row long term. I was
running a test game and found some odd behaviour when I used map
correction to rotate a tile so that it pointed one end of it's track
off map (the most obvious is that the next company to operate cannot
lay a tile!) I added the extra row as a quick get out and that worked,
honestly I forgot to remove it before submitting a patch!

Actually, yes, if you could apply that fix you suggest, for the moment
having this spare row works, I'll need to do something a bit more
permanent when I get round to adding in Unit 2 since it will use that
row but I can think about it when we get to that point!

Phil



On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:

> 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

----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

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

(Apologies to Phil for misspelling his name)

I have created a white tile -10000 that has now replaced tile 0 for the
Q-row, and marked it as not upgradable. It is not completely invisible, as
the map background turns out to be a bit off-white. If anyone can detect
that colour's RGB value, I can apply it to this new tile too.

By the way, Phil, don't you need some of these extra tiles at the left-hand
side of Unit 1 as well?

While at tile tweaking, in the 18EU map I have also replaced tile -10 by the
-3007 (Y) and -3008 centered city tiles, that I had created specially for
18EU, but apparently overlooked to use them in the map. The Y label is now
visible, as requested by John Galt.

Erik.

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Thursday 16 September 2010 02:11
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Erik,

I hadn't really decided what to do with that row long term. I was
running a test game and found some odd behaviour when I used map
correction to rotate a tile so that it pointed one end of it's track
off map (the most obvious is that the next company to operate cannot
lay a tile!) I added the extra row as a quick get out and that worked,
honestly I forgot to remove it before submitting a patch!

Actually, yes, if you could apply that fix you suggest, for the moment
having this spare row works, I'll need to do something a bit more
permanent when I get round to adding in Unit 2 since it will use that
row but I can think about it when we get to that point!

Phil



On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:

> 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

----------------------------------------------------------------------------
--
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


----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

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

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> 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
>
> ----------------------------------------------------------------------------
> --
> 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
>
>
> ----------------------------------------------------------------------------
> --
> 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
>
>
> ------------------------------------------------------------------------------
> 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

Re: [Rails-devel] 1825 patch

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

Yes, that should be possible.

Erik. 

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

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the
left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by
the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> 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
>
>
----------------------------------------------------------------------------
> --
> 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
>
>
>
----------------------------------------------------------------------------
> --
> 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
>
>
>
----------------------------------------------------------------------------
--
> 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

----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

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

I have added unplayable hexes to the left side where regional extensions
exist,
and removed Q21 and Q27 at the upper border, which do not exist in any
extension.
Comments in Map.xml now indicate which units and regional kits relate to
each group of unplayable hexes.

I think that for all or most other units and kits new (preprinted) tiles
need be created. I can do that - let me know when you think you are ready to
work on these extensions, at which time I will try to give it some priority.

Erik.

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

Erik,

No problem, I get mistaken for a Paul all the time ;)

Yes, I will need an extra column to the left (well, a line of hexes
that borders on that edge anyway, it jumps between two column numbers
given the hex orientation). I've been meaning to try this out at some
point but does the map XML support IfOption tags for defining hexes?
The ability to add on the extra units and extensions is going to be
useful at some point, presumeably we can make it so that the lines are
this invisible hex colour if the extensions aren't in use and put the
real hexes there if they are

Phil



On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:

> (Apologies to Phil for misspelling his name)
>
> I have created a white tile -10000 that has now replaced tile 0 for the
> Q-row, and marked it as not upgradable. It is not completely invisible, as
> the map background turns out to be a bit off-white. If anyone can detect
> that colour's RGB value, I can apply it to this new tile too.
>
> By the way, Phil, don't you need some of these extra tiles at the
left-hand
> side of Unit 1 as well?
>
> While at tile tweaking, in the 18EU map I have also replaced tile -10 by
the
> -3007 (Y) and -3008 centered city tiles, that I had created specially for
> 18EU, but apparently overlooked to use them in the map. The Y label is now
> visible, as requested by John Galt.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Thursday 16 September 2010 02:11
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> I hadn't really decided what to do with that row long term. I was
> running a test game and found some odd behaviour when I used map
> correction to rotate a tile so that it pointed one end of it's track
> off map (the most obvious is that the next company to operate cannot
> lay a tile!) I added the extra row as a quick get out and that worked,
> honestly I forgot to remove it before submitting a patch!
>
> Actually, yes, if you could apply that fix you suggest, for the moment
> having this spare row works, I'll need to do something a bit more
> permanent when I get round to adding in Unit 2 since it will use that
> row but I can think about it when we get to that point!
>
> Phil
>
>
>
> On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
>
>> 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
>
>
----------------------------------------------------------------------------
> --
> 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
>
>
>
----------------------------------------------------------------------------
> --
> 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
>
>
>
----------------------------------------------------------------------------
--
> 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

----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

[Stefan F. <ste...@we...>]

Phil:
this already adds a lot of functionality to 1825. Those rules have some nasty 
difficulties, so I think it is good work!

I had a short glance on the code and overall it seems very reasonable.

A few comments below.
Stefan

> 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 reasoess is currently work in progress, as I 
intend to add true route checks in a non 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

I have not created a test case for that, but I would guess that you should 
change the formationOrderIndex from an Integer variable to an IntegerState 
variable, as otherwise it is likely that the mechanism will fail with 
undo-actions.

And I would prefer if everything related to the formationOrderIndex is kept in 
the subclass PublicCompany_1825, as it is only used by those. 
I am usually confused by variables in a base class, which are only used in 
subclass context.

> 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.
>
Actually I only read your mail carefully after I have added the required code 
for 1825 revenue calculation. Sorry for not leaving that for you.
A good reason for that was that I had the idea for the 1825 issues already in 
mind during the implementation of the revenue modifier framework. 
And from this I knew that I had to change a few subtle issues there to allow 
the 1825 modifiers show the results correctly.
Without those the task would have been much harder.

So there are now two dynamic modifiers, which allow double heading and prevent 
termination at towns. Feel free to test and adapt them to your needs.

There is still one issue on revenue calculation: There is nothing preventing a 
train visiting two stations on a tile. The current method is to set the city 
attribute for all station of that tile to an identical value (in Tiles.xml). 
Erik already critized that and I am close to suggest that an attribute in 
TileSet.xml might be better (for example a VisitOnlyOnce attribute).

Route awareness is currently work in progress, as I intend to add true route 
checks in a hopefully not too distant future. As 1825 has some rule 
adjustments in that area, it is worth to wait for changes there. I intend to 
provide a modifier interface similar to those used for revenue calculation.

Re: [Rails-devel] 1825 patch

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

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.

I'll look into this

> And I would prefer if everything related to the formationOrderIndex is kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.

There was a reason I had to put it in the interface, although this is
probably largely due to a lack of coding skill on my part...

Oh yeah, in OperatingRound_1825, line 23:

for (PublicCompanyI company : companyManager.getAllPublicCompanies()) {

If you make that foreach loop PublicCompany_125 then
getAllPublicCompanies doesn't work because that returns a collections
of PublicCompanyI objects.  There is likely a better way to fix this
than putting that information into the interface class so if so I'm
happy to be corrected!


>> 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.
>>
> Actually I only read your mail carefully after I have added the required code
> for 1825 revenue calculation. Sorry for not leaving that for you.
> A good reason for that was that I had the idea for the 1825 issues already in
> mind during the implementation of the revenue modifier framework.
> And from this I knew that I had to change a few subtle issues there to allow
> the 1825 modifiers show the results correctly.
> Without those the task would have been much harder.
>
> So there are now two dynamic modifiers, which allow double heading and prevent
> termination at towns. Feel free to test and adapt them to your needs.

I need to look in general how the modifiers for route calculation
work, I have a lot of saved emails to trawl through when I get the
spare time :)

> There is still one issue on revenue calculation: There is nothing preventing a
> train visiting two stations on a tile. The current method is to set the city
> attribute for all station of that tile to an identical value (in Tiles.xml).
> Erik already critized that and I am close to suggest that an attribute in
> TileSet.xml might be better (for example a VisitOnlyOnce attribute).
>
> Route awareness is currently work in progress, as I intend to add true route
> checks in a hopefully not too distant future. As 1825 has some rule
> adjustments in that area, it is worth to wait for changes there. I intend to
> provide a modifier interface similar to those used for revenue calculation.
>

Re: [Rails-devel] 1825 patch

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

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Monday 20 September 2010 11:57
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

[EV] Yes, that shouldn't be too difficult. I'll try it out one of these
days.

> And I would prefer if everything related to the formationOrderIndex is
kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.

There was a reason I had to put it in the interface, although this is
probably largely due to a lack of coding skill on my part...

Oh yeah, in OperatingRound_1825, line 23:

for (PublicCompanyI company : companyManager.getAllPublicCompanies()) {

If you make that foreach loop PublicCompany_125 then
getAllPublicCompanies doesn't work because that returns a collections
of PublicCompanyI objects.  There is likely a better way to fix this
than putting that information into the interface class so if so I'm
happy to be corrected!

[EV] I already wondered why you needed this interface. I will try to sort
out if we can omit it.

Re: [Rails-devel] 1825 patch

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

See attached patch.  I've done what Stefan suggested below and changed
to an IntegerState variable for the formationOrderIndex, as well as
moving it into the specific game class.  There are potentially other
games out there where this matters but I think it's niche enough to be
in the game specific files.

This also includes the start of the StockRound_1825 where I've started
thinking about receivership.  Doesn't really do much as of yet but
it's a start.

Phil

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.
>
> And I would prefer if everything related to the formationOrderIndex is kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.
>

Re: [Rails-devel] 1825 patch

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

Applied. Thanks.
Erik. 

-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Tuesday 12 October 2010 11:09
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

See attached patch.  I've done what Stefan suggested below and changed
to an IntegerState variable for the formationOrderIndex, as well as
moving it into the specific game class.  There are potentially other
games out there where this matters but I think it's niche enough to be
in the game specific files.

This also includes the start of the StockRound_1825 where I've started
thinking about receivership.  Doesn't really do much as of yet but
it's a start.

Phil

On 17 September 2010 22:57, Stefan Frey <ste...@we...> wrote:
> I have not created a test case for that, but I would guess that you should
> change the formationOrderIndex from an Integer variable to an IntegerState
> variable, as otherwise it is likely that the mechanism will fail with
> undo-actions.
>
> And I would prefer if everything related to the formationOrderIndex is
kept in
> the subclass PublicCompany_1825, as it is only used by those.
> I am usually confused by variables in a base class, which are only used in
> subclass context.
>

Re: [Rails-devel] 1825 patch

[Stefan F. <ste...@we...>]

Another idea for those unplayable hexes, which however allow track to end 
there:
Would it possible to have those tiles show up as half-hexes (thus half green, 
half background color), similar to the boardgame map?

On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> I have added unplayable hexes to the left side where regional extensions
> exist,
> and removed Q21 and Q27 at the upper border, which do not exist in any
> extension.
> Comments in Map.xml now indicate which units and regional kits relate to
> each group of unplayable hexes.
>
> I think that for all or most other units and kits new (preprinted) tiles
> need be created. I can do that - let me know when you think you are ready
> to work on these extensions, at which time I will try to give it some
> priority.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 17 September 2010 00:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> No problem, I get mistaken for a Paul all the time ;)
>
> Yes, I will need an extra column to the left (well, a line of hexes
> that borders on that edge anyway, it jumps between two column numbers
> given the hex orientation). I've been meaning to try this out at some
> point but does the map XML support IfOption tags for defining hexes?
> The ability to add on the extra units and extensions is going to be
> useful at some point, presumeably we can make it so that the lines are
> this invisible hex colour if the extensions aren't in use and put the
> real hexes there if they are
>
> Phil
>
> On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > (Apologies to Phil for misspelling his name)
> >
> > I have created a white tile -10000 that has now replaced tile 0 for the
> > Q-row, and marked it as not upgradable. It is not completely invisible,
> > as the map background turns out to be a bit off-white. If anyone can
> > detect that colour's RGB value, I can apply it to this new tile too.
> >
> > By the way, Phil, don't you need some of these extra tiles at the
>
> left-hand
>
> > side of Unit 1 as well?
> >
> > While at tile tweaking, in the 18EU map I have also replaced tile -10 by
>
> the
>
> > -3007 (Y) and -3008 centered city tiles, that I had created specially for
> > 18EU, but apparently overlooked to use them in the map. The Y label is
> > now visible, as requested by John Galt.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Thursday 16 September 2010 02:11
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > I hadn't really decided what to do with that row long term. I was
> > running a test game and found some odd behaviour when I used map
> > correction to rotate a tile so that it pointed one end of it's track
> > off map (the most obvious is that the next company to operate cannot
> > lay a tile!) I added the extra row as a quick get out and that worked,
> > honestly I forgot to remove it before submitting a patch!
> >
> > Actually, yes, if you could apply that fix you suggest, for the moment
> > having this spare row works, I'll need to do something a bit more
> > permanent when I get round to adding in Unit 2 since it will use that
> > row but I can think about it when we get to that point!
> >
> > Phil
> >
> > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> >> 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
>
> ---------------------------------------------------------------------------
>-
>
> > --
> > 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
>
> ---------------------------------------------------------------------------
>-
>
> > --
> > 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
>
> ---------------------------------------------------------------------------
>- --
>
> > 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
>
> ---------------------------------------------------------------------------
>- --
> 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
>
>
> ---------------------------------------------------------------------------
>--- 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

Re: [Rails-devel] 1825 patch

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

Hmm... how would that be at the left hand side of the 1825U1 map (where I
have added such hexes today)?
We would need several variations of such half-hexes. 
Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 18 September 2010 00:00
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

Another idea for those unplayable hexes, which however allow track to end 
there:
Would it possible to have those tiles show up as half-hexes (thus half
green, 
half background color), similar to the boardgame map?

On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> I have added unplayable hexes to the left side where regional extensions
> exist,
> and removed Q21 and Q27 at the upper border, which do not exist in any
> extension.
> Comments in Map.xml now indicate which units and regional kits relate to
> each group of unplayable hexes.
>
> I think that for all or most other units and kits new (preprinted) tiles
> need be created. I can do that - let me know when you think you are ready
> to work on these extensions, at which time I will try to give it some
> priority.
>
> Erik.
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Friday 17 September 2010 00:45
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Erik,
>
> No problem, I get mistaken for a Paul all the time ;)
>
> Yes, I will need an extra column to the left (well, a line of hexes
> that borders on that edge anyway, it jumps between two column numbers
> given the hex orientation). I've been meaning to try this out at some
> point but does the map XML support IfOption tags for defining hexes?
> The ability to add on the extra units and extensions is going to be
> useful at some point, presumeably we can make it so that the lines are
> this invisible hex colour if the extensions aren't in use and put the
> real hexes there if they are
>
> Phil
>
> On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > (Apologies to Phil for misspelling his name)
> >
> > I have created a white tile -10000 that has now replaced tile 0 for the
> > Q-row, and marked it as not upgradable. It is not completely invisible,
> > as the map background turns out to be a bit off-white. If anyone can
> > detect that colour's RGB value, I can apply it to this new tile too.
> >
> > By the way, Phil, don't you need some of these extra tiles at the
>
> left-hand
>
> > side of Unit 1 as well?
> >
> > While at tile tweaking, in the 18EU map I have also replaced tile -10 by
>
> the
>
> > -3007 (Y) and -3008 centered city tiles, that I had created specially
for
> > 18EU, but apparently overlooked to use them in the map. The Y label is
> > now visible, as requested by John Galt.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Thursday 16 September 2010 02:11
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > I hadn't really decided what to do with that row long term. I was
> > running a test game and found some odd behaviour when I used map
> > correction to rotate a tile so that it pointed one end of it's track
> > off map (the most obvious is that the next company to operate cannot
> > lay a tile!) I added the extra row as a quick get out and that worked,
> > honestly I forgot to remove it before submitting a patch!
> >
> > Actually, yes, if you could apply that fix you suggest, for the moment
> > having this spare row works, I'll need to do something a bit more
> > permanent when I get round to adding in Unit 2 since it will use that
> > row but I can think about it when we get to that point!
> >
> > Phil
> >
> > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> >> 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
>
>
---------------------------------------------------------------------------
>-
>
> > --
> > 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
>
>
---------------------------------------------------------------------------
>-
>
> > --
> > 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
>
>
---------------------------------------------------------------------------
>- --
>
> > 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
>
>
---------------------------------------------------------------------------
>- --
> 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
>
>
>
---------------------------------------------------------------------------
>--- 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



----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

[Stefan F. <ste...@we...>]

If I am not off-track now, two variations are needed:
One for North/South and one for West/East border hexes (with appropriate
rotation). I never worked with Inkscape, thus I do not know how difficult it 
is to change the hex accordingly.
Stefan

On Saturday 18 September 2010 00:27:44 Erik Vos wrote:
> Hmm... how would that be at the left hand side of the 1825U1 map (where I
> have added such hexes today)?
> We would need several variations of such half-hexes.
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 18 September 2010 00:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Another idea for those unplayable hexes, which however allow track to end
> there:
> Would it possible to have those tiles show up as half-hexes (thus half
> green,
> half background color), similar to the boardgame map?
>
> On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> > I have added unplayable hexes to the left side where regional extensions
> > exist,
> > and removed Q21 and Q27 at the upper border, which do not exist in any
> > extension.
> > Comments in Map.xml now indicate which units and regional kits relate to
> > each group of unplayable hexes.
> >
> > I think that for all or most other units and kits new (preprinted) tiles
> > need be created. I can do that - let me know when you think you are ready
> > to work on these extensions, at which time I will try to give it some
> > priority.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Friday 17 September 2010 00:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > No problem, I get mistaken for a Paul all the time ;)
> >
> > Yes, I will need an extra column to the left (well, a line of hexes
> > that borders on that edge anyway, it jumps between two column numbers
> > given the hex orientation). I've been meaning to try this out at some
> > point but does the map XML support IfOption tags for defining hexes?
> > The ability to add on the extra units and extensions is going to be
> > useful at some point, presumeably we can make it so that the lines are
> > this invisible hex colour if the extensions aren't in use and put the
> > real hexes there if they are
> >
> > Phil
> >
> > On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > > (Apologies to Phil for misspelling his name)
> > >
> > > I have created a white tile -10000 that has now replaced tile 0 for the
> > > Q-row, and marked it as not upgradable. It is not completely invisible,
> > > as the map background turns out to be a bit off-white. If anyone can
> > > detect that colour's RGB value, I can apply it to this new tile too.
> > >
> > > By the way, Phil, don't you need some of these extra tiles at the
> >
> > left-hand
> >
> > > side of Unit 1 as well?
> > >
> > > While at tile tweaking, in the 18EU map I have also replaced tile -10
> > > by
> >
> > the
> >
> > > -3007 (Y) and -3008 centered city tiles, that I had created specially
>
> for
>
> > > 18EU, but apparently overlooked to use them in the map. The Y label is
> > > now visible, as requested by John Galt.
> > >
> > > Erik.
> > >
> > > -----Original Message-----
> > > From: Phil Davies [mailto:de...@gm...]
> > > Sent: Thursday 16 September 2010 02:11
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 1825 patch
> > >
> > > Erik,
> > >
> > > I hadn't really decided what to do with that row long term. I was
> > > running a test game and found some odd behaviour when I used map
> > > correction to rotate a tile so that it pointed one end of it's track
> > > off map (the most obvious is that the next company to operate cannot
> > > lay a tile!) I added the extra row as a quick get out and that worked,
> > > honestly I forgot to remove it before submitting a patch!
> > >
> > > Actually, yes, if you could apply that fix you suggest, for the moment
> > > having this spare row works, I'll need to do something a bit more
> > > permanent when I get round to adding in Unit 2 since it will use that
> > > row but I can think about it when we get to that point!
> > >
> > > Phil
> > >
> > > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> > >> 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
>
> ---------------------------------------------------------------------------
>
> >-
> >
> > > --:
> > > 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
>
> ---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > > 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
>
> ---------------------------------------------------------------------------
>
> >- --
> >
> > > 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
>
> ---------------------------------------------------------------------------
>
> >- --
> > 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
>
> ---------------------------------------------------------------------------
>
> >--- 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
>
> ---------------------------------------------------------------------------
>- --
> 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
>
>
> ---------------------------------------------------------------------------
>--- 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

Re: [Rails-devel] 1825 patch

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

Depending of how you want the left border look like, you might need two such
E/W border half-tiles, a small and a broad one. 

The problem with Inkscape is not to modify existing to create new ones, but
to size and tweak the result to make it fit into Rails maps. That's a pretty
delicate process. If anyone wants to try: instructions can be found in
CombineTiles.pl.

Erik.

-----Original Message-----
From: Stefan Frey [mailto:ste...@we...] 
Sent: Saturday 18 September 2010 10:56
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

If I am not off-track now, two variations are needed:
One for North/South and one for West/East border hexes (with appropriate
rotation). I never worked with Inkscape, thus I do not know how difficult it

is to change the hex accordingly.
Stefan

On Saturday 18 September 2010 00:27:44 Erik Vos wrote:
> Hmm... how would that be at the left hand side of the 1825U1 map (where I
> have added such hexes today)?
> We would need several variations of such half-hexes.
> Erik.
>
> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday 18 September 2010 00:00
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> Another idea for those unplayable hexes, which however allow track to end
> there:
> Would it possible to have those tiles show up as half-hexes (thus half
> green,
> half background color), similar to the boardgame map?
>
> On Friday 17 September 2010 20:49:06 Erik Vos wrote:
> > I have added unplayable hexes to the left side where regional extensions
> > exist,
> > and removed Q21 and Q27 at the upper border, which do not exist in any
> > extension.
> > Comments in Map.xml now indicate which units and regional kits relate to
> > each group of unplayable hexes.
> >
> > I think that for all or most other units and kits new (preprinted) tiles
> > need be created. I can do that - let me know when you think you are
ready
> > to work on these extensions, at which time I will try to give it some
> > priority.
> >
> > Erik.
> >
> > -----Original Message-----
> > From: Phil Davies [mailto:de...@gm...]
> > Sent: Friday 17 September 2010 00:45
> > To: Development list for Rails: an 18xx game
> > Subject: Re: [Rails-devel] 1825 patch
> >
> > Erik,
> >
> > No problem, I get mistaken for a Paul all the time ;)
> >
> > Yes, I will need an extra column to the left (well, a line of hexes
> > that borders on that edge anyway, it jumps between two column numbers
> > given the hex orientation). I've been meaning to try this out at some
> > point but does the map XML support IfOption tags for defining hexes?
> > The ability to add on the extra units and extensions is going to be
> > useful at some point, presumeably we can make it so that the lines are
> > this invisible hex colour if the extensions aren't in use and put the
> > real hexes there if they are
> >
> > Phil
> >
> > On 16 Sep 2010, at 23:01, Erik Vos <eri...@xs...> wrote:
> > > (Apologies to Phil for misspelling his name)
> > >
> > > I have created a white tile -10000 that has now replaced tile 0 for
the
> > > Q-row, and marked it as not upgradable. It is not completely
invisible,
> > > as the map background turns out to be a bit off-white. If anyone can
> > > detect that colour's RGB value, I can apply it to this new tile too.
> > >
> > > By the way, Phil, don't you need some of these extra tiles at the
> >
> > left-hand
> >
> > > side of Unit 1 as well?
> > >
> > > While at tile tweaking, in the 18EU map I have also replaced tile -10
> > > by
> >
> > the
> >
> > > -3007 (Y) and -3008 centered city tiles, that I had created specially
>
> for
>
> > > 18EU, but apparently overlooked to use them in the map. The Y label is
> > > now visible, as requested by John Galt.
> > >
> > > Erik.
> > >
> > > -----Original Message-----
> > > From: Phil Davies [mailto:de...@gm...]
> > > Sent: Thursday 16 September 2010 02:11
> > > To: Development list for Rails: an 18xx game
> > > Subject: Re: [Rails-devel] 1825 patch
> > >
> > > Erik,
> > >
> > > I hadn't really decided what to do with that row long term. I was
> > > running a test game and found some odd behaviour when I used map
> > > correction to rotate a tile so that it pointed one end of it's track
> > > off map (the most obvious is that the next company to operate cannot
> > > lay a tile!) I added the extra row as a quick get out and that worked,
> > > honestly I forgot to remove it before submitting a patch!
> > >
> > > Actually, yes, if you could apply that fix you suggest, for the moment
> > > having this spare row works, I'll need to do something a bit more
> > > permanent when I get round to adding in Unit 2 since it will use that
> > > row but I can think about it when we get to that point!
> > >
> > > Phil
> > >
> > > On 15 Sep 2010, at 21:39, Erik Vos <eri...@xs...> wrote:
> > >> 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
>
>
---------------------------------------------------------------------------
>
> >-
> >
> > > --:
> > > 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
>
>
---------------------------------------------------------------------------
>
> >-
> >
> > > --
> > > 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
>
>
---------------------------------------------------------------------------
>
> >- --
> >
> > > 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
>
>
---------------------------------------------------------------------------
>
> >- --
> > 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
>
>
---------------------------------------------------------------------------
>
> >--- 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
>
>
---------------------------------------------------------------------------
>- --
> 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
>
>
>
---------------------------------------------------------------------------
>--- 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



----------------------------------------------------------------------------
--
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

Re: [Rails-devel] 1825 patch

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

Well, that was simple indeed. The white fake tiles are now gone. Hexsides
can be declared "open" which means that track can be laid against these
sides even at the board edge. I have applied this to the map of 1825U1. As
far as I can see now, such track is ignored by the revenue calculator.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Monday 20 September 2010 19:46
To: 'Development list for Rails: an 18xx game'
Subject: Re: [Rails-devel] 1825 patch


-----Original Message-----
From: Phil Davies [mailto:de...@gm...] 
Sent: Monday 20 September 2010 11:57
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] 1825 patch

I kind of like the idea of having half-hexes to plug onto the top/side
of the map from an aesthetic point of view, however, in terms of time
spend, I think it might end up being more worthwhile being able to
define edges that are 'safe' for pointing track into (and that
automatically act as a terminus of 0 value perhaps?

I'm not sure how tricky that is, of course, but it would sidestep the
issue of even needing these extra fake hexes anyway.

[EV] Yes, that shouldn't be too difficult. I'll try it out one of these
days.

Re: [Rails-devel] 1825 patch

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

Excellent news, good work :)

On 20 September 2010 22:40, Erik Vos <eri...@xs...> wrote:
> Well, that was simple indeed. The white fake tiles are now gone. Hexsides
> can be declared "open" which means that track can be laid against these
> sides even at the board edge. I have applied this to the map of 1825U1. As
> far as I can see now, such track is ignored by the revenue calculator.
>
> Erik.
>
> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Monday 20 September 2010 19:46
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1825 patch
>
>
> -----Original Message-----
> From: Phil Davies [mailto:de...@gm...]
> Sent: Monday 20 September 2010 11:57
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] 1825 patch
>
> I kind of like the idea of having half-hexes to plug onto the top/side
> of the map from an aesthetic point of view, however, in terms of time
> spend, I think it might end up being more worthwhile being able to
> define edges that are 'safe' for pointing track into (and that
> automatically act as a terminus of 0 value perhaps?
>
> I'm not sure how tricky that is, of course, but it would sidestep the
> issue of even needing these extra fake hexes anyway.
>
> [EV] Yes, that shouldn't be too difficult. I'll try it out one of these
> days.
>
>
>
> ------------------------------------------------------------------------------
> 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
>