In
this thread about signalling, and
this thread about refurbishing vehicles, there has been some discussion or consideration of ways of reducing the micromanagement inherent in upgrading elements of the network. There is one method that I have recently devised of doing so that should be quite easy to implement in the code, and also make upgrading all manner of network infrastructure far easier for players.
Firstly, there would for certain sorts of assets (I suggest vehicles, ways, way objects and road signs/signals) be a datum representing the asset to which that asset is an upgrade, if any. For example, "concrete sleeper track" might have a value in the .dat file that says something like "upgrade=wooden sleeper track". That would mean that the upgrading system (discussed below) would know that, when one stipulates an upgrade of "wooden sleeper track", it should be replaced with "concrete sleeper track". If no matching asset is found, then no semi-automated upgrade would be available. There would also be a datum in the upgradable assets stipulating the cost of upgrade (something like "upgrade_cost=21000"), which would be the cost of replacing the older asset with the newer asset. If that line was omitted, the cost of the upgrade would be the same as buying the later type of the asset new. Finally, there would be a datum representing whether the asset in question is
only available as an upgrade (e.g. "upgrade_only=1"), which, if set, would hide the asset from the normal purchasing windows and thus enable it to be purchased only as an upgrade. This would be useful for refurbished vehicle types in particular.
Secondly, there would be, in the asset's information dialogue box (the window that appears when clicking on the asset with the inspection tool, or, in the case of vehicles, the vehicle's details window), three buttons: "Upgrade", "Upgrade all", and "Upgrade all in group". "Upgrade" would replace that single asset with the asset that is an upgrade to it, and cause the upgrade price (or, if not stipulated, the new purchase price of the upgraded asset) to be deducted from the player's coffers. Vehicles would keep their schedules (although perhaps ought have a trip to the depot before the upgrade takes effect), and signals, etc. would keep their state. (At a programmatic level, the upgrade would work not by replacing the assets at all, but by copying the data from the upgraded type of asset to the original asset, thus keeping all of the status data in tact). "Upgrade all" would do the same thing for
all assets of that type owned by that player. "Upgrade group" will be explained below. Below each of the three buttons would be the cost of each option.
Thirdly, there would be a system of asset groups. There would be a fixed number - perhaps 16 or 32 or so - of asset groups, and each asset would be assigned a group at the time of being built/bought. The group would be determined by the player, who could change an "asset group" setting via a menu button (perhaps in the "special construction tools" submenu), and perhaps also by a shortcut key (perhaps [ and ], if not already used?). The asset group would permanently be displayed in the right hand side of the ticker bar. The "upgrade group" button would then upgrade all of the assets belonging to the player that belong to that particular group.
Groups could be used like this: supposing that one had a line of lorries serving a factory, and another line of lorries serving another factory, all the same type of lorry. One could build all the lorries in the first line under group no. 1, and all the lorries in the second line under group no. 2. Ten years pass, and the first factory line turns out to be a great deal more profitable than the second. Many more lorries are added to the first factory's line. An upgrade becomes available to the type of lorry used for the first factory which increases its speed, but also increases its maintenance cost. Supposing that one decided that it was not worthwhile upgrading the lorries to the second factory, but that it was worthwhile upgrading the lorries to the first factory: all that one would have to do is click on one of the first factory's lorries, and select "upgrade group", and all of that line of lorries (but
not the line serving the second factory) would be sent to the depot for their upgrade.
Another example: suppose that one had a railway with a great many different lines, some minor, some major, all built in the 19th century with wooden sleeper track. Then, in the 20th century, concrete sleeper track becomes available, and allows trains to go faster, but costs a great deal to install. One would not want to have to replace each individual tile on the network manually with concrete sleeper track, but one would also not want to have to upgrade
all the track at the same time, since it may not be worthwhile or necessary to do so for small branch lines or freight routes that only have slow trains travelling on them in any event. So, one would be able to upgrade by group (assuming that one had used groups wisely when laying the track, of course, and had one group for each line or class of line), and upgrade the network in manageable chunks without excessive micromanagement.