Roadmap for version 1.1.0 Expand all | Collapse all
71% of 34 tasks completed. 9 open tasks:
- FS#3569 - x/y location of wagons outside of wagons Expand Collapse
-
Open the attached savegame, start the train in the red depot and fastforward a few days. The red train and the purple one will crash.
- FS#3637 - Second highest competing station rating doubly penalized when di Expand Collapse
-
In the current MoveGoodsToStation calculation, the penalty adjustment (effectively dividing the rating in half) to the second highest station rating is applied too broadly. It correctly (as documented, but not quite desirably, the subject of another feature request) affects the split of goods available to the two stations. However it remains in effect when the amount of wasted goods are calculated for the second station, which seems like an undesired and unanticipated side effect.
By way of an example, simplified to % instead of internal n/255ths, two stations have ratings of 80% and 60%. 100 goods are split between them with the first being assigned (100+1)*80/(80+(60/2))=73 of them and the second the remaining 27. The first then actually gets 73*80/100+1=59 goods. The bug occurs when the second gets 27*(60/2)/100+1=9 goods instead of 27*60/100+1=17, strangely increasing its internal post-split wastage from the expected 40% to around 70%.
Attached is a patch that moves the penalty to the correct location.
- FS#3714 - Crash on loading corrupted savegame Expand Collapse
-
Using Windows XP. Upon loading savegame 'NOT_REACHED triggered at line 719 of ..\src\saveload\vehicle_sl.cpp' error displayed.
- FS#3746 - interesting handling of mixtures of rtl and ltr languages Expand Collapse
-
Clients can chose any language, thus independently an rtl or ltr language, thus nicknames are available in both rtl and ltr. The handling of rtl nicks in ltr languages is bad as it breaks the ltr strings. Probably the same applies in reverse. Attached the screenshot where I set an arabic nickname on one client and the console of a ltr (German) server where this client joins. Note the broken join message for the last client which is the arabic nickname.
- FS#3935 - Pause + Goto depot from terminus station = ignoring queues Expand Collapse
-
To reproduce:
- create terminus RV station
- send 2 no articulated RV with full load order to that station
- pause game
- send both vehicles to depot
- unpause game
- admire 2 RV starting in the same moment ignoring queueing.
==
Windows 7
- FS#3952 - rescan_ai in console doesn't work Expand Collapse
-
r20131
what it says, typing rescan_ai into the console does not appear to do anything, as it still thought an ai i'd just deleted was still there
unless of course, it's supposed to do something else?
- FS#4025 - NewGRF Parameter list too long - r20442 Expand Collapse
-
Please see attached images. Newer GRFs have the ability to limit parameters, such as FIRS.
But older GRFs doesn't, such as CS rails and Combined Airports Set.
The list expanded to 128 items.
Is it because of the limited information provided by older GRFs?
- FS#4094 - scenario editor "add many" Expand Collapse
-
r20635
For some reason, the scenario editors place "many random X" (where x is either towns or industry) is tied to to the "new game" settings "no. of towns", "no of industries".
For example, if I click "build" for many industries in the scenario editor, it simply won't place a single industry if "no. of industries" in the newgame dialog is set on "none". If I change this setting, the number created is dependent on what the new setting is at.
I would instead suggest that a fixed (and very low) number be randomly place. If the user wants more, it's easy to click it a few more times, but removing items (especially from a large map) is much more time consuming.
Semi-relatedly tree's plant too many when you click "random trees". If I want sparse tree cover there's no way to do it except manually. Again, it's easy to click "random trees" many times if you want less-sparseness.
- FS#4096 - Unable distinguish player built/randomly generated industries in Expand Collapse
-
Industry variable A7 (http://wiki.ttdpatch.net/tiki-index.php?page=VarAction2Industries#Industry_founder_information_A7_) returns 10h for "many random industries" as well as for manually placed industries.
The documentation states that "10h [is returned] if the industry was generated randomly". However, this is also returned for manually constructed industries in the scenario editor. It would be appreciated if manually constructed industries could return something else than 10h (possibly 00).
Background: for FIRS we would like to differentiate between randomly placed industries and manually placed industries. That way we can force industries to have a 1-tile buffer between them if randomly constructed, but allow users to manually build industries without a buffer. Currently this works fine in normal game, but not in the scen editor.
Note: this can also be considered a feature request, but I thought of it as a bug, as the documentation description does not match behaviour. It is fine if you fix this bug by fixing the documentation, but then I'm required to file this anew as a feature request :D
Text Version