rails-devel

[Rails-devel] Price tokens change order when moving up.

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

(Switching to the proper group)
This has been fixed now - in Subversion!
 
Erik.


  _____  

From: 18...@ya... [mailto:18...@ya...] On Behalf Of John
A. Tamplin
Sent: Friday 02 July 2010 00:17
To: 18...@ya...
Subject: Re: [18xx] par value marker movement


  

On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
<mailto:erik.vos%40xs4all.nl> > wrote:

> At the end of the SR, the companies are scanned for being sold out in the
> order in which they appear in the Game Status window. Any upward token
> moves
> are then executed in that order and follow the normal move rules. So I
> suspect that the token order gets reversed only if a 'lower' company token
> is on top of a 'higher' one. Or it could be the reverse...:-) Indeed we
> need
> a saved file to prove that.
> In any case, I would encourage to file it as a bug, so it will get proper
> attention at some point.

The tokens are supposed to be processed in market order, which winds up
preserving the same stacking.

-- 
John A. Tamplin

[Non-text portions of this message have been removed]



__._,_.___
Reply  <mailto:ja...@ja...?subject=Re: [18xx] par value marker movement> to
sender | Reply  <mailto:18...@ya...?subject=Re: [18xx] par value
marker movement> to group | Reply
<http://groups.yahoo.com/group/18xx/post;_ylc=X3oDMTJwanVscDFmBF9TAzk3MzU5Nz
E0BGdycElkAzExOTgyOQRncnBzcElkAzE3MDUwNTI4OTYEbXNnSWQDMjg5NjAEc2VjA2Z0cgRzbG
sDcnBseQRzdGltZQMxMjc4MDIyNjgy?act=reply&messageNum=28960> via web post |
Start
<http://groups.yahoo.com/group/18xx/post;_ylc=X3oDMTJkaWVwZWdxBF9TAzk3MzU5Nz
E0BGdycElkAzExOTgyOQRncnBzcElkAzE3MDUwNTI4OTYEc2VjA2Z0cgRzbGsDbnRwYwRzdGltZQ
MxMjc4MDIyNjgy> a New Topic 
Messages
<http://groups.yahoo.com/group/18xx/message/28950;_ylc=X3oDMTM1NDQ1NzFvBF9TA
zk3MzU5NzE0BGdycElkAzExOTgyOQRncnBzcElkAzE3MDUwNTI4OTYEbXNnSWQDMjg5NjAEc2VjA
2Z0cgRzbGsDdnRwYwRzdGltZQMxMjc4MDIyNjgyBHRwY0lkAzI4OTUw> in this topic (7) 
Recent Activity: 

*	New
<http://groups.yahoo.com/group/18xx/members;_ylc=X3oDMTJlcGw4azRpBF9TAzk3MzU
5NzE0BGdycElkAzExOTgyOQRncnBzcElkAzE3MDUwNTI4OTYEc2VjA3Z0bARzbGsDdm1icnMEc3R
pbWUDMTI3ODAyMjY4Mg--?o=6> Members 6 

Visit
<http://groups.yahoo.com/group/18xx;_ylc=X3oDMTJkNGVzYWNjBF9TAzk3MzU5NzE0BGd
ycElkAzExOTgyOQRncnBzcElkAzE3MDUwNTI4OTYEc2VjA3Z0bARzbGsDdmdocARzdGltZQMxMjc
4MDIyNjgy> Your Group 
This is a message from the 18xx mailing list. 
MARKETPLACE

Stay
<http://us.ard.yahoo.com/SIG=15om3tl37/M=493064.13983314.14041046.13298430/D
=groups/S=1705052896:MKP1/Y=YAHOO/EXP=1278029882/L=83903402-855e-11df-ae5f-e
792b59ce9ac/B=5w4yF0PDhEA-/J=1278022682563805/K=QSG5YhfRCMiBCFxuFAxm4g/A=606
0255/R=0/SIG=1194m4keh/*http://us.toolbar.yahoo.com/?.cpdl=grpj> on top of
your group activity without leaving the page you're on - Get the Yahoo!
Toolbar now.

 
  _____  


Get
<http://us.ard.yahoo.com/SIG=15o5ejigq/M=493064.13814537.14041040.10835568/D
=groups/S=1705052896:MKP1/Y=YAHOO/EXP=1278029882/L=83903402-855e-11df-ae5f-e
792b59ce9ac/B=6A4yF0PDhEA-/J=1278022682563805/K=QSG5YhfRCMiBCFxuFAxm4g/A=607
8812/R=0/SIG=114ae4ln1/*http://dogandcatanswers.yahoo.com/> great advice
about dogs and cats. Visit the Dog & Cat Answers Center.

 
  _____  


Hobbies
<http://us.ard.yahoo.com/SIG=15o76ht6q/M=493064.14012770.13963757.13298430/D
=groups/S=1705052896:MKP1/Y=YAHOO/EXP=1278029882/L=83903402-855e-11df-ae5f-e
792b59ce9ac/B=6Q4yF0PDhEA-/J=1278022682563805/K=QSG5YhfRCMiBCFxuFAxm4g/A=601
5306/R=0/SIG=11vlkvigg/*http://advision.webevents.yahoo.com/hobbiesandactivi
tieszone/> & Activities Zone: Find others who share your passions! Explore
new interests.

 
 
<http://groups.yahoo.com/;_ylc=X3oDMTJjYmswOWtjBF9TAzk3MzU5NzE0BGdycElkAzExO
TgyOQRncnBzcElkAzE3MDUwNTI4OTYEc2VjA2Z0cgRzbGsDZ2ZwBHN0aW1lAzEyNzgwMjI2ODI->
Yahoo! Groups 
Switch to: Text-Only <mailto:18x...@ya...?subject=Change
Delivery Format: Traditional> , Daily
<mailto:18x...@ya...?subject=Email Delivery: Digest> Digest .
Unsubscribe <mailto:18x...@ya...?subject=Unsubscribe>  .
Terms of Use <http://docs.yahoo.com/info/terms/> 
.
 
<http://geo.yahoo.com/serv?s=97359714/grpId=119829/grpspId=1705052896/msgId=
28960/stime=1278022682/nc1=6083913/nc2=3848640/nc3=5733768> 

__,_._,___

Re: [Rails-devel] Price tokens change order when moving up.

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

Stefan,

I'm afraid this does not sound like a very good idea to me.

AFAIK, a comparator requires *every* instance to be comparable. And
non-started companies without a price aren't really well comparable for
defining operating order purposes.

Defining operating order (there are now two methods doing that, for
different purposes and with different output) does not only require sorting,
but also prior selection of the objects eligible for ordering. 

Yes, I realize that my new getCompaniesInRunningOrder() method does order
*all* companies (contrary to everything I have said above), but (thinking
about it) that's probably rather a bug than a feature. For now it works, but
I don't consider it durable. In all likelihood the current logic will need
major changes when adding games like 1837 and 1844 with their many different
company types. And for such purposes I'd rather subclass GameManager (which
must be done anyway in most new games) than PublicCompany.*

Another consideration: recent developments increasingly force me to move
logic out of the 'static' objects (companies, trains, tiles etc.) and into
the 'dynamic' Manager/Round objects. Your proposal goes somewhat in the
opposite direction.

Erik.

* That's a separate subject. Company class hierarchies have been discussed
before in this forum. That might be a good idea if Java would support
multiple inheritance, but it doesn't. There are too many company types with
different mixtures of special features, and I have given up of thinking
about catching these in hierarchies.

-----Original Message-----
From: Stefan Frey (web.de) [mailto:ste...@we...] 
Sent: Sunday 04 July 2010 23:46
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] Price tokens change order when moving up.

Erik:
do you mind if I move the definition of running order into the PublicCompany

class and define a Comparator?

I can still keep the new method in the GameManager, but the change would
later 
simplify the migration to the new sequence model.

Stefan

On Sunday 04 July 2010 22:57:26 Erik Vos wrote:
> (Switching to the proper group)
> This has been fixed now - in Subversion!
>
> Erik.
>
>
>   _____
>
> From: 18...@ya... [mailto:18...@ya...] On Behalf Of John
> A. Tamplin
> Sent: Friday 02 July 2010 00:17
> To: 18...@ya...
> Subject: Re: [18xx] par value marker movement
>
>
>
>
> On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
>
> <mailto:erik.vos%40xs4all.nl> > wrote:
> > At the end of the SR, the companies are scanned for being sold out in
the
> > order in which they appear in the Game Status window. Any upward token
> > moves
> > are then executed in that order and follow the normal move rules. So I
> > suspect that the token order gets reversed only if a 'lower' company
> > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > Indeed we need
> > a saved file to prove that.
> > In any case, I would encourage to file it as a bug, so it will get
proper
> > attention at some point.
>
> The tokens are supposed to be processed in market order, which winds up
> preserving the same stacking.



----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Price tokens change order when moving up.

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

Erik,
seems to be a day of disagreements ;-)
But this makes discussion interesting and fruitful.
For the time being it is not mission-critical, where the sorting is done.
Mainly I was not happy about more things moved into those classes, which I 
would prefer to be smaller (more details below).
Stefan

On a general perspective:

From the perspective of a developer coming late to the project the GameManager 
and Round classes seems overloaded or even bloated already.
And it is much easier to guess that the operating order of public companies is 
defined by the PublicCompany class (and as it defines an ordering most likely 
as a comparator) instead of the GameManager. You (might) know everything by 
heart, but this makes it more difficult for the others.

I have to admit that most of my recent suggestions all intend to break those 
large classes into smaller pieces to allow easier and safer modifications.
Seems that we are moving in opposite directions here. 

Another admission: I already defined comparators for the Player and Company 
classes to have the GameReport sequence unique for the automated testing. 
There is even a class, which defines a sorting related to classes which all 
implement a common interface CashHolder (rails.util.SequenceUtil)
The latter would also be a place to put the sorting instead of the GameManager 
class.

On the specific task on hand:

My idea was to move only the ordering logic to the comparator (and if no price 
is yet defined put those at the end of sequence) and then have the specific 
methods only apply the filtering for floated companies.

By no means I did intend to suggest to move the filtering to the comparator, 
which is not possible as you rightly observe.

And on the company hierachy: 
I read the discussion (some years ago in the archive). I agree, I might have 
been even more drastic: Maybe one should even not have separate private and 
public companies classes (think about those operating privates in 1846). Even 
the fact that companies can operate or be purchased could be configured by 
attributes instead of defined by class (names).
I agree that in this case (as in many other cases like e.g. trains) the 
specific features should be configurable. If one wants to separate those 
features in different classes I would prefer composition instead of 
inheritance.

On Monday 05 July 2010 22:06:52 Erik Vos wrote:
> Stefan,
>
> I'm afraid this does not sound like a very good idea to me.
>
> AFAIK, a comparator requires *every* instance to be comparable. And
> non-started companies without a price aren't really well comparable for
> defining operating order purposes.
>
> Defining operating order (there are now two methods doing that, for
> different purposes and with different output) does not only require
> sorting, but also prior selection of the objects eligible for ordering.
>
> Yes, I realize that my new getCompaniesInRunningOrder() method does order
> *all* companies (contrary to everything I have said above), but (thinking
> about it) that's probably rather a bug than a feature. For now it works,
> but I don't consider it durable. In all likelihood the current logic will
> need major changes when adding games like 1837 and 1844 with their many
> different company types. And for such purposes I'd rather subclass
> GameManager (which must be done anyway in most new games) than
> PublicCompany.*
>
> Another consideration: recent developments increasingly force me to move
> logic out of the 'static' objects (companies, trains, tiles etc.) and into
> the 'dynamic' Manager/Round objects. Your proposal goes somewhat in the
> opposite direction.
>
> Erik.
>
> * That's a separate subject. Company class hierarchies have been discussed
> before in this forum. That might be a good idea if Java would support
> multiple inheritance, but it doesn't. There are too many company types with
> different mixtures of special features, and I have given up of thinking
> about catching these in hierarchies.
>
> -----Original Message-----
> From: Stefan Frey (web.de) [mailto:ste...@we...]
> Sent: Sunday 04 July 2010 23:46
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Price tokens change order when moving up.
>
> Erik:
> do you mind if I move the definition of running order into the
> PublicCompany
>
> class and define a Comparator?
>
> I can still keep the new method in the GameManager, but the change would
> later
> simplify the migration to the new sequence model.
>
> Stefan
>
> On Sunday 04 July 2010 22:57:26 Erik Vos wrote:
> > (Switching to the proper group)
> > This has been fixed now - in Subversion!
> >
> > Erik.
> >
> >
> >   _____
> >
> > From: 18...@ya... [mailto:18...@ya...] On Behalf Of
> > John A. Tamplin
> > Sent: Friday 02 July 2010 00:17
> > To: 18...@ya...
> > Subject: Re: [18xx] par value marker movement
> >
> >
> >
> >
> > On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
> >
> > <mailto:erik.vos%40xs4all.nl> > wrote:
> > > At the end of the SR, the companies are scanned for being sold out in
>
> the
>
> > > order in which they appear in the Game Status window. Any upward token
> > > moves
> > > are then executed in that order and follow the normal move rules. So I
> > > suspect that the token order gets reversed only if a 'lower' company
> > > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > > Indeed we need
> > > a saved file to prove that.
> > > In any case, I would encourage to file it as a bug, so it will get
>
> proper
>
> > > attention at some point.
> >
> > The tokens are supposed to be processed in market order, which winds up
> > preserving the same stacking.
>
> ---------------------------------------------------------------------------
>- --
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Price tokens change order when moving up.

[Aliza P. <ali...@gm...>]

I did not see a bug filed on this in SourceForge so I filed bug
3044491on it with a savefile.

(I also note that a more critical bug affecting 18AL, ID: 3026083, has
been marked as fixed but there's nothing in Sourceforge to tell me
what Rails release, if any, contains the fix.)

If the bug has been fixed, when can we expect to see a new version of
Rails published with the fix? Is there a way to set up Sourceforge so
people can see what published version contains the fix for each bug,
or at least add a "released" status after "fixed"?

Peter, Brad, Joshua, this involves a play-ahead of our game based on
my guessing what people would do, please do not look at the savefile
(though you can probably guess.)

 - Aliza

On Sun, Jul 4, 2010 at 1:57 PM, Erik Vos <eri...@xs...> wrote:
>
> (Switching to the proper group)
> This has been fixed now - in Subversion!
>
> Erik.
>
> ________________________________
> From: 18...@ya... [mailto:18...@ya...] On Behalf Of John A. Tamplin
> Sent: Friday 02 July 2010 00:17
> To: 18...@ya...
> Subject: Re: [18xx] par value marker movement
>
>
>
> On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...> wrote:
>
> > At the end of the SR, the companies are scanned for being sold out in the
> > order in which they appear in the Game Status window. Any upward token
> > moves
> > are then executed in that order and follow the normal move rules. So I
> > suspect that the token order gets reversed only if a 'lower' company token
> > is on top of a 'higher' one. Or it could be the reverse...:-) Indeed we
> > need
> > a saved file to prove that.
> > In any case, I would encourage to file it as a bug, so it will get proper
> > attention at some point.
>
> The tokens are supposed to be processed in market order, which winds up
> preserving the same stacking.
>
> --
> John A. Tamplin
>

Re: [Rails-devel] Price tokens change order when moving up.

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

Hi Aliza,
3044491 was already fixed, but still to be released.

The other 18AL bug you are referring to (3026083) is not that critical as you 
might assume: Version 1.3 only displays in the game report that the 4 trains 
are rusted. The game engine itself progresses correctly and allows the 4 
trains the additional run. The wrong text will be changed in the next release.

The other remaining 18AL bug (3017592) causes minor annoyance during revenue 
calculation for the company with named trains (always assumes that the bonus 
is scored if the cities to connect do not exist in the route network of that 
company). Again fixed in the next release.

I do not know an easy way to change the state of the bugs after a version 
release of Sourceforge (but I am no expert here), but usually you can assume 
that it will be the next release after the version for which the bug was 
reported and/or still valid (shown in the group field).

Stefan

On Friday, August 13, 2010 07:42:08 pm Aliza Panitz wrote:
> I did not see a bug filed on this in SourceForge so I filed bug
> 3044491on it with a savefile.
> 
> (I also note that a more critical bug affecting 18AL, ID: 3026083, has
> been marked as fixed but there's nothing in Sourceforge to tell me
> what Rails release, if any, contains the fix.)
> 
> If the bug has been fixed, when can we expect to see a new version of
> Rails published with the fix? Is there a way to set up Sourceforge so
> people can see what published version contains the fix for each bug,
> or at least add a "released" status after "fixed"?
> 
> Peter, Brad, Joshua, this involves a play-ahead of our game based on
> my guessing what people would do, please do not look at the savefile
> (though you can probably guess.)
> 
>  - Aliza
> 
> On Sun, Jul 4, 2010 at 1:57 PM, Erik Vos <eri...@xs...> wrote:
> > (Switching to the proper group)
> > This has been fixed now - in Subversion!
> > 
> > Erik.
> > 
> > ________________________________
> > From: 18...@ya... [mailto:18...@ya...] On Behalf Of
> > John A. Tamplin Sent: Friday 02 July 2010 00:17
> > To: 18...@ya...
> > Subject: Re: [18xx] par value marker movement
> > 
> > On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...> wrote:
> > > At the end of the SR, the companies are scanned for being sold out in
> > > the order in which they appear in the Game Status window. Any upward
> > > token moves
> > > are then executed in that order and follow the normal move rules. So I
> > > suspect that the token order gets reversed only if a 'lower' company
> > > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > > Indeed we need
> > > a saved file to prove that.
> > > In any case, I would encourage to file it as a bug, so it will get
> > > proper attention at some point.
> > 
> > The tokens are supposed to be processed in market order, which winds up
> > preserving the same stacking.
> > 
> > --
> > John A. Tamplin
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by
> 
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Price tokens change order when moving up.

[Stefan F. (web.de) <ste...@we...>]

Erik:
do you mind if I move the definition of running order into the PublicCompany 
class and define a Comparator?

I can still keep the new method in the GameManager, but the change would later 
simplify the migration to the new sequence model.

Stefan

On Sunday 04 July 2010 22:57:26 Erik Vos wrote:
> (Switching to the proper group)
> This has been fixed now - in Subversion!
>
> Erik.
>
>
>   _____
>
> From: 18...@ya... [mailto:18...@ya...] On Behalf Of John
> A. Tamplin
> Sent: Friday 02 July 2010 00:17
> To: 18...@ya...
> Subject: Re: [18xx] par value marker movement
>
>
>
>
> On Thu, Jul 1, 2010 at 3:43 PM, Erik Vos <eri...@xs...
>
> <mailto:erik.vos%40xs4all.nl> > wrote:
> > At the end of the SR, the companies are scanned for being sold out in the
> > order in which they appear in the Game Status window. Any upward token
> > moves
> > are then executed in that order and follow the normal move rules. So I
> > suspect that the token order gets reversed only if a 'lower' company
> > token is on top of a 'higher' one. Or it could be the reverse...:-)
> > Indeed we need
> > a saved file to prove that.
> > In any case, I would encourage to file it as a bug, so it will get proper
> > attention at some point.
>
> The tokens are supposed to be processed in market order, which winds up
> preserving the same stacking.