rails-devel — List for discussion of Rails development

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

[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

[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...>]

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 patches

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

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

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

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

> Phil

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

---Brett

Re: [Rails-devel] 1825 patches

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

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

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

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

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

Phil

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

Re: [Rails-devel] 1825 patches

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

Jim,

>> in 1825 companies always operate in descending par value order.
>> When two companies share the same par value, they always operate
>>  in the order they were formed.
>
> That's not right:  throughout the 1825, majors operate strictly in order of formation (NOT par value).

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

In the case of 1825 unit 1 (which is all I've got added so far), the
LNWR MUST form before the GWR which must form before either the GER or
LSWR forms.  The tricky bit is catching which of those two forms first
and this IS currently handled.

> Only minors operate in descending par value.

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

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

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

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

Yep, all working

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

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

Phil


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

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

[Rails-devel] 1825 patches

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

Phil wrote:

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

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

Only minors operate in descending par value.

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

I'm curious whether you implemented the update to allow 1-4 steps on the stock-market, depending on the size of earnings.  (That's really important..)   Also, whether running 2 2-trains as 1 3-train works in the revenue-calc engine...

best,
  - jim

[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] Rails 1.4 18EU playtest with commentary

[John D. G. <jd...@di...>]

Erik Vos wrote:
> OK, thanks.
> 
> Next question: would you like the income-per-OR be updated continuously
> during that OR (which means that all values need to be reset to 0 at the
> start of the OR), or just once when an OR is finished (so that the previous
> value remains visible up to that point)?

If I were writing it, it would update at the end of each OR (and maybe log
itself to make look-back possible).

Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

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

OK, thanks.

Next question: would you like the income-per-OR be updated continuously
during that OR (which means that all values need to be reset to 0 at the
start of the OR), or just once when an OR is finished (so that the previous
value remains visible up to that point)?

Erik.

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Sunday 12 September 2010 22:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

Erik Vos wrote:
> *  It would be nice if the Game Status window had a column showing each
> player's total income in the last round.  This would act as a reminder
that
> the player who is falling furthest behind had better DO SOMETHING! (and
> conversely, that the player who is making the most money should probably
not
> change the status quo, by buying lots of trains or starting new
companies).
> 
> [EV] The question here is: what cash gains qualify as income?
> I would say:
> - payments by owned private companies
> - all dividends paid out for owned shares
> but not:
> - cash received for sold properties (shares, tokens, whatever)
> The main issue being:
> - will share value increase count as income (and decrease as negative
> income)?
> 
> Another, but related, question is: do we add up income in Operating Rounds
> only, of in all rounds?

It should probably include all changes to net worth, since that is how I
would want to make the decision to be active or passive.

The one thing I liked in Avalon Hill's computer 1830 that isn't in Rails is
the graph you can display (click on History, then Players) that compares you
to the other players, round by round as the game progresses.

(I'm studying accounting, and one of these days I'm going to end a round in
a PBEM 18xx game by sending out a set of GAAP financial statements, just to
freak the other players out.)

----------------------------------------------------------------------------
--
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] Rails 1.4 18EU playtest with commentary

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

I went ahead and created bug and feature requests for most of these.  It's
not always clear what should be a bug and what should be a feature request,
so most of them are listed as bugs.

--
Chris

Please consider the environment before printing this e-mail.


On Sat, Sep 11, 2010 at 10:04 PM, Chris Shaffer <chr...@gm...>wrote:

> I'm really not sure.  I'd hate to have the tracker auto-post to this list,
> which I think would be the only solution.  Encouraging people to post here
> if they feel discussion is warranted and also post actual feature requests
> and bug reports is probably best.
>
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Sat, Sep 11, 2010 at 9:45 PM, brett lentz <bre...@gm...>wrote:
>
>> What could be done to make the process easier?
>>
>> ---Brett.
>>
>>
>>
>> On Sat, Sep 11, 2010 at 7:08 PM, Chris Shaffer <chr...@gm...>
>> wrote:
>> > The disadvantage of simply filing bugs and feature requests, of course,
>> is
>> > that there is virtually no discussion of them, because they are not seen
>> by
>> > 90% of the people on this list.
>> >
>> > I often file the bug or feature request and also post here, but that's
>> > double work.
>> >
>> > --
>> > Chris
>> >
>> > Please consider the environment before printing this e-mail.
>> >
>> >
>> > On Sat, Sep 11, 2010 at 11:27 AM, Erik Vos <eri...@xs...> wrote:
>> >>
>> >> All good suggestions, and all of these would make nice entries in the
>> >> Feature Request or Bug Report lists. That would have the added benefit
>> >> that
>> >> any discussions can be saved there too.
>> >>
>> >> Some comments from my side; some aspects I will have to leave to
>> Stefan.
>> >>
>> >> Just one general remark: some ideas sound simple, and in theory
>> anything
>> >> is
>> >> possible, but we should keep in mind that there is always a price,
>> however
>> >> small. Additional complexity, slower speed, or just larger code. We
>> should
>> >> not make Rails so big that the word "bloated" starts coming to mind.
>> >>
>> >> Erik
>> >>
>> >> -----Original Message-----
>> >> From: John David Galt [mailto:jd...@di...]
>> >> Sent: Saturday 11 September 2010 04:32
>> >> To: rai...@li...
>> >> Subject: [Rails-devel] Rails 1.4 18EU playtest with commentary
>> >>
>> >> Comments on Rails 1.4, tested with a four player game of 18EU
>>  2010-09-09
>> >>
>> >> General comments:
>> >>
>> >> *  In the "select game" dialog box, changing to a different game should
>> >> not
>> >> cause all players to be set back to "none" and the names blanked.
>> >>
>> >> [EV] Sure. That's a bug to me.
>> >>
>> >> *  The map should show "Y", where needed, on unbuilt city hexes.  This
>> is
>> >> a
>> >> major annoyance during the start round, because it affects both the
>> city's
>> >> revenue and the possible shapes of the yellow tile, so not seeing it
>> makes
>> >> it hard to predict the values of minors.  (Yes, I know, I can find this
>> >> out
>> >> by mousing-over each one, but that is annoying.)
>> >>
>> >> [EV] I'm a bit surprised that you consider this an annoyance. For me,
>> the
>> >> hard and fast rule is that all minor start cities are either preprinted
>> >> yellow or Y cities, and vice versa. But it is easy to create an extra
>> >> blank
>> >> Y city tile, so that's on my list.
>> >>
>> >> *  The map also ought to show the values of red areas.  (I would treat
>> >> each
>> >> one as a "tile" with a negative number that gets upgraded by phase
>> >> changes.)
>> >>
>> >> [EV] Creating a separate red tile for each possible revenue value
>> sounds
>> >> like overkill to me. Another idea could be to overprint red tiles with
>> the
>> >> current revenue value. The problem is that such values will look
>> similar
>> >> to
>> >> tile laying cost.
>> >> Talking about "the map" - I would love it if we would have map images
>> (as
>> >> SVG files). Then we could show any info we would like.
>> >>
>> >> *  Entering a comment before the first action in the game should be
>> >> allowed.
>> >>
>> >> *  Entering two comments in a row should append, not replace.
>> >>
>> >> [EV] I leave these two for Stefan.
>> >>
>> >> *  It would be nice if the Game Status window had a column showing each
>> >> player's total income in the last round.  This would act as a reminder
>> >> that
>> >> the player who is falling furthest behind had better DO SOMETHING! (and
>> >> conversely, that the player who is making the most money should
>> probably
>> >> not
>> >> change the status quo, by buying lots of trains or starting new
>> >> companies).
>> >>
>> >> [EV] Great suggestion. High on my list.
>> >>
>> >> *  It would be nice if the program could remember (or let you save in a
>> >> config file) the locations of every window, so you don't have to move
>> them
>> >> manual every time you start a game (and often afterward too).  I always
>> >> use
>> >> these settings.
>> >>   Stock market: upper left corner of screen
>> >>   "Game Status" tabulation/stock round input: lower left corner of
>> screen
>> >>   Map/operating round input: upper right corner of screen (and don't
>> allow
>> >>       the height to self-adjust so it's taller than the screen height
>> >> minus
>> >>       the Windows menu bar -- it now does so at the start of every OR
>> >> until
>> >>       there are too few companies to cause it (in my case, 10
>> companies).
>> >>       The map also moves so it extends about an inch to the right of
>> the
>> >>       screen, every time.)
>> >>   History/comment window: lower right corner
>> >>
>> >> [EV] I believe Stefan is already considering this one.
>> >>
>> >> All of the above apply to all games, except that I believe the 1830 and
>> >> 1835
>> >> maps do show you where the lettered tiles go.  Due credit: 18EU does
>> show
>> >> the two "B-V" hexes.
>> >>
>> >> Start round:
>> >>
>> >> *  It would be nice to have alternate starts available, such as any
>> >>   combination of:
>> >>   $400 each to start;
>> >>   all starting prices reduced to $50;
>> >>   bidding round order 1,2,3,4,4,3,2,1,1,2,3,4,4,3,2.
>> >>
>> >> [EV] "such as" - where do the possibilities end? However, your
>> suggestions
>> >> sound like a sensible subset of the infinite universe of possible
>> >> alternatives.
>> >>
>> >> *  "Unlimited tiles" should not be an all-or-nothing setting: there
>> should
>> >> be a setting to make only #7, #8, and #9 unlimited (this is what the
>> rules
>> >> say to do in 18EU, 1826, and 1853v2, and probably many other games).
>> >>
>> >> [EV] I cannot find this in the 18EU rules. However, it's a common
>> >> extension,
>> >> and I agree that it could be a generic option.
>> >>
>> >> *  Bids (above the starting value) look the same as the prices of
>> things
>> >> you've already bought.  Please change this: it makes it nonobvious who
>> >> already owns more companies than others.
>> >>
>> >> *  There should be some visual indication of which players can still
>> bid
>> >> on
>> >> the current item.
>> >>
>> >> *  A player is correctly skipped when an item someone else selected for
>> >> bidding would cost more than he has.  But if it's your turn to select
>> an
>> >> item and you have less than $100, "Bid" ought to be grayed out and
>> isn't.
>> >>
>> >> [EV] Three sensible UI improvements for the start rounds.
>> >>
>> >> Operating rounds:
>> >>
>> >> *  The map should show the reserved hexes controlled by certain minors.
>> >> (I don't expect them to be enforced yet, just shown.)
>> >>
>> >> [EV] Agree. I think there should be a generic configuration option to
>> add
>> >> any text to any tile.
>> >>
>> >> *  Please enforce the rule that minors can't lay green tiles.
>> >>
>> >> [EV] I'm pretty sure that this worked correctly until recently. Stefan,
>> I
>> >> think to have been working on the tile laying rules - can you please
>> >> check?
>> >>
>> >> *  When no tile lay is legally possible, please skip the tile-lay step.
>> >> (Which would mean that after the first couple of rounds, most minors'
>> >> tile-
>> >> lay step would be skipped, speeding up the game a lot.)
>> >>
>> >> [EV] This can only be done if the current disconnect between knowing
>> about
>> >> legal lays (in the UI only) and the round/step management (in the game
>> >> engine) has been fixed. Be aware, though, that any additional action
>> skips
>> >> will make all previous saved files unloadable, insofar these contain
>> >> pass/done actions that are now skipped. I'm very reluctant to do add or
>> >> remove such steps, as that will (again) invalidate many of my saved
>> files
>> >> that I use for testing.
>> >>
>> >> *  When placing tile #581 (green upgrade) in Berlin and trying it both
>> >> ways
>> >> it will go, the tokens that are already there (#9 and KPEV, which I
>> formed
>> >> from #7) are shown, respectively, along the SE and NW edges, rather
>> than
>> >> the
>> >> NE and SW which are the existing connections they must keep.  They move
>> to
>> >> the correct places once I make the tile lay final, but showing them
>> wrong
>> >> makes it harder to place the tile correctly.
>> >>
>> >> [EV] Will look at that. Don't hold your breath - token repositioning on
>> >> upgrades is one of the most complex processes we now have.
>> >>
>> >> *  It would be nice if I were allowed to have the program compute runs
>> >> before I decide what tile to lay.  Sometimes a company is so spread out
>> it
>> >> isn't obvious where its trains are going.  (Of course I can always work
>> >> around this by skipping the tile lay step, then "undo".)
>> >>
>> >> [EV] That's again for Stefan, I think.
>> >>
>> >> *  When deciding whether to pay, split, or withhold, it would be nice
>> if
>> >> the screen showed how much money the company will have after each
>> choice.
>> >> This isn't always easy to work out in your head, especially if there
>> are
>> >> some shares paying dividends into the treasury.  This goes for all
>> games.
>> >>
>> >> [EV] Where should the screen show that? Below each of these buttons?
>> >>
>> >> *  Please get rid of the pop-up "<company> owns no trains, so revenue
>> is
>> >> $0."  Instead, just silently skip the revenue-setting step.
>> >>
>> >> [EV] Agree.
>> >>
>> >> *  The column that now reports "Pay out", "Withhold", or "Split" for
>> the
>> >> last turn of each company ought to say "$0 income" (or maybe "No run"
>> or
>> >> "No train") when that is true, so it doesn't look like the owner chose
>> to
>> >> withhold.
>> >>
>> >> [EV] A sensible refinement.
>> >>
>> >> *  A company's train-buying step is correctly skipped if it has no room
>> >> for
>> >> another train, but it should also be skipped (that is, "Buy Train"
>> should
>> >> be grayed out) if the company has $0 and at least one train.
>>  Similarly,
>> >> if
>> >> a company spends its last dollar on a train (including forced
>> purchases),
>> >> its train-buying step should immediately end.
>> >> (I believe this goes for all games -- or does anyone on this list
>> really
>> >> think that any game exists in which a train "purchase" from another
>> >> company
>> >> for $0 is allowed?  But even if you do, it's explicitly banned in
>> 18EU.)
>> >>
>> >> [EV] Right, but see my above remark on skipping existing actions.
>> >>
>> >> *  When it's impossible for the company to buy or sell any treasury
>> >> shares,
>> >> the TRADING TREASURY SHARES step should be skipped.  (I'm mostly
>> thinking
>> >> of the situation when all shares of the company are owned by players,
>> but
>> >> it also applies if the company has no shares in treasury and has too
>> >> little
>> >> cash to buy one from the bank pool, or there are 5 shares in the bank
>> pool
>> >> and the company has too little cash to buy one.)  Because of the change
>> of
>> >> focus, this is a major waste of time, especially in the late game when
>> the
>> >> only shares not owned by players are those of companies that were never
>> >> started.
>> >>
>> >> [EV] Yes, that makes sense, but see above.
>> >>
>> >> *  Buying and selling treasury stock works correctly, except one minor
>> >> detail: when I mouse-over the "treasury shares" column, the tooltip
>> says
>> >> "click to select for buying" (even though it would be selling).
>> >>
>> >> [EV] OK.
>> >>
>> >> Stock rounds:
>> >>
>> >> *  When floating a new company, if I buy until I have 60% and then
>> merge
>> >> in
>> >> another minor company (to get more than 60% until the next stock round,
>> >> which is specifically allowed in the rules) the exchange occurs but the
>> >> "Done" button stays grayed out, making it impossible to continue the
>> game
>> >> without Undoing the exchange.
>> >>
>> >> [EV] Will look at that bug (if Stefan doesn't beat me)
>> >>
>> >> *  If I start a company (purchase the president's share) and then Undo
>> the
>> >> act of forming it, the status window continues to show the company with
>> >> the
>> >> share price I set.
>> >>
>> >> [EV] Guess we're missing a state variable here.
>> >>
>> >> *  When I buy shares from a company's treasury, the amount of money in
>> >> that
>> >> treasury is usually not updated right away.
>> >>
>> >> [EV] OK
>> >>
>> >> Ending:
>> >>
>> >> *  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
>> >> just change the space on the Game Status window where the amount of
>> money
>> >> in the bank is normally shown to say "BROKEN", maybe in bright colors.
>> >>
>> >> [EV] The former is simple, the latter a bit less so, but I agree.
>> >>
>> >> *  The repeated pop-ups that "count down" to the winning player are
>> even
>> >> more annoying.
>> >>
>> >> [EV] Fully agree. Luckily I can plead innocence here...
>> >>
>> >>
>> >>
>> ----------------------------------------------------------------------------
>> >> --
>> >> 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] Rails 1.4 18EU playtest with commentary

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

On Saturday, September 11, 2010 04:31:31 am John David Galt wrote:
> Comments on Rails 1.4, tested with a four player game of 18EU  2010-09-09

A list of comments on those topics, which Erik left to me ;-)
I categorize them into (potential) bugs and UI improvements.
Some short  opinions on other issues at the end.
Stefan

(Potential) bugs:
*  Please enforce the rule that minors can't lay green tiles.

SFY: First a general remark how Rails checks conditions: 
In general the game engine has two types of checks. 

At the time of generating available actions for the UI (ex-ante) 
and after the player chose/specified an action (ex-post).
Some actions are passed pretty generic to the UI (for example tile lays: it 
simply
states the tile colour). For those the UI has additional validation checks
during the process of specification.
The ex-post checks usually cover every aspect to prevent any action going 
through which
violate an 18xx rule, but it can only raise an error. 

So in the case above:
For minors the game engine only creates yellow tile lay actions (as shown by 
the 
instruction text above the map). The UI does not consider that and still 
suggest green tiles
(this is an omission), but the game engine complains later that a minor is not 
allowed to lay
green tiles. However if you were really able to lay a green tile with a minor, 
please forward the 
game file.

Remark: This is similar to the tile lay on Ludwigshafen/Mannheim: Only the 
ex-post check prevents the special tile lay there in yellow, the ex-ante 
generation 
does not know which tile the Pfalzbahn could lay.

*  A player is correctly skipped when an item someone else selected for
bidding would cost more than he has.  But if it's your turn to select an
item and you have less than $100, "Bid" ought to be grayed out and isn't.

SFY: I hope again that this is only the ex-ante check missing, the game engine 
should
still complain that a bid is not possible here.

UI improvements:

*  Entering a comment before the first action in the game should be allowed.

SFY: This would change with an option to comment before actions in general. 
But then it is not possible to comment after the game has ended... 

*  Entering two comments in a row should append, not replace.

SFY: Current behavior is to suggest the previous entered comment in the text 
field.
Maybe a larger editing window makes sense. Comments so far are plain Strings 
related to
actions and for now I would prefer to keep things simple.

*  It would be nice if the program could remember (or let you save in a
config file) the locations of every window, so you don't have to move them
manual every time you start a game (and often afterward too).  I always use
these settings.
   Stock market: upper left corner of screen
   "Game Status" tabulation/stock round input: lower left corner of screen
   Map/operating round input: upper right corner of screen (and don't allow
       the height to self-adjust so it's taller than the screen height minus
       the Windows menu bar -- it now does so at the start of every OR until
       there are too few companies to cause it (in my case, 10 companies).
       The map also moves so it extends about an inch to the right of the
       screen, every time.)
   History/comment window: lower right corner

SFY: Currently have a prototype working, but there is still some need to 
discuss
which window properties are saved. My general opinion on UI is that the use of 
advanced libraries (adding a docking framework like JDock and improved layout 
managers like MIGLayout)
should be the foundation in the longer run.

*  When no tile lay is legally possible, please skip the tile-lay step.
(Which would mean that after the first couple of rounds, most minors' tile-
lay step would be skipped, speeding up the game a lot.)

SFY: As Erik pointed out already: At the beginning of the tile laying step 
the game engine does not know that no tile lay is possible. I am working
on the whole tile laying process since I have the route algorithm working, but
it is not trivial, as it should support not only the permissive, but also the 
restrictive/semi-restrictive rule-set.

*  It would be nice if I were allowed to have the program compute runs
before I decide what tile to lay.  Sometimes a company is so spread out it
isn't obvious where its trains are going.  (Of course I can always work
around this by skipping the tile lay step, then "undo".)

SFY: Very good suggestion, pretty easy to change. I wonder if this should 
be an UI configuration. (The game option for revenue calculation is a general
allow/disallow switch, how it works precisely is maybe up to each player?)

*  Please get rid of the pop-up "<company> owns no trains, so revenue is
$0."  Instead, just silently skip the revenue-setting step.

*  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
just change the space on the Game Status window where the amount of money
in the bank is normally shown to say "BROKEN", maybe in bright colors.

SFY: All of those dialogs are created by the general-purpose DisplayBuffer 
mechanism, which
allows the backend to transmit messages to the user. The question is what 
exactly is evil:
Modal or pop-up? Changing those dialogs to non-modal is an easy change, but I 
suspect that
the pop-up behavior is the one in question.
The route information used to be a pop-up too and I moved that to the message 
panel above 
the map. For this I modified the MessagePanel class, which now allows to add 
additional and/or
optional text to display. It is possible to make the information available 
there. 
This would require to add the message panel to the Stock/Status window.
The double-pop-up is an application of a flag to display that message to the 
following player, 
but that can be easily removed.

*  The repeated pop-ups that "count down" to the winning player are even
more annoying.

SFY: At the time I fixed the UNDO behavior of the game end I took the liberty 
to emulate
the behavior of Lemmi's moderator which has this dramatic display of players 
wealth at the
end of the game. I agree that this makes only sense, if players total wealth 
is not displayed
anyway throughout the game, but this is another option I would like to add for 
ftf-play.  

Other (which Erik already commented on):
- Y: I support different preprinted tiles for Y-cities, which would not 
require to
specify the hexes in TileSet.xml

- Map labels: The map.xml already supports labels (see 1830 example). However 
it is not drawn yet. 
Again strong support here. (Would be even nice to be able to toggle on/off the 
city names).

- Action skipping: For the recent 18EU action auto passing I used a different 
approach to skip actions automatically. 
Instead of not creating those actions, the actions are still generated, but 
are selected automatically.
This should work on many occasions as well. But I wonder if this should be 
configurable as well,
as it might confuse newbies (why does my company always get skipped?).

Re: [Rails-devel] Rails 1.4 1835 playtest - hangs early

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

The bug you refer below is the self-nationalisation bug, which has Rails 
create ex-ante nationalisation actions for the own holdings, an action which 
cannot be processed ex-post. You can still continue playing, but it is not 
possible to sell stocks after crossing the threshold for nationalization in 
Rails 1.4. This is fixed in development.

Stefan

For reference I copy the list of fixes in 1835 from a previous mail, but I 
admit most descriptions are more technical than descriptive.

- Tile 213 update was incorrect
- Pr funding money not given, but see TODO 1
- PR formation round acted as a stock round (side effect: price increase, 
wrong round names), removed call to super.finishRound()
- Undo inside PR formation round creates weird states, fixed by changing to 
linked moveSets
- Nationalisation did not check certificate limits before action (post-action 
check was ok)
- Nationalisation prevents selling of stocks (due to self-nationalisation bug)
- Pr 5% shares report only 1/4 of value, 10% shares only 1/2 of value(report 
window, executed correctly fixed currentSellPrice, see TODO 2 and 3, adjusted 
output)
- Added manual closing of OBB

Remaining TODOs:
1) Implement SharePriceUnits everywhere it is appropriate (e.g. Round method 
floating())
2) SellPrices is not a stateful map (=> undo side effects!)
3) Selling PR president is shown as selling two 5 percent shares (which might 
be correct) but selling those creates all kind of crazy effects


On Sunday, September 12, 2010 10:32:05 pm John David Galt wrote:
> John David Galt wrote:
> >> I tried it with 1835.  Contrary to what I wrote in the 18EU review, the
> >> 1835 map doesn't show the Y or XX hexes.
> 
> My mistake.  It does show the XX hexes, just not the Y.
> 
> >> I got as far as laying tiles with the BY in OR1 (thanks for changing the
> >> company names!)  Then it hangs (no "Buy Train" button, "Done" is grayed
> >> out, and I don't even get the usual dialog saying BY has no train.)
> 
> Stefan Frey wrote:
> > I have seen this bug before: It seems that the tile lay phase does not
> > end correctly, if the special tile lay of the OBB comes after the
> > regular tile lays. I had not time yet to follow this up, so I do not
> > know if this comes from the fact that there are already multiple lays
> > allowed or that OBB itself allows two independent lays.
> > 
> > Fortunately there is a quick workaround: Simply lay the OBB tile first,
> > followed by the regular ones. This works on your save file too.
> 
> Thanks, that works.
> 
> > Be aware that there are still several bugs ahead of your party. Some of
> > them already fixed in development, but some other still need further
> > investigation. (Nearly all of them related to PR merger/creation).
> 
> I continued this game just to see what other glitches I could find, and did
> find several more.  It hung (sort of) partway through a stock round, about
> halfway through the game (the next train to be purchased will be the 4 and
> trigger PR formation, but I'm not there yet).  Here's a new save file with
> commentary in it.
> 
> > And thanks for your excellent and interesting comments from your 18EU
> > play. I will try to follow up, but time is a rare good at the moment.
> 
> I haven't yet managed to get a build to work locally, but I am trying to
> help you out & not just complain.

Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

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

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Sunday 12 September 2010 22:37
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

(I'm studying accounting, and one of these days I'm going to end a round in
a PBEM 18xx game by sending out a set of GAAP financial statements, just to
freak the other players out.)

[EV] Or put them to sleep. Gaap is the Dutch word for yawn (noun).

Erik.

Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

[John D. G. <jd...@di...>]

Erik Vos wrote:
> *  It would be nice if the Game Status window had a column showing each
> player's total income in the last round.  This would act as a reminder that
> the player who is falling furthest behind had better DO SOMETHING! (and
> conversely, that the player who is making the most money should probably not
> change the status quo, by buying lots of trains or starting new companies).
> 
> [EV] The question here is: what cash gains qualify as income?
> I would say:
> - payments by owned private companies
> - all dividends paid out for owned shares
> but not:
> - cash received for sold properties (shares, tokens, whatever)
> The main issue being:
> - will share value increase count as income (and decrease as negative
> income)?
> 
> Another, but related, question is: do we add up income in Operating Rounds
> only, of in all rounds?

It should probably include all changes to net worth, since that is how I
would want to make the decision to be active or passive.

The one thing I liked in Avalon Hill's computer 1830 that isn't in Rails is
the graph you can display (click on History, then Players) that compares you
to the other players, round by round as the game progresses.

(I'm studying accounting, and one of these days I'm going to end a round in
a PBEM 18xx game by sending out a set of GAAP financial statements, just to
freak the other players out.)

Re: [Rails-devel] Rails 1.4 1835 playtest - hangs early

[John D. G. <jd...@di...>]

John David Galt wrote:
>> I tried it with 1835.  Contrary to what I wrote in the 18EU review, the
>> 1835 map doesn't show the Y or XX hexes.

My mistake.  It does show the XX hexes, just not the Y.

>> I got as far as laying tiles with the BY in OR1 (thanks for changing the
>> company names!)  Then it hangs (no "Buy Train" button, "Done" is grayed
>> out, and I don't even get the usual dialog saying BY has no train.)

Stefan Frey wrote:
> I have seen this bug before: It seems that the tile lay phase does not end 
> correctly, if the special tile lay of the OBB comes after the regular tile 
> lays. I had not time yet to follow this up, so I do not know if this comes 
> from the fact that there are already multiple lays allowed or that OBB itself 
> allows two independent lays.
> 
> Fortunately there is a quick workaround: Simply lay the OBB tile first, 
> followed by the regular ones. This works on your save file too.

Thanks, that works.

> Be aware that there are still several bugs ahead of your party. Some of them 
> already fixed in development, but some other still need further investigation. 
> (Nearly all of them related to PR merger/creation).

I continued this game just to see what other glitches I could find, and did
find several more.  It hung (sort of) partway through a stock round, about
halfway through the game (the next train to be purchased will be the 4 and
trigger PR formation, but I'm not there yet).  Here's a new save file with
commentary in it.

> And thanks for your excellent and interesting comments from your 18EU play.
> I will try to follow up, but time is a rare good at the moment.

I haven't yet managed to get a build to work locally, but I am trying to help
you out & not just complain.

Re: [Rails-devel] Add group

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

done... 
Thanks for splitting up into specific artifacts.
Stefan

On Sunday 12 September 2010 17:47:25 Chris Shaffer wrote:
> Could someone add the group 1.4 to the tracker, so bugs and feature
> requests can be appropriately tagged?
>
> Thanks.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.

[Rails-devel] Add group

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

Could someone add the group 1.4 to the tracker, so bugs and feature requests
can be appropriately tagged?

Thanks.

--
Chris

Please consider the environment before printing this e-mail.

Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

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

*  It would be nice if the Game Status window had a column showing each
player's total income in the last round.  This would act as a reminder that
the player who is falling furthest behind had better DO SOMETHING! (and
conversely, that the player who is making the most money should probably not
change the status quo, by buying lots of trains or starting new companies).

[EV] The question here is: what cash gains qualify as income?
I would say:
- payments by owned private companies
- all dividends paid out for owned shares
but not:
- cash received for sold properties (shares, tokens, whatever)
The main issue being:
- will share value increase count as income (and decrease as negative
income)?

Another, but related, question is: do we add up income in Operating Rounds
only, of in all rounds?

I would say that the player's 'worth' increase/decrease per OR would be the
best indicator of his/her future prospects. That would then include share
value changes, but only in Operating Rounds.

Other opinions?

Erik.

Re: [Rails-devel] Rails 1.4 18EU playtest with commentary

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

I'm really not sure.  I'd hate to have the tracker auto-post to this list,
which I think would be the only solution.  Encouraging people to post here
if they feel discussion is warranted and also post actual feature requests
and bug reports is probably best.

--
Chris

Please consider the environment before printing this e-mail.


On Sat, Sep 11, 2010 at 9:45 PM, brett lentz <bre...@gm...> wrote:

> What could be done to make the process easier?
>
> ---Brett.
>
>
>
> On Sat, Sep 11, 2010 at 7:08 PM, Chris Shaffer <chr...@gm...>
> wrote:
> > The disadvantage of simply filing bugs and feature requests, of course,
> is
> > that there is virtually no discussion of them, because they are not seen
> by
> > 90% of the people on this list.
> >
> > I often file the bug or feature request and also post here, but that's
> > double work.
> >
> > --
> > Chris
> >
> > Please consider the environment before printing this e-mail.
> >
> >
> > On Sat, Sep 11, 2010 at 11:27 AM, Erik Vos <eri...@xs...> wrote:
> >>
> >> All good suggestions, and all of these would make nice entries in the
> >> Feature Request or Bug Report lists. That would have the added benefit
> >> that
> >> any discussions can be saved there too.
> >>
> >> Some comments from my side; some aspects I will have to leave to Stefan.
> >>
> >> Just one general remark: some ideas sound simple, and in theory anything
> >> is
> >> possible, but we should keep in mind that there is always a price,
> however
> >> small. Additional complexity, slower speed, or just larger code. We
> should
> >> not make Rails so big that the word "bloated" starts coming to mind.
> >>
> >> Erik
> >>
> >> -----Original Message-----
> >> From: John David Galt [mailto:jd...@di...]
> >> Sent: Saturday 11 September 2010 04:32
> >> To: rai...@li...
> >> Subject: [Rails-devel] Rails 1.4 18EU playtest with commentary
> >>
> >> Comments on Rails 1.4, tested with a four player game of 18EU
>  2010-09-09
> >>
> >> General comments:
> >>
> >> *  In the "select game" dialog box, changing to a different game should
> >> not
> >> cause all players to be set back to "none" and the names blanked.
> >>
> >> [EV] Sure. That's a bug to me.
> >>
> >> *  The map should show "Y", where needed, on unbuilt city hexes.  This
> is
> >> a
> >> major annoyance during the start round, because it affects both the
> city's
> >> revenue and the possible shapes of the yellow tile, so not seeing it
> makes
> >> it hard to predict the values of minors.  (Yes, I know, I can find this
> >> out
> >> by mousing-over each one, but that is annoying.)
> >>
> >> [EV] I'm a bit surprised that you consider this an annoyance. For me,
> the
> >> hard and fast rule is that all minor start cities are either preprinted
> >> yellow or Y cities, and vice versa. But it is easy to create an extra
> >> blank
> >> Y city tile, so that's on my list.
> >>
> >> *  The map also ought to show the values of red areas.  (I would treat
> >> each
> >> one as a "tile" with a negative number that gets upgraded by phase
> >> changes.)
> >>
> >> [EV] Creating a separate red tile for each possible revenue value sounds
> >> like overkill to me. Another idea could be to overprint red tiles with
> the
> >> current revenue value. The problem is that such values will look similar
> >> to
> >> tile laying cost.
> >> Talking about "the map" - I would love it if we would have map images
> (as
> >> SVG files). Then we could show any info we would like.
> >>
> >> *  Entering a comment before the first action in the game should be
> >> allowed.
> >>
> >> *  Entering two comments in a row should append, not replace.
> >>
> >> [EV] I leave these two for Stefan.
> >>
> >> *  It would be nice if the Game Status window had a column showing each
> >> player's total income in the last round.  This would act as a reminder
> >> that
> >> the player who is falling furthest behind had better DO SOMETHING! (and
> >> conversely, that the player who is making the most money should probably
> >> not
> >> change the status quo, by buying lots of trains or starting new
> >> companies).
> >>
> >> [EV] Great suggestion. High on my list.
> >>
> >> *  It would be nice if the program could remember (or let you save in a
> >> config file) the locations of every window, so you don't have to move
> them
> >> manual every time you start a game (and often afterward too).  I always
> >> use
> >> these settings.
> >>   Stock market: upper left corner of screen
> >>   "Game Status" tabulation/stock round input: lower left corner of
> screen
> >>   Map/operating round input: upper right corner of screen (and don't
> allow
> >>       the height to self-adjust so it's taller than the screen height
> >> minus
> >>       the Windows menu bar -- it now does so at the start of every OR
> >> until
> >>       there are too few companies to cause it (in my case, 10
> companies).
> >>       The map also moves so it extends about an inch to the right of the
> >>       screen, every time.)
> >>   History/comment window: lower right corner
> >>
> >> [EV] I believe Stefan is already considering this one.
> >>
> >> All of the above apply to all games, except that I believe the 1830 and
> >> 1835
> >> maps do show you where the lettered tiles go.  Due credit: 18EU does
> show
> >> the two "B-V" hexes.
> >>
> >> Start round:
> >>
> >> *  It would be nice to have alternate starts available, such as any
> >>   combination of:
> >>   $400 each to start;
> >>   all starting prices reduced to $50;
> >>   bidding round order 1,2,3,4,4,3,2,1,1,2,3,4,4,3,2.
> >>
> >> [EV] "such as" - where do the possibilities end? However, your
> suggestions
> >> sound like a sensible subset of the infinite universe of possible
> >> alternatives.
> >>
> >> *  "Unlimited tiles" should not be an all-or-nothing setting: there
> should
> >> be a setting to make only #7, #8, and #9 unlimited (this is what the
> rules
> >> say to do in 18EU, 1826, and 1853v2, and probably many other games).
> >>
> >> [EV] I cannot find this in the 18EU rules. However, it's a common
> >> extension,
> >> and I agree that it could be a generic option.
> >>
> >> *  Bids (above the starting value) look the same as the prices of things
> >> you've already bought.  Please change this: it makes it nonobvious who
> >> already owns more companies than others.
> >>
> >> *  There should be some visual indication of which players can still bid
> >> on
> >> the current item.
> >>
> >> *  A player is correctly skipped when an item someone else selected for
> >> bidding would cost more than he has.  But if it's your turn to select an
> >> item and you have less than $100, "Bid" ought to be grayed out and
> isn't.
> >>
> >> [EV] Three sensible UI improvements for the start rounds.
> >>
> >> Operating rounds:
> >>
> >> *  The map should show the reserved hexes controlled by certain minors.
> >> (I don't expect them to be enforced yet, just shown.)
> >>
> >> [EV] Agree. I think there should be a generic configuration option to
> add
> >> any text to any tile.
> >>
> >> *  Please enforce the rule that minors can't lay green tiles.
> >>
> >> [EV] I'm pretty sure that this worked correctly until recently. Stefan,
> I
> >> think to have been working on the tile laying rules - can you please
> >> check?
> >>
> >> *  When no tile lay is legally possible, please skip the tile-lay step.
> >> (Which would mean that after the first couple of rounds, most minors'
> >> tile-
> >> lay step would be skipped, speeding up the game a lot.)
> >>
> >> [EV] This can only be done if the current disconnect between knowing
> about
> >> legal lays (in the UI only) and the round/step management (in the game
> >> engine) has been fixed. Be aware, though, that any additional action
> skips
> >> will make all previous saved files unloadable, insofar these contain
> >> pass/done actions that are now skipped. I'm very reluctant to do add or
> >> remove such steps, as that will (again) invalidate many of my saved
> files
> >> that I use for testing.
> >>
> >> *  When placing tile #581 (green upgrade) in Berlin and trying it both
> >> ways
> >> it will go, the tokens that are already there (#9 and KPEV, which I
> formed
> >> from #7) are shown, respectively, along the SE and NW edges, rather than
> >> the
> >> NE and SW which are the existing connections they must keep.  They move
> to
> >> the correct places once I make the tile lay final, but showing them
> wrong
> >> makes it harder to place the tile correctly.
> >>
> >> [EV] Will look at that. Don't hold your breath - token repositioning on
> >> upgrades is one of the most complex processes we now have.
> >>
> >> *  It would be nice if I were allowed to have the program compute runs
> >> before I decide what tile to lay.  Sometimes a company is so spread out
> it
> >> isn't obvious where its trains are going.  (Of course I can always work
> >> around this by skipping the tile lay step, then "undo".)
> >>
> >> [EV] That's again for Stefan, I think.
> >>
> >> *  When deciding whether to pay, split, or withhold, it would be nice if
> >> the screen showed how much money the company will have after each
> choice.
> >> This isn't always easy to work out in your head, especially if there are
> >> some shares paying dividends into the treasury.  This goes for all
> games.
> >>
> >> [EV] Where should the screen show that? Below each of these buttons?
> >>
> >> *  Please get rid of the pop-up "<company> owns no trains, so revenue is
> >> $0."  Instead, just silently skip the revenue-setting step.
> >>
> >> [EV] Agree.
> >>
> >> *  The column that now reports "Pay out", "Withhold", or "Split" for the
> >> last turn of each company ought to say "$0 income" (or maybe "No run" or
> >> "No train") when that is true, so it doesn't look like the owner chose
> to
> >> withhold.
> >>
> >> [EV] A sensible refinement.
> >>
> >> *  A company's train-buying step is correctly skipped if it has no room
> >> for
> >> another train, but it should also be skipped (that is, "Buy Train"
> should
> >> be grayed out) if the company has $0 and at least one train.  Similarly,
> >> if
> >> a company spends its last dollar on a train (including forced
> purchases),
> >> its train-buying step should immediately end.
> >> (I believe this goes for all games -- or does anyone on this list really
> >> think that any game exists in which a train "purchase" from another
> >> company
> >> for $0 is allowed?  But even if you do, it's explicitly banned in 18EU.)
> >>
> >> [EV] Right, but see my above remark on skipping existing actions.
> >>
> >> *  When it's impossible for the company to buy or sell any treasury
> >> shares,
> >> the TRADING TREASURY SHARES step should be skipped.  (I'm mostly
> thinking
> >> of the situation when all shares of the company are owned by players,
> but
> >> it also applies if the company has no shares in treasury and has too
> >> little
> >> cash to buy one from the bank pool, or there are 5 shares in the bank
> pool
> >> and the company has too little cash to buy one.)  Because of the change
> of
> >> focus, this is a major waste of time, especially in the late game when
> the
> >> only shares not owned by players are those of companies that were never
> >> started.
> >>
> >> [EV] Yes, that makes sense, but see above.
> >>
> >> *  Buying and selling treasury stock works correctly, except one minor
> >> detail: when I mouse-over the "treasury shares" column, the tooltip says
> >> "click to select for buying" (even though it would be selling).
> >>
> >> [EV] OK.
> >>
> >> Stock rounds:
> >>
> >> *  When floating a new company, if I buy until I have 60% and then merge
> >> in
> >> another minor company (to get more than 60% until the next stock round,
> >> which is specifically allowed in the rules) the exchange occurs but the
> >> "Done" button stays grayed out, making it impossible to continue the
> game
> >> without Undoing the exchange.
> >>
> >> [EV] Will look at that bug (if Stefan doesn't beat me)
> >>
> >> *  If I start a company (purchase the president's share) and then Undo
> the
> >> act of forming it, the status window continues to show the company with
> >> the
> >> share price I set.
> >>
> >> [EV] Guess we're missing a state variable here.
> >>
> >> *  When I buy shares from a company's treasury, the amount of money in
> >> that
> >> treasury is usually not updated right away.
> >>
> >> [EV] OK
> >>
> >> Ending:
> >>
> >> *  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
> >> just change the space on the Game Status window where the amount of
> money
> >> in the bank is normally shown to say "BROKEN", maybe in bright colors.
> >>
> >> [EV] The former is simple, the latter a bit less so, but I agree.
> >>
> >> *  The repeated pop-ups that "count down" to the winning player are even
> >> more annoying.
> >>
> >> [EV] Fully agree. Luckily I can plead innocence here...
> >>
> >>
> >>
> ----------------------------------------------------------------------------
> >> --
> >> 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] Rails 1.4 18EU playtest with commentary

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

What could be done to make the process easier?

---Brett.



On Sat, Sep 11, 2010 at 7:08 PM, Chris Shaffer <chr...@gm...> wrote:
> The disadvantage of simply filing bugs and feature requests, of course, is
> that there is virtually no discussion of them, because they are not seen by
> 90% of the people on this list.
>
> I often file the bug or feature request and also post here, but that's
> double work.
>
> --
> Chris
>
> Please consider the environment before printing this e-mail.
>
>
> On Sat, Sep 11, 2010 at 11:27 AM, Erik Vos <eri...@xs...> wrote:
>>
>> All good suggestions, and all of these would make nice entries in the
>> Feature Request or Bug Report lists. That would have the added benefit
>> that
>> any discussions can be saved there too.
>>
>> Some comments from my side; some aspects I will have to leave to Stefan.
>>
>> Just one general remark: some ideas sound simple, and in theory anything
>> is
>> possible, but we should keep in mind that there is always a price, however
>> small. Additional complexity, slower speed, or just larger code. We should
>> not make Rails so big that the word "bloated" starts coming to mind.
>>
>> Erik
>>
>> -----Original Message-----
>> From: John David Galt [mailto:jd...@di...]
>> Sent: Saturday 11 September 2010 04:32
>> To: rai...@li...
>> Subject: [Rails-devel] Rails 1.4 18EU playtest with commentary
>>
>> Comments on Rails 1.4, tested with a four player game of 18EU  2010-09-09
>>
>> General comments:
>>
>> *  In the "select game" dialog box, changing to a different game should
>> not
>> cause all players to be set back to "none" and the names blanked.
>>
>> [EV] Sure. That's a bug to me.
>>
>> *  The map should show "Y", where needed, on unbuilt city hexes.  This is
>> a
>> major annoyance during the start round, because it affects both the city's
>> revenue and the possible shapes of the yellow tile, so not seeing it makes
>> it hard to predict the values of minors.  (Yes, I know, I can find this
>> out
>> by mousing-over each one, but that is annoying.)
>>
>> [EV] I'm a bit surprised that you consider this an annoyance. For me, the
>> hard and fast rule is that all minor start cities are either preprinted
>> yellow or Y cities, and vice versa. But it is easy to create an extra
>> blank
>> Y city tile, so that's on my list.
>>
>> *  The map also ought to show the values of red areas.  (I would treat
>> each
>> one as a "tile" with a negative number that gets upgraded by phase
>> changes.)
>>
>> [EV] Creating a separate red tile for each possible revenue value sounds
>> like overkill to me. Another idea could be to overprint red tiles with the
>> current revenue value. The problem is that such values will look similar
>> to
>> tile laying cost.
>> Talking about "the map" - I would love it if we would have map images (as
>> SVG files). Then we could show any info we would like.
>>
>> *  Entering a comment before the first action in the game should be
>> allowed.
>>
>> *  Entering two comments in a row should append, not replace.
>>
>> [EV] I leave these two for Stefan.
>>
>> *  It would be nice if the Game Status window had a column showing each
>> player's total income in the last round.  This would act as a reminder
>> that
>> the player who is falling furthest behind had better DO SOMETHING! (and
>> conversely, that the player who is making the most money should probably
>> not
>> change the status quo, by buying lots of trains or starting new
>> companies).
>>
>> [EV] Great suggestion. High on my list.
>>
>> *  It would be nice if the program could remember (or let you save in a
>> config file) the locations of every window, so you don't have to move them
>> manual every time you start a game (and often afterward too).  I always
>> use
>> these settings.
>>   Stock market: upper left corner of screen
>>   "Game Status" tabulation/stock round input: lower left corner of screen
>>   Map/operating round input: upper right corner of screen (and don't allow
>>       the height to self-adjust so it's taller than the screen height
>> minus
>>       the Windows menu bar -- it now does so at the start of every OR
>> until
>>       there are too few companies to cause it (in my case, 10 companies).
>>       The map also moves so it extends about an inch to the right of the
>>       screen, every time.)
>>   History/comment window: lower right corner
>>
>> [EV] I believe Stefan is already considering this one.
>>
>> All of the above apply to all games, except that I believe the 1830 and
>> 1835
>> maps do show you where the lettered tiles go.  Due credit: 18EU does show
>> the two "B-V" hexes.
>>
>> Start round:
>>
>> *  It would be nice to have alternate starts available, such as any
>>   combination of:
>>   $400 each to start;
>>   all starting prices reduced to $50;
>>   bidding round order 1,2,3,4,4,3,2,1,1,2,3,4,4,3,2.
>>
>> [EV] "such as" - where do the possibilities end? However, your suggestions
>> sound like a sensible subset of the infinite universe of possible
>> alternatives.
>>
>> *  "Unlimited tiles" should not be an all-or-nothing setting: there should
>> be a setting to make only #7, #8, and #9 unlimited (this is what the rules
>> say to do in 18EU, 1826, and 1853v2, and probably many other games).
>>
>> [EV] I cannot find this in the 18EU rules. However, it's a common
>> extension,
>> and I agree that it could be a generic option.
>>
>> *  Bids (above the starting value) look the same as the prices of things
>> you've already bought.  Please change this: it makes it nonobvious who
>> already owns more companies than others.
>>
>> *  There should be some visual indication of which players can still bid
>> on
>> the current item.
>>
>> *  A player is correctly skipped when an item someone else selected for
>> bidding would cost more than he has.  But if it's your turn to select an
>> item and you have less than $100, "Bid" ought to be grayed out and isn't.
>>
>> [EV] Three sensible UI improvements for the start rounds.
>>
>> Operating rounds:
>>
>> *  The map should show the reserved hexes controlled by certain minors.
>> (I don't expect them to be enforced yet, just shown.)
>>
>> [EV] Agree. I think there should be a generic configuration option to add
>> any text to any tile.
>>
>> *  Please enforce the rule that minors can't lay green tiles.
>>
>> [EV] I'm pretty sure that this worked correctly until recently. Stefan, I
>> think to have been working on the tile laying rules - can you please
>> check?
>>
>> *  When no tile lay is legally possible, please skip the tile-lay step.
>> (Which would mean that after the first couple of rounds, most minors'
>> tile-
>> lay step would be skipped, speeding up the game a lot.)
>>
>> [EV] This can only be done if the current disconnect between knowing about
>> legal lays (in the UI only) and the round/step management (in the game
>> engine) has been fixed. Be aware, though, that any additional action skips
>> will make all previous saved files unloadable, insofar these contain
>> pass/done actions that are now skipped. I'm very reluctant to do add or
>> remove such steps, as that will (again) invalidate many of my saved files
>> that I use for testing.
>>
>> *  When placing tile #581 (green upgrade) in Berlin and trying it both
>> ways
>> it will go, the tokens that are already there (#9 and KPEV, which I formed
>> from #7) are shown, respectively, along the SE and NW edges, rather than
>> the
>> NE and SW which are the existing connections they must keep.  They move to
>> the correct places once I make the tile lay final, but showing them wrong
>> makes it harder to place the tile correctly.
>>
>> [EV] Will look at that. Don't hold your breath - token repositioning on
>> upgrades is one of the most complex processes we now have.
>>
>> *  It would be nice if I were allowed to have the program compute runs
>> before I decide what tile to lay.  Sometimes a company is so spread out it
>> isn't obvious where its trains are going.  (Of course I can always work
>> around this by skipping the tile lay step, then "undo".)
>>
>> [EV] That's again for Stefan, I think.
>>
>> *  When deciding whether to pay, split, or withhold, it would be nice if
>> the screen showed how much money the company will have after each choice.
>> This isn't always easy to work out in your head, especially if there are
>> some shares paying dividends into the treasury.  This goes for all games.
>>
>> [EV] Where should the screen show that? Below each of these buttons?
>>
>> *  Please get rid of the pop-up "<company> owns no trains, so revenue is
>> $0."  Instead, just silently skip the revenue-setting step.
>>
>> [EV] Agree.
>>
>> *  The column that now reports "Pay out", "Withhold", or "Split" for the
>> last turn of each company ought to say "$0 income" (or maybe "No run" or
>> "No train") when that is true, so it doesn't look like the owner chose to
>> withhold.
>>
>> [EV] A sensible refinement.
>>
>> *  A company's train-buying step is correctly skipped if it has no room
>> for
>> another train, but it should also be skipped (that is, "Buy Train" should
>> be grayed out) if the company has $0 and at least one train.  Similarly,
>> if
>> a company spends its last dollar on a train (including forced purchases),
>> its train-buying step should immediately end.
>> (I believe this goes for all games -- or does anyone on this list really
>> think that any game exists in which a train "purchase" from another
>> company
>> for $0 is allowed?  But even if you do, it's explicitly banned in 18EU.)
>>
>> [EV] Right, but see my above remark on skipping existing actions.
>>
>> *  When it's impossible for the company to buy or sell any treasury
>> shares,
>> the TRADING TREASURY SHARES step should be skipped.  (I'm mostly thinking
>> of the situation when all shares of the company are owned by players, but
>> it also applies if the company has no shares in treasury and has too
>> little
>> cash to buy one from the bank pool, or there are 5 shares in the bank pool
>> and the company has too little cash to buy one.)  Because of the change of
>> focus, this is a major waste of time, especially in the late game when the
>> only shares not owned by players are those of companies that were never
>> started.
>>
>> [EV] Yes, that makes sense, but see above.
>>
>> *  Buying and selling treasury stock works correctly, except one minor
>> detail: when I mouse-over the "treasury shares" column, the tooltip says
>> "click to select for buying" (even though it would be selling).
>>
>> [EV] OK.
>>
>> Stock rounds:
>>
>> *  When floating a new company, if I buy until I have 60% and then merge
>> in
>> another minor company (to get more than 60% until the next stock round,
>> which is specifically allowed in the rules) the exchange occurs but the
>> "Done" button stays grayed out, making it impossible to continue the game
>> without Undoing the exchange.
>>
>> [EV] Will look at that bug (if Stefan doesn't beat me)
>>
>> *  If I start a company (purchase the president's share) and then Undo the
>> act of forming it, the status window continues to show the company with
>> the
>> share price I set.
>>
>> [EV] Guess we're missing a state variable here.
>>
>> *  When I buy shares from a company's treasury, the amount of money in
>> that
>> treasury is usually not updated right away.
>>
>> [EV] OK
>>
>> Ending:
>>
>> *  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
>> just change the space on the Game Status window where the amount of money
>> in the bank is normally shown to say "BROKEN", maybe in bright colors.
>>
>> [EV] The former is simple, the latter a bit less so, but I agree.
>>
>> *  The repeated pop-ups that "count down" to the winning player are even
>> more annoying.
>>
>> [EV] Fully agree. Luckily I can plead innocence here...
>>
>>
>> ----------------------------------------------------------------------------
>> --
>> 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] Rails 1.4 18EU playtest with commentary

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

The disadvantage of simply filing bugs and feature requests, of course, is
that there is virtually no discussion of them, because they are not seen by
90% of the people on this list.

I often file the bug or feature request and also post here, but that's
double work.

--
Chris

Please consider the environment before printing this e-mail.


On Sat, Sep 11, 2010 at 11:27 AM, Erik Vos <eri...@xs...> wrote:

> All good suggestions, and all of these would make nice entries in the
> Feature Request or Bug Report lists. That would have the added benefit that
> any discussions can be saved there too.
>
> Some comments from my side; some aspects I will have to leave to Stefan.
>
> Just one general remark: some ideas sound simple, and in theory anything is
> possible, but we should keep in mind that there is always a price, however
> small. Additional complexity, slower speed, or just larger code. We should
> not make Rails so big that the word "bloated" starts coming to mind.
>
> Erik
>
> -----Original Message-----
> From: John David Galt [mailto:jd...@di...]
> Sent: Saturday 11 September 2010 04:32
> To: rai...@li...
> Subject: [Rails-devel] Rails 1.4 18EU playtest with commentary
>
> Comments on Rails 1.4, tested with a four player game of 18EU  2010-09-09
>
> General comments:
>
> *  In the "select game" dialog box, changing to a different game should not
> cause all players to be set back to "none" and the names blanked.
>
> [EV] Sure. That's a bug to me.
>
> *  The map should show "Y", where needed, on unbuilt city hexes.  This is a
> major annoyance during the start round, because it affects both the city's
> revenue and the possible shapes of the yellow tile, so not seeing it makes
> it hard to predict the values of minors.  (Yes, I know, I can find this out
> by mousing-over each one, but that is annoying.)
>
> [EV] I'm a bit surprised that you consider this an annoyance. For me, the
> hard and fast rule is that all minor start cities are either preprinted
> yellow or Y cities, and vice versa. But it is easy to create an extra blank
> Y city tile, so that's on my list.
>
> *  The map also ought to show the values of red areas.  (I would treat each
> one as a "tile" with a negative number that gets upgraded by phase
> changes.)
>
> [EV] Creating a separate red tile for each possible revenue value sounds
> like overkill to me. Another idea could be to overprint red tiles with the
> current revenue value. The problem is that such values will look similar to
> tile laying cost.
> Talking about "the map" - I would love it if we would have map images (as
> SVG files). Then we could show any info we would like.
>
> *  Entering a comment before the first action in the game should be
> allowed.
>
> *  Entering two comments in a row should append, not replace.
>
> [EV] I leave these two for Stefan.
>
> *  It would be nice if the Game Status window had a column showing each
> player's total income in the last round.  This would act as a reminder that
> the player who is falling furthest behind had better DO SOMETHING! (and
> conversely, that the player who is making the most money should probably
> not
> change the status quo, by buying lots of trains or starting new companies).
>
> [EV] Great suggestion. High on my list.
>
> *  It would be nice if the program could remember (or let you save in a
> config file) the locations of every window, so you don't have to move them
> manual every time you start a game (and often afterward too).  I always use
> these settings.
>   Stock market: upper left corner of screen
>   "Game Status" tabulation/stock round input: lower left corner of screen
>   Map/operating round input: upper right corner of screen (and don't allow
>       the height to self-adjust so it's taller than the screen height minus
>       the Windows menu bar -- it now does so at the start of every OR until
>       there are too few companies to cause it (in my case, 10 companies).
>       The map also moves so it extends about an inch to the right of the
>       screen, every time.)
>   History/comment window: lower right corner
>
> [EV] I believe Stefan is already considering this one.
>
> All of the above apply to all games, except that I believe the 1830 and
> 1835
> maps do show you where the lettered tiles go.  Due credit: 18EU does show
> the two "B-V" hexes.
>
> Start round:
>
> *  It would be nice to have alternate starts available, such as any
>   combination of:
>   $400 each to start;
>   all starting prices reduced to $50;
>   bidding round order 1,2,3,4,4,3,2,1,1,2,3,4,4,3,2.
>
> [EV] "such as" - where do the possibilities end? However, your suggestions
> sound like a sensible subset of the infinite universe of possible
> alternatives.
>
> *  "Unlimited tiles" should not be an all-or-nothing setting: there should
> be a setting to make only #7, #8, and #9 unlimited (this is what the rules
> say to do in 18EU, 1826, and 1853v2, and probably many other games).
>
> [EV] I cannot find this in the 18EU rules. However, it's a common
> extension,
> and I agree that it could be a generic option.
>
> *  Bids (above the starting value) look the same as the prices of things
> you've already bought.  Please change this: it makes it nonobvious who
> already owns more companies than others.
>
> *  There should be some visual indication of which players can still bid on
> the current item.
>
> *  A player is correctly skipped when an item someone else selected for
> bidding would cost more than he has.  But if it's your turn to select an
> item and you have less than $100, "Bid" ought to be grayed out and isn't.
>
> [EV] Three sensible UI improvements for the start rounds.
>
> Operating rounds:
>
> *  The map should show the reserved hexes controlled by certain minors.
> (I don't expect them to be enforced yet, just shown.)
>
> [EV] Agree. I think there should be a generic configuration option to add
> any text to any tile.
>
> *  Please enforce the rule that minors can't lay green tiles.
>
> [EV] I'm pretty sure that this worked correctly until recently. Stefan, I
> think to have been working on the tile laying rules - can you please check?
>
> *  When no tile lay is legally possible, please skip the tile-lay step.
> (Which would mean that after the first couple of rounds, most minors' tile-
> lay step would be skipped, speeding up the game a lot.)
>
> [EV] This can only be done if the current disconnect between knowing about
> legal lays (in the UI only) and the round/step management (in the game
> engine) has been fixed. Be aware, though, that any additional action skips
> will make all previous saved files unloadable, insofar these contain
> pass/done actions that are now skipped. I'm very reluctant to do add or
> remove such steps, as that will (again) invalidate many of my saved files
> that I use for testing.
>
> *  When placing tile #581 (green upgrade) in Berlin and trying it both ways
> it will go, the tokens that are already there (#9 and KPEV, which I formed
> from #7) are shown, respectively, along the SE and NW edges, rather than
> the
> NE and SW which are the existing connections they must keep.  They move to
> the correct places once I make the tile lay final, but showing them wrong
> makes it harder to place the tile correctly.
>
> [EV] Will look at that. Don't hold your breath - token repositioning on
> upgrades is one of the most complex processes we now have.
>
> *  It would be nice if I were allowed to have the program compute runs
> before I decide what tile to lay.  Sometimes a company is so spread out it
> isn't obvious where its trains are going.  (Of course I can always work
> around this by skipping the tile lay step, then "undo".)
>
> [EV] That's again for Stefan, I think.
>
> *  When deciding whether to pay, split, or withhold, it would be nice if
> the screen showed how much money the company will have after each choice.
> This isn't always easy to work out in your head, especially if there are
> some shares paying dividends into the treasury.  This goes for all games.
>
> [EV] Where should the screen show that? Below each of these buttons?
>
> *  Please get rid of the pop-up "<company> owns no trains, so revenue is
> $0."  Instead, just silently skip the revenue-setting step.
>
> [EV] Agree.
>
> *  The column that now reports "Pay out", "Withhold", or "Split" for the
> last turn of each company ought to say "$0 income" (or maybe "No run" or
> "No train") when that is true, so it doesn't look like the owner chose to
> withhold.
>
> [EV] A sensible refinement.
>
> *  A company's train-buying step is correctly skipped if it has no room for
> another train, but it should also be skipped (that is, "Buy Train" should
> be grayed out) if the company has $0 and at least one train.  Similarly, if
> a company spends its last dollar on a train (including forced purchases),
> its train-buying step should immediately end.
> (I believe this goes for all games -- or does anyone on this list really
> think that any game exists in which a train "purchase" from another company
> for $0 is allowed?  But even if you do, it's explicitly banned in 18EU.)
>
> [EV] Right, but see my above remark on skipping existing actions.
>
> *  When it's impossible for the company to buy or sell any treasury shares,
> the TRADING TREASURY SHARES step should be skipped.  (I'm mostly thinking
> of the situation when all shares of the company are owned by players, but
> it also applies if the company has no shares in treasury and has too little
> cash to buy one from the bank pool, or there are 5 shares in the bank pool
> and the company has too little cash to buy one.)  Because of the change of
> focus, this is a major waste of time, especially in the late game when the
> only shares not owned by players are those of companies that were never
> started.
>
> [EV] Yes, that makes sense, but see above.
>
> *  Buying and selling treasury stock works correctly, except one minor
> detail: when I mouse-over the "treasury shares" column, the tooltip says
> "click to select for buying" (even though it would be selling).
>
> [EV] OK.
>
> Stock rounds:
>
> *  When floating a new company, if I buy until I have 60% and then merge in
> another minor company (to get more than 60% until the next stock round,
> which is specifically allowed in the rules) the exchange occurs but the
> "Done" button stays grayed out, making it impossible to continue the game
> without Undoing the exchange.
>
> [EV] Will look at that bug (if Stefan doesn't beat me)
>
> *  If I start a company (purchase the president's share) and then Undo the
> act of forming it, the status window continues to show the company with the
> share price I set.
>
> [EV] Guess we're missing a state variable here.
>
> *  When I buy shares from a company's treasury, the amount of money in that
> treasury is usually not updated right away.
>
> [EV] OK
>
> Ending:
>
> *  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
> just change the space on the Game Status window where the amount of money
> in the bank is normally shown to say "BROKEN", maybe in bright colors.
>
> [EV] The former is simple, the latter a bit less so, but I agree.
>
> *  The repeated pop-ups that "count down" to the winning player are even
> more annoying.
>
> [EV] Fully agree. Luckily I can plead innocence here...
>
>
> ----------------------------------------------------------------------------
> --
> 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] Rails 1.4 18EU playtest with commentary

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

All good suggestions, and all of these would make nice entries in the
Feature Request or Bug Report lists. That would have the added benefit that
any discussions can be saved there too.

Some comments from my side; some aspects I will have to leave to Stefan.

Just one general remark: some ideas sound simple, and in theory anything is
possible, but we should keep in mind that there is always a price, however
small. Additional complexity, slower speed, or just larger code. We should
not make Rails so big that the word "bloated" starts coming to mind.

Erik

-----Original Message-----
From: John David Galt [mailto:jd...@di...] 
Sent: Saturday 11 September 2010 04:32
To: rai...@li...
Subject: [Rails-devel] Rails 1.4 18EU playtest with commentary

Comments on Rails 1.4, tested with a four player game of 18EU  2010-09-09

General comments:

*  In the "select game" dialog box, changing to a different game should not
cause all players to be set back to "none" and the names blanked.

[EV] Sure. That's a bug to me.

*  The map should show "Y", where needed, on unbuilt city hexes.  This is a
major annoyance during the start round, because it affects both the city's
revenue and the possible shapes of the yellow tile, so not seeing it makes
it hard to predict the values of minors.  (Yes, I know, I can find this out
by mousing-over each one, but that is annoying.)

[EV] I'm a bit surprised that you consider this an annoyance. For me, the
hard and fast rule is that all minor start cities are either preprinted
yellow or Y cities, and vice versa. But it is easy to create an extra blank
Y city tile, so that's on my list.

*  The map also ought to show the values of red areas.  (I would treat each
one as a "tile" with a negative number that gets upgraded by phase changes.)

[EV] Creating a separate red tile for each possible revenue value sounds
like overkill to me. Another idea could be to overprint red tiles with the
current revenue value. The problem is that such values will look similar to
tile laying cost.
Talking about "the map" - I would love it if we would have map images (as
SVG files). Then we could show any info we would like.

*  Entering a comment before the first action in the game should be allowed.

*  Entering two comments in a row should append, not replace.

[EV] I leave these two for Stefan.

*  It would be nice if the Game Status window had a column showing each
player's total income in the last round.  This would act as a reminder that
the player who is falling furthest behind had better DO SOMETHING! (and
conversely, that the player who is making the most money should probably not
change the status quo, by buying lots of trains or starting new companies).

[EV] Great suggestion. High on my list.

*  It would be nice if the program could remember (or let you save in a
config file) the locations of every window, so you don't have to move them
manual every time you start a game (and often afterward too).  I always use
these settings.
   Stock market: upper left corner of screen
   "Game Status" tabulation/stock round input: lower left corner of screen
   Map/operating round input: upper right corner of screen (and don't allow
       the height to self-adjust so it's taller than the screen height minus
       the Windows menu bar -- it now does so at the start of every OR until
       there are too few companies to cause it (in my case, 10 companies).
       The map also moves so it extends about an inch to the right of the
       screen, every time.)
   History/comment window: lower right corner

[EV] I believe Stefan is already considering this one.

All of the above apply to all games, except that I believe the 1830 and 1835
maps do show you where the lettered tiles go.  Due credit: 18EU does show
the two "B-V" hexes.

Start round:

*  It would be nice to have alternate starts available, such as any
   combination of:
   $400 each to start;
   all starting prices reduced to $50;
   bidding round order 1,2,3,4,4,3,2,1,1,2,3,4,4,3,2.

[EV] "such as" - where do the possibilities end? However, your suggestions
sound like a sensible subset of the infinite universe of possible
alternatives.

*  "Unlimited tiles" should not be an all-or-nothing setting: there should
be a setting to make only #7, #8, and #9 unlimited (this is what the rules
say to do in 18EU, 1826, and 1853v2, and probably many other games).

[EV] I cannot find this in the 18EU rules. However, it's a common extension,
and I agree that it could be a generic option.

*  Bids (above the starting value) look the same as the prices of things
you've already bought.  Please change this: it makes it nonobvious who
already owns more companies than others.

*  There should be some visual indication of which players can still bid on
the current item.

*  A player is correctly skipped when an item someone else selected for
bidding would cost more than he has.  But if it's your turn to select an
item and you have less than $100, "Bid" ought to be grayed out and isn't.

[EV] Three sensible UI improvements for the start rounds.

Operating rounds:

*  The map should show the reserved hexes controlled by certain minors.
(I don't expect them to be enforced yet, just shown.)

[EV] Agree. I think there should be a generic configuration option to add
any text to any tile.

*  Please enforce the rule that minors can't lay green tiles.

[EV] I'm pretty sure that this worked correctly until recently. Stefan, I
think to have been working on the tile laying rules - can you please check?

*  When no tile lay is legally possible, please skip the tile-lay step.
(Which would mean that after the first couple of rounds, most minors' tile-
lay step would be skipped, speeding up the game a lot.)

[EV] This can only be done if the current disconnect between knowing about
legal lays (in the UI only) and the round/step management (in the game
engine) has been fixed. Be aware, though, that any additional action skips
will make all previous saved files unloadable, insofar these contain
pass/done actions that are now skipped. I'm very reluctant to do add or
remove such steps, as that will (again) invalidate many of my saved files
that I use for testing.

*  When placing tile #581 (green upgrade) in Berlin and trying it both ways
it will go, the tokens that are already there (#9 and KPEV, which I formed
from #7) are shown, respectively, along the SE and NW edges, rather than the
NE and SW which are the existing connections they must keep.  They move to
the correct places once I make the tile lay final, but showing them wrong
makes it harder to place the tile correctly.

[EV] Will look at that. Don't hold your breath - token repositioning on
upgrades is one of the most complex processes we now have.

*  It would be nice if I were allowed to have the program compute runs
before I decide what tile to lay.  Sometimes a company is so spread out it
isn't obvious where its trains are going.  (Of course I can always work
around this by skipping the tile lay step, then "undo".)

[EV] That's again for Stefan, I think.

*  When deciding whether to pay, split, or withhold, it would be nice if
the screen showed how much money the company will have after each choice.
This isn't always easy to work out in your head, especially if there are
some shares paying dividends into the treasury.  This goes for all games.

[EV] Where should the screen show that? Below each of these buttons? 

*  Please get rid of the pop-up "<company> owns no trains, so revenue is
$0."  Instead, just silently skip the revenue-setting step.

[EV] Agree. 

*  The column that now reports "Pay out", "Withhold", or "Split" for the
last turn of each company ought to say "$0 income" (or maybe "No run" or
"No train") when that is true, so it doesn't look like the owner chose to
withhold.

[EV] A sensible refinement.

*  A company's train-buying step is correctly skipped if it has no room for
another train, but it should also be skipped (that is, "Buy Train" should
be grayed out) if the company has $0 and at least one train.  Similarly, if
a company spends its last dollar on a train (including forced purchases),
its train-buying step should immediately end.
(I believe this goes for all games -- or does anyone on this list really
think that any game exists in which a train "purchase" from another company
for $0 is allowed?  But even if you do, it's explicitly banned in 18EU.)

[EV] Right, but see my above remark on skipping existing actions.

*  When it's impossible for the company to buy or sell any treasury shares,
the TRADING TREASURY SHARES step should be skipped.  (I'm mostly thinking
of the situation when all shares of the company are owned by players, but
it also applies if the company has no shares in treasury and has too little
cash to buy one from the bank pool, or there are 5 shares in the bank pool
and the company has too little cash to buy one.)  Because of the change of
focus, this is a major waste of time, especially in the late game when the
only shares not owned by players are those of companies that were never
started.

[EV] Yes, that makes sense, but see above.

*  Buying and selling treasury stock works correctly, except one minor
detail: when I mouse-over the "treasury shares" column, the tooltip says
"click to select for buying" (even though it would be selling).

[EV] OK.

Stock rounds:

*  When floating a new company, if I buy until I have 60% and then merge in
another minor company (to get more than 60% until the next stock round,
which is specifically allowed in the rules) the exchange occurs but the
"Done" button stays grayed out, making it impossible to continue the game
without Undoing the exchange.

[EV] Will look at that bug (if Stefan doesn't beat me)

*  If I start a company (purchase the president's share) and then Undo the
act of forming it, the status window continues to show the company with the
share price I set.

[EV] Guess we're missing a state variable here.

*  When I buy shares from a company's treasury, the amount of money in that
treasury is usually not updated right away.

[EV] OK

Ending:

*  Please get rid of BOTH pop-ups saying the bank has broken.  Instead,
just change the space on the Game Status window where the amount of money
in the bank is normally shown to say "BROKEN", maybe in bright colors.

[EV] The former is simple, the latter a bit less so, but I agree.

*  The repeated pop-ups that "count down" to the winning player are even
more annoying.

[EV] Fully agree. Luckily I can plead innocence here...

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