Topic: Semi-automated upgrades and grouping

[jamespetts]

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.

[VS]

Hm, hm...

Upgrading groups could be more useful for whole lines, as long as we're talking about vehicles.

[jamespetts]

VS,

interesting point about vehicles - but then what about track and signals?

[isidoro]

For ways, I would work this way: if you click once on a way type icon, construction works as usual.  If you click a second time on the same icon, construction would behave like the road removing tool: it would rebuild of that new type what is there between the two points clicked.  That way you can upgrade to a more advance road in one step.  The machine that appears when building could have in the latter case a green upwards arrow to indicate upgrade behavior.

For signals, I would do it manually as it is done, if any, now.

For vehicles, three possibilities: replacement of this vehicle, of all vehicles of this kind or, of all vehicles of this kind belonging to a line.

For vehicles (II):  I don't like the idea of automatic upgrade indicated in the pak file.  When upgrading a vehicle, a window should appear with compatible vehicles and I would like to choose whichever I liked and not to be tied to preprogrammed upgrades or be forced to upgrade one step at a time.

[jamespetts]

Isidoro,

interesting ideas about how to automate upgrades, although some parts might be harder to code than others. I am hoping to look into upgrade code this week - do you think that you could look into how to do the click at one point and do something to all the track between there and the next point on which one clicks? As to signals, see the response here as to why an automated system is needed. Perhaps, then, vehicles could be upgraded by line, track as you suggest, and only signals by group?

The reason that I suggest an automated upgrade path for vehicles is that some vehicles could be re-built into other vehicles, and the cost of doing so would be considerably less than buying a new one. For example, many of the Great Western Railway's Star class were rebuilt in later life into the more advanced Castle class, but a number of Castle class locomotives were also built new. Obviously, rebuilding a Star class (which was quite similar) into a Castle class was cheaper than building a new Castle class from scratch. Furthermore, the system of specified upgrades for vehicles could be used to simulate refurbishment/rebuilding of those vehicles into modified versions that were never built as such from new, and then prevent the player from buying that type as new. For example, the Southern Railway's Merchant Navy Class, built in the early 1940s, was rebuilt in the mid 1950s to resolve a number of design problems. The original class had a great many difficulties, but the rebuilt version was a great success, its life only foreshortened by the drive to dispense with all steam power, but no new ones were built in that condition. Very often, public transport vehicles are given significant rebuilds part way through their lives which result in them emerging as quite highly altered, but no new examples are built. Similarly, a number of examples of the British Rail Class 47 was rebuilt very late in its life (when it was nearly 40 years old!) into the class 57 - a more reliable and more powerful version, keeping the same chassis, but replacing the engine and alternator with ones that were themselves secondhand, taken from another withdrawn class (the 56). Obviously, it would be silly to allow class 57s to be built from new - hence the "is_upgrade_only=1" option suggested.

Perhaps what would work is an additional option for vehicles, as well as "upgrade": "replace", which would let the vehicle be replaced with a brand new vehicle (at the price that one would pay for a brand new vehicle), whilst keeping all of the old vehicle's status data in tact? That would, perhaps, satisfy both requirements. To do all this looks as if it might be a lot of work - your work on that routing/overcrowding patch was very good: perhaps you could lend some assistance to this patch and we could each work on parts of it?

[isidoro]

I guess this will be a very loooong reply, longer than all yours, if that can ever be possible for a human being  :

You can count on me to help, but I'm afraid that my holidays are nearly over and surely won't have the time to keep to your pace.  You're the quickest patcher west of Pecos, no doubt.  With the speed of my last patch (one line/day average), we'll be finished by Chinese New Year (around February), Chinese New Year, I was saying, 2013, year more, year less.

I agree with you regarding the replacement/refurbished cost, but I would leave that for a second version, in which pak development can be affected.  Now I would work with what we have now.

First thing I would do is split the patches and, hence, the work.  My opinions on the three parts:

• Signals: I will join that to the signal thread you've just opened and keep apart from this
• Way replacement: seems pretty easy and feasible to me.  Not too much work and I think it has good chance to get into trunk (only my opinion here).  I would open a new thread for this
• The mother of all patches (vehicle replacement): here I can see a lot of work, with major changes to the game engine.  Similar questions have been discussed before without agreement.  Therefore, a very good work should be done here if this is ever to come to trunk (my opinion again).  And if it doesn't, it is certainly a lot of work for nothing.  So, I would think thrice before embarking.

I will now point out some features with problems vehicle replacement would have, to continue this thread:

• Vehicle/convoi dichotomy: when replacing, what is replaced individual vehicles or whole convois?  How we identify "convois of the same kind"?
• Compatibility: what if the new vehicle is not electric and cannot drive on a portion of tracks of the old vehicle, longer, can't hold some kind of cargo, etc.
• Depots: vehicles marked for replacement should be allowed to automatically go to a depot and be replaced.  What if there is no depot, or depot is outside the vehicle's zone and messes everything?  Once in the depot, the vehicle should be allowed to automatically replace and restart.  What if the track is occupied and cannot be restarted?
• Cargo: what we do with loaded vehicles?  Is the cargo transferred to the new one or is the vehicle first emptied at stations before replacing?  If transferred, what if the new vehicle's capacity is lower?
• Options:  there should be a lot of options for the patch to be flexible enough and accommodate to all likings and situations.  For instance, only mark vehicles for replacement or also empty first or also send to depot or also send to depot and restart...
• Visibility: marked for replacement vehicles should appear with a visible mark indicating so.

I've tried hard but I have to admit that I failed to post something longer that you...  Run out of ideas...   :'(

[jamespetts]

Isidoro,

excellent, I'm glad that you can help :-) I am in a similar position in respect of holidays - I am off until Friday, then resume normal work. I have been trying to get as much as I can done before then.

I'm not sure that I agree about leaving the upgrade cost/refurbishment until a second version, however: I can code the part to write to and read from the .pak files fairly quickly and pakset authors can be working on adding the parameters whilst we work on the code to make them do something useful - it is more efficient that way. That part of things does not add enormous complexity, so it makes sense to include it early on, especially as it would be more work in the end adding it to existing code.

Some thoughts on your ideas about vehicle replacement:

(1) it makes sense to replace individual vehicles, rather than entire convoys. The difficulty might arise when a vehicle is coupled to a vehicle to which its replacement could not be coupled: perhaps, in that instance, automated replacement ought be prohibited, with a tooltip on the greyed out button explaining why;

(2) there could be a similar approach as above to issues relating to incompatible cargo; for incompatible routes, the convoy would just have to give a "no route" message when it had finished being upgraded (however, this does show why a designated upgrade path as originally suggested might be a good idea);

(3) the best way of doing it is to allow replacement only in a depot, and to send vehicles to a depot automatically if one tries to upgrade them outside a depot - if there is no depot (which would be daft, since a player always needs a depot), the vehicle would show "no route" when it was sent to a depot; cargo could be dealt with in the usual way for depots, by being lost inside the depot;

(4) if vehicles are always emptied on entering a depot, this would nto seem appropriate; and

(5) perhaps, but where would the mark be? In the convoy window? On the map?

Thank you again for co-operating on this. Do let me know any further thoughts.

[isidoro]

(1) it makes sense to replace individual vehicles, rather than entire convoys. The difficulty might arise when a vehicle is coupled to a vehicle to which its replacement could not be coupled: perhaps, in that instance, automated replacement ought be prohibited, with a tooltip on the greyed out button explaining why;

As I understand it, that very reason is one in favor of replacing convois.  One can be presented with the convoi.  There can be an empty window under.  A "copy" button can optionally copy the convoi from up window to down.  Then one can add, replace, etc. vehicles.  Some options: unload first, send to depot, send to depot and start, only this convoi, convois like this in this line (if there is a line attached), all convois like this.  Then, accept button.

Everything starts to work, some problems are just now addressed in the program (no route, the "Go to depot" button of convois, the "withdrawal" button of convois).  The parts not done automatically, are left to the player.  For example, if send to depot is not checked, the vehicle is only marked for replacement, but that it postponed until the player manually sends the vehicle to depot.

[jamespetts]

As I understand it, that very reason is one in favor of replacing convois.  One can be presented with the convoi.  There can be an empty window under.  A "copy" button can optionally copy the convoi from up window to down.  Then one can add, replace, etc. vehicles.  Some options: unload first, send to depot, send to depot and start, only this convoi, convois like this in this line (if there is a line attached), all convois like this.  Then, accept button.

Everything starts to work, some problems are just now addressed in the program (no route, the "Go to depot" button of convois, the "withdrawal" button of convois).  The parts not done automatically, are left to the player.  For example, if send to depot is not checked, the vehicle is only marked for replacement, but that it postponed until the player manually sends the vehicle to depot.

The problem is - suppose that the player only wants to replace, for example, the locomotive of a train? Suppose that the coaches are already of the latest design? And if the convoy consists of a mix of different locomotives and carriages, how does the player choose what to replace each of them with if he/she just clicks one button to upgrade them all?

If I have a train consisting of a new locomotive and three new carriages, but also two older carriage designs that I now want to replace with the latest design, how would I do that under a system that replaced only entire convoys?

[isidoro]

The problem is - suppose that the player only wants to replace, for example, the locomotive of a train? Suppose that the coaches are already of the latest design? And if the convoy consists of a mix of different locomotives and carriages, how does the player choose what to replace each of them with if he/she just clicks one button to upgrade them all?

In an ulterior phase, there can be a "wildcard" vehicle which matches any vehicle.  Otherwise, it should be done one type of convoi at a time.  If you replace vehicles instead, you are not free from those special cases either.  One can want to replace all locomotives of a certain model except two or three cases.

If I have a train consisting of a new locomotive and three new carriages, but also two older carriage designs that I now want to replace with the latest design, how would I do that under a system that replaced only entire convoys?

You choose one vehicle of the old design, replace it and check all convois of this type.

[jamespetts]

In an ulterior phase, there can be a "wildcard" vehicle which matches any vehicle.

I am not sure what you mean by that - can you explain?

Otherwise, it should be done one type of convoi at a time.  If you replace vehicles instead, you are not free from those special cases either.  One can want to replace all locomotives of a certain model except two or three cases.

You choose one vehicle of the old design, replace it and check all convois of this type.

What do you mean by "convoys of this type" here: convoys on the same line? One line might be served by convoys with twelve or thirteen different configurations...

[isidoro]

The wildcard thing: in the convoi window, you can keep the original vehicle in which case it works as usual or you can replace one or several vehicles by a wildcard vehicle.  In that case, when you check "all vehicles like this one", the wildcard vehicles will match anything.  For exampe, I want to replace all convois in a line with loco A with loco B.  In the up window, I would use wildcard vehicles instead of carriages.

"all convois of this type" is one of the options that I proposed.  It means to replace all convois equal to (or equivalent to if wildcards are used) the one I have opened.

[jamespetts]

I'm afraid that I'm still having trouble understanding the wildcards - how is that different from just selecting the locomotive and pressing an "upgrade all on this line" button as in my original suggestion? Would one have to de-select the carriages manually from being upgraded...?

[isidoro]

Well.  When replacing, there has to be a selection mechanism, i.e., which convois are objective of replacement.  One has to take one convoi.  Let's call that convoi convoiA.  The original idea is that you can replace only convoiA, all convois equal to convoiA, or all convois equal to convoiA that belong to the line of convoiA.

Now, wildcards.  Wildcards add to the concept of equality in the latter sentence.  I can change one or several vehicles of convoiA with wildcards.  A wildcard vehicle will match any vehicle.  For example, let convoiA be: LocoA-CarriageA-Wildcard-Wildcard.  A convoiB with LocoA-CarriageA-CarriageA-CarriageB will be eligible for replacement.  A convoiC with LocoA-CarriageB-CarriageA-CarriageB will not, since the first carriage doesn't match.

Wildcards would be advanced functionality for a second phase.  Just without wildcards, the tool would be a great help against micromanagement.

[jamespetts]

Ahh, I see what you mean - that would certainly be complicated to implement. Perhaps the whole convoy replacement, then, should be left until version 2, and the wildcards can be implemented? I am quite keen for the idea of refurbishment to be represented with this system, and that cannot be done if convoys are replaced entirely without that level of granularity. If we start with upgrading vehicles with designated upgrades (which should then have the same coupling constraints), and then later move into convoy replacement with wildcards if we can manage it, do you think that that might work?

[isidoro]

My opinion is to work the other way round.  First, the option to replace with whatever vehicle, with an empty replacement convoi and a copy button (that put down the original convoi to make changes).  Then, refurbishment or whatever.  Patch over patch.  When you open the replacement window, the refurbished version of the vehicle will appear by default so that you have to only accept to do refurbishment.

[jamespetts]

Perhaps it would be helpful to break down the tasks to do in terms of work to be done on the code. It seems that we need the following components:

(1) a method for replacing one type of vehicle, way, way object, roadsign, etc., with another type without altering the instance data (I imagine that this will be relatively easy given the way in which the code is structured, with a separate type ("besch") class for each type of object, and then an instance class with all the instance data;

(2) code for reading and writing of additional parameters for the .dat/.pak files to specify upgrades (a parameter for "upgrade from", a parameter for "upgrade cost" and a parameter for "available as upgrade only) - these will be needed initially whether or not we deal with vehicle upgrades, as they will be required in any event for way/way object upgrades;

(3) code for replacing entire sections of way at a time;

(4) code for replacing entire sections of way objects at a time (if not already extant);

(5) code for replacing (or possibly even placing) batches of signals at a time;

(6) a GUI for the replacement of vehicles by line and type (including, eventually, for replacement in complex patterns by wildcard as you suggested);

(6) a GUI for the replacement of way/way objects/signals by batch;

(7) modifications to the depot GUI for taking account of vehicles' upgrade costs, and vehicles available only as an upgrade; and

(8) GUI notifications of the availability of types available as an upgrade, or only as an upgrade being differentiated from notifications of types available to purchase new.

[isidoro]

Overwhelmed!

[jamespetts]

Well, shall we start slowly? Every journey of a thousand miles starts with a single step :-) Perhaps I could start with (1) and (2), and perhaps you could start with (3) and (4), and we'll see how we go from there?

[isidoro]

I'm only interested in the replace tool, not the upgrade/refurbish/pak one.  Nevertheless, I lack time again and little time I have is spent in the passenger QoS stuff.  Sorry.

[jamespetts]

I'm only interested in the replace tool, not the upgrade/refurbish/pak one.  Nevertheless, I lack time again and little time I have is spent in the passenger QoS stuff.  Sorry.

That's why I suggested that you do nos. 3 and 4 :-) But you don't even have time to do that at all now...?

[isidoro]

My holidays are now over.  I don't want to say yes and later not be able to keep my word.  You go too fast for me.  I prefer lighter tasks now, if any.  I will help in what I can, but can't commit myself.  Sorry.

[jamespetts]

My holidays are now over.  I don't want to say yes and later not be able to keep my word.  You go too fast for me.  I prefer lighter tasks now, if any.  I will help in what I can, but can't commit myself.  Sorry.

Ahh, then I am afraid that we may not have an automated track replacement tool after all...

[isidoro]

Don't be pessimistic.  It's only a question of time.   

[isidoro]

I'm playing with pak.german now.  I'm in 1902 and I don't have a replacement for Horse Carriages, the only road vehicle capable or carrying passengers.  The map I'm playing is a very, very hilly one, so that trains are no good option.

I have 246 horse carriages altogether!  I'm sweating thinking about replacement when the first bus arrives... 
So, I have decided to try to code the replacement window, but at a slow pace.  Will take a lot of time so I will freeze in a release.  I will open a new thread when I have something, if I ever have.

[[[ Well, to be honest, I dare say, though feeling terribly ashamed, that I like coding, for the pleasure of it...  :  My God, I'm sick, I should have my brain checked...  :  Please, don't tell anyone... ]]]

[jamespetts]

Isidoro,

I shall very much look forward to seeing the results of your progress! And don't worry that you like coding for fun - surely, what you really mean is that you enjoy the experience of making things work as you intended?

[isidoro]

No, no, James...  The problem is that I have no time, but keep coding...  Addiction is a problem only when you can't leave it...  Too bad!

[jamespetts]

No, no, James...  The problem is that I have no time, but keep coding...  Addiction is a problem only when you can't leave it...  Too bad!

Maybe you should see Programmers Anonymous?

[isidoro]

- Hello, everyone, I'm also a code-addict...
- HELLO, ISIDORO! (everyone else)

    

Good Luck with your experimental release, James.  If there were a way to activate/deactivate certain patches, it would be a *very nice* tool, but I guess that is very difficult...

[jamespetts]

- Hello, everyone, I'm also a code-addict...
- HELLO, ISIDORO! (everyone else)

    

Good Luck with your experimental release, James.  If there were a way to activate/deactivate certain patches, it would be a *very nice* tool, but I guess that is very difficult...

Well, actually, for quite a lot of the new developments, there are settings in simuconf.tab that can be used to revert to pre-patch behaviour, or something close to it.

[isidoro]

I was thinking more on a standardized way to develop patches so that they can auto-inhibit themselves at will, so that your platform would be a workbench where everyone could test new features.  But that, I think, would be very difficult, if not impossible.  That standard way should be easily reverted in the case that feature is included in trunk.