[Patch] Convert all rail depots and their trains r8 (r26360)

[MJP]

Hi!

Here is a patch that allows the player to convert a rail depot to another rail type (parts of the code are taken from other files of OpenTTD, especially the autoreplace system). Since it adds a new internal command, it breaks multiplayer compatibility (but if all players applied the patch, it should work).

To fully convert a rail network:

1. First you send all your trains to depot.
2. Then you use the classic convert tool (the depot containing trains are not modified).
3. Here is the new part: you open and upgrade the remaining depots:

   

   new_button_in_depot_window.png (15.29 KiB) Viewed 2866 times

4. A conversion window appears (see autoreplace? the same). You may choose a specific rail type with the dropdown in the bottom left corner. For each item on the left, you choose a replacement. If there is at least one train still moving in/out of a depot, an error message will appear (in that case, close the window, wait all your trains stop and retry).

   

   convert_window.png (10.04 KiB) Viewed 2645 times

5. That's all.

Patch:

convert_depot_r8_for_r26360.patch

(43.13 KiB) Downloaded 102 times

[r8]
- fix data transfer in multiplayer (require Packet::Send/Recv_binary() provided with enhanced viewport)

[r7]
- Fix compilation with gcc.

[Eddi]

and how would repeating the replacement scheme for each of the 500 depots on your 2kx2k map be easier than using the universal railtype?

[MJP]

I didn't know about this GRF which seems to be a great solution.
It should be more advertised, maybe integrated to the game and enabled by default.
Anyway, thanks for the tip!

[MJP]

I can't add a NewGRF to an already existing savegame so I still need this patch for the time being (and it's fun to do too).
Repeating the process once per depot is clearly unacceptable so I've extended the patch functionality: one ctrl-click, one mapping of replacements and that's all (although the universal rail type is still much easier to use).

The patch r2 is quite functional but I have no clue concerning the 3 known bugs...

Edit: For the bug of the cost, I left a TODO uncoded The paid price is certainly right while the estimation is wrong. I need to get some sleep...

[Zuu]

upgrade a rail depot to the next rail type

How is this "next" rail type determined? In some rail NewGRFs and/or train NewGRFs there may not be a clear "next" rail. Also if there is a high maintenance cost of some rail type, it may be cases when users want to downgrade even in cases when "next" and "previous" type is possible to determine automatically.

[MJP]

The r3 is indeed an upgrade tool based only on the enum RailType. I took a deeper look at _railtypes and extended the GUI to take into account all 16 possibilities. The next available rail type is now determined according to the sorting_order and a new dropdown let the player change that value. Downgrading is now possible but there are limitations (cargo decrease of wagons). Concerning NewGRF compatibility, I checked very quickly with NuTracks and it seemed OK.

However I don't know how to dynamically rebuild the list of a dropdown, how could I do that? (it's just to remove the selected rail type from the other choices)

[Zuu]

However I don't know how to dynamically rebuild the list of a dropdown, how could I do that? (it's just to remove the selected rail type from the other choices)

It would be better to mark that option as disabled. That is more transparent for users than hiding the option.

IIRC there is a solution in the GUI framework to always (re-)build the drop down when it is opened. There you can specify these things if you are not able to modify the drop down content without rebuilding.

[MJP]

IIRC there is a solution in the GUI framework to always (re-)build the drop down when it is opened. There you can specify these things if you are not able to modify the drop down content without rebuilding.

How embarrassing I had it working at a time, I thought I was doing it wrong for obviously no good reason and I commented the check. OK, so the dropdown's rebuild function is called from OnClick() and there we can build[+store] a list or provide a previous one (it was my first time using a dropdown in ottd). At least, following your advice, I had to review that part and got it working.

But seeing how it looks, this is not easy to "read". The other dropdown are on the scheme "title that introduces items"+list, that gives "Change type into" and the full rail types list. Looks good to me.