From: Stefan F. <ste...@we...> - 2010-08-16 20:19:31
|
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 |