Menu
▾
▴
Re: [Rails-devel] Rails 1.7.x revenue display / calculation bug
|
From: Stefan F. <ste...@we...> - 2012-04-10 11:41:50
|
Mike: thanks for your input. The good news is that neither the route calculation, nor the standard workflow is broken. That remains that there is an issue with the multi-concurrency used to display the active routes, which is annoying, however does not prevent game play. So I will look into this as soon as I will finalize my work on stabilizing Rails2.0. Stefan On 04/06/2012 03:41 AM, Mike Bourke wrote: > Hi Stefan - > > 1) > > Closer inspection shows that the "better route" I thought I was seeing for > the B&M required re-using a tiny segment of track from D20 to E19. Small, > but enough to invalidate the result. I could not reproduce the strange > behaviour of the route display either. > > 4) > > I focussed on the NYC operating round in OR 8.1, as requested. > > in the enclosed zip file are 4 copies of the log and 3 saved games showing > the different stages of the bug for the NYC operating round. > > "Copy of 18xx.log" is from the original game and may not be of much use to > you. It was created prior to relaunching any games. > > I then deleted the original log file and relaunched the game, loading the > saved game that I have previously sent and returning to the first noted > aberrational behaviour (B&M's op round 8.1) and playing forward from there. > > "Copy (2) of 18xx.log" and "1830_20120406_0054_Mike_8.1(2).rails" give the > initial display of the NYC route and all looks fine. This corresponds to the > screenshot 1830-bug-03.jpg. > > "Copy (3) of 18xx.log" and "1830_20120406_0054_Mike_8.1(3).rails" give the > results immediately after "no token" was clicked. This corresponds to the > screenshot 1830-bug-04.jpg. > > "Copy (4) of 18xx.log" and "1830_20120406_0054_Mike_8.1(4).rails" give the > display immediately after collecting the revenue, and the display is back to > normal. Note that 1830-bug-05.jpg was the result of clicking "undo" after > paying revenues. I did not attempt to generate a log or saved game for this. > I have confirmed that loading "1830_20120406_0054_Mike_8.1(3).rails" or > "1830_20120406_0054_Mike_8.1(4).rails", setting revenue, paying out revenue, > and then clicking "undo" produces this route display and an earnings > description of "Best Run Value = 1070 with 6-train=220; D-train=640". > > 2) > > My system configuration is Intel Celeron 2.66GHz, 2.0Gb RAM, running XP Pro > 2002 Service pack 3. > > 3) > > Turning off the Active Routes fixed the problem, and the route displayed and > values shown looked fine. So, while I find it a useful tool for determining > where best to lay tiles early in the game, the point at which it becomes > most useful (once diesels enter the game) is the point at which Active > Routes becomes unreliable. > > Mike Bourke > Campaign Mastery http://www.campaignmastery.com > Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com > > -----Original Message----- > From: Stefan Frey [mailto:ste...@we...] > Sent: Friday, 6 April 2012 2:14 AM > To: rai...@li... > Subject: Re: [Rails-devel] Rails 1.7.x revenue display / calculation bug > > Mike: > thanks for your detailed post about your observed bugs. > > Most likely there is an issue with the update of routes and revenue > information. The revenue calculation runs in a separate thread and > updates from there. During a calculation the revenue thread informs the > UI about intermediate and best total run values. > > However it is the taks of the UI thread to ask the revenue calculation > thread for route information (including break down by trains), so the > mechanism for getting routes and total values are completely different > ones. Something in the synchronization between the calls went wrong on > your system. > > I admit I had to rely on my sparse knowledge of Java 1.2 multi-threading > instead of using the new and superior methods available now. This is on > my todo list to be upgraded in Rails 2.0. > > So I have the following questions: > > * In one case (the B&M, bug 1) I have not found the better route you > imply (see below). > > * What hardware to you use? On my PC I cannot replicate the issues you > had, but the calculations run quickly fast here, so that none of the > intermediate results can be seen (none runs for more than a second, even > for the double Diesel runs). Thus I cannot replicate your bugs (except > the B&M case, but see above). > > * Could you turn off the option in Configuration => Map => Show active > routes and check if you still see those kind of bugs? This option has > been introduced by Frederick in 1.7.0 recently (and it runs in a > separate thread as well). > > * Could you replicate one of the bugs (again except B&M) and then > immediately store and send me a copy of the 18xx.log file which is > located in the working directory of Rails? > > Stefan > > Some more detailed comments see below (more for me for reference) > > On 04/05/2012 03:11 PM, Mike Bourke wrote: >> The revenue calculations and routing displays in the 1.7.x series continue >> to behave strangely, as illustrated within the saved game and series of >> screen captures attached. >> >> While the example is from 1830, I have observed the same behaviour in >> several other of the games implemented in Rails 1.7.0. >> >> 1830-bug-01.jpg is taken from before a company (in this case, the B&M) > lays >> a tile during Op Round 8.1. Note that it shows routes for both trains but >> ignores the lucrative route to the west. > > How to you run the lucrative route to the west, the loop via South NYC > to Balitmore and a good 5 at the same time? I have seen at least no easy > improvement over the route currently found, but you might have checked > that better than me? > >> >> 1830-bug-02 is taken immediately after a piece of straight track has been >> layed and "no token" chosen, without increasing the potential payout at > all. >> Accordingly, the optimum revenue route should not have changed. And yet, >> mysteriously, the 5-train routing has vanished from the display even > though >> there is clearly at least one obvious route, and the Diesel route has >> completely changed. Note also the information at the top of screen, which >> reads, "Best Run Value = 920 with 5-train = 0; D-train = 770". Clearly the >> routing optimisation is being performed by two different algorythms, and > one >> of them has a bug in it. > > Route information belongs to the best Diesel run alone (so this is a > temporary result after finding the best Diesel run). The Best Run Value > belongs to the best combined (D,5) run. > >> >> --------------------------------------------------------------- >> >> 1830-bug-03 is taken from later in the same operating round. The NYC has >> layed a tile, and the route displayed is entirely reasonable. > > Agree, seems ok. > >> >> As soon as "no token" is clicked, the and the computer is permitted to >> calculate its optimum route, the display changes to that shown in >> 1830-bug-04.jpg. The 6-train route has vanished, the diesel route > displayed >> is the one that would have been optimum IF the company only had a diesel, >> and the text at the top of screen reads "Best Run Value = 1070 with > 6-train >> = 0; D-train = 780". > > See above: Best Diesel run as route information, whereas the best run > value shows best (D,6) run. > >> >> Using "undo" and then again choosing "no token", the routing display >> abruptly changes to that shown in 1830-bug-05.jpg! Note that the lucrative >> routing to the west is suddenly being ignored, both trains have a > displayed >> value, and the text at the top of the screen has changed to read "Best Run >> Value = 1070 with 6-train = 220; D-train = 640". These individual train >> earnings numbers do match the route displayed, but don't match the best > run >> value total. The game save is from this point. > > This is now an intermediate result from the (D,6) optimization which has > not found the best combination yet. Best run value again correct. > >> >> But as soon as you "set revenue", the route changes, as shown by >> 1830-bug-06.jpg - to what once again appears to be the optimum route, and > is >> *hopefully* the one that matches the actual payout total. >> > > That is ok, given that you have triggered the next phase, it calculates > and displays the current best values again. > >> ------------------------------------------------------------- >> >> At the start of the next operating round, after a tile has been layed by > the >> NYNH, and "no token" chosen, I was presented with the display shown in >> 1830-bug-07.jpg. This is clealy the other side of the coin. The only route >> showing is that of the 5-train, and the information shown at the top of > the >> screen confirms this: "Best Run Value = 1040 with D-train = 0; 5-train = >> 260". > > OK: This time the trains got optimized in a different order: It shows > the best 5 train for route information, but the total run value is correct. > > Remark: In fact there is no order in which trains should be optimized as > in the final run the best set of simultaneous runs has to be found. > However as part of the revenue prediction algorithm which allows to cut > the search tree, it helps to calculate single runs first (and for more > three and more trains, to run smaller sets of trains first). > > >> >> ------------------------------------------------------------- >> >> Unfortunately, I was unable to replicate the other bug that I had > previously >> observed, which also involved the correct calculation of the optimum > route. >> But this bug (and I suspect it is just one bug, despite the variation in >> symptoms) should give the development team enough to be getting on with! >> >> Notes: this bug doesn't always manifest. You may have to use the game > report >> to return to an earlier stage of the game to replicate the effects, or to >> click "undo". For example, on reloading the saved game, they NYC display > and >> payout appeared quite correct. >> >> >> Mike Bourke >> Campaign Mastery http://www.campaignmastery.com >> Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com >> >> >> >> >> >> >> --- >> avast! Antivirus: Outbound message clean. >> Virus Database (VPS): 120404-0, 04/04/2012 >> Tested on: 5/04/2012 11:12:16 PM >> avast! - copyright (c) 1988-2012 AVAST Software. >> http://www.avast.com >> >> >> >> >> >> >> >> > ---------------------------------------------------------------------------- > -- >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> >> >> >> _______________________________________________ >> Rails-devel mailing list >> Rai...@li... >> https://lists.sourceforge.net/lists/listinfo/rails-devel > > > ---------------------------------------------------------------------------- > -- > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > --- > avast! Antivirus: Outbound message clean. > Virus Database (VPS): 120405-0, 05/04/2012 > Tested on: 6/04/2012 11:41:29 AM > avast! - copyright (c) 1988-2012 AVAST Software. > http://www.avast.com > > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
