Topic: Balance discussion: cost (maintenance, convoy re-combination and others)

[jamespetts]

One of the major tasks that lies ahead is altering the vehicle/convoy cost model to take into account the need for regular maintenance and overhauls, as well as time spent in maintenance. It is also necessary, in order to make full use of fixed costs, to allow for a convoy to be in a state of lay-over, in which it is static, with no passengers/goods on board, in which it is not incurring any fixed costs (e.g. because there is no driver in the cab, as it is awaiting its next turn of duty).

Another task that will need to be done at some point is allowing convoy re-combination: for example, allowing locomotive changes on railway trains. This is particularly important for railways, for which the ability to change locomotives in service was very important throughout most of their history (although has become much less important in recent years).

That latter task in particular is likely to be extremely complex to implement (more complex than signalling, and signalling took well over a year to complete and there are still a number of bugs even now that need to be resolved).

I had planned to undertake both of these things at the same time so that, for example, a locomotive could be separated from its carriages to be maintained/refuelled. However, given that the game is really only suitable for sandbox play until balancing occurs and that the convoy recombination task is likely to be gargantuan, I have wondered recently whether it would be sensible to split the two projects. That requires a maintenance/overhaul/availability system that will work properly without convoy recombination but that can readily be adapted to work with it.

I have devised the following system, which I will set out in outline below. I should be grateful for any considered feedback on this scheme.

All vehicles would have an availability percentage. This would denote the time that those vehicles are not spending being maintained. There would be two options (settable in simuconf.tab) as to how to handle this: (1) the simple option, more suited to sandbox play; and (2) the realistic option, more suited to economic play. In the simple option, the vehicle's capital cost would be multiplied by one divided by the availability percentage. So, for example, a vehicle with an availability of 75% would cost 25% more to purchase in the simple model. This would be intended to simulate the cost of having to buy extra vehicles of the same type to cover the period that the vehicle in question is being (notionally) maintained. The actual maintenance would not be simulated directly. This would be the default option for loading existing saved games.

The realistic option would not adjust the purchase price, but would instead mandate that every schedule have a depot of a suitable type for that convoy as an entry. A schedule without a depot would not be valid. Each depot entry in a schedule would have parameters determining (1) the frequency of the visit (i.e., how many times would the convoy pass the depot before visiting); and (2) whether the visit is for maintenance or whether the vehicle is to go to the depot for storage (the current default behaviour). Depending on the length of the route and the vehicle's availability percentage, there would be a minimum limit on the frequency of depot visits in the schedule.

Because at present a convoy entering or leaving a depot triggers a re-run of the path explorer, this would have to be altered so as only to run the path explorer when entering a depot for storage, not for maintenance. The path explorer would ignore depot visits for the purpose of calculating routes.

The maintenance time in the depot would then be based on the availability percentage and the time since the vehicle last visited a depot. For example, if the vehicle had last visited the depot exactly an hour ago and its availability percentage were 75%, the vehicle would spend 1/4 of an hour being maintained before becoming available again. This time would be based on the vehicle in the convoy with the lowest availability percentage. (It will thus be seen that convoy re-combination would allow players to make more efficient use of their resources in the case of trains).

Further, convoys should be able to enter a state of layover at any stop, as set by the schedule: but this would require discharging all of the passengers/mail/cargo at that stop, and have a minimum dwell time for putting the vehicle into a state of layover. During a layover, no fixed maintenance costs would be charged.

As vehicles accumulate distance since they were first bought, their per kilometre cost would increase based on settings in their .dat files. It would be possible to reset this increased cost by overhauling the vehicle. This would be done on a visit to the depot. There would come a point in time (defined in kilometres since purchase or last overhaul, except for aircraft, where it would be defined in number of takeoffs) where the vehicle would have to have an overhaul in order to continue running at all. This would be set in the vehicle's .dat file, as would the cost of an overhaul. By default, vehicles would be overhauled at the point in time when it is compulsory to do so, but players should be able to set a convoy (or a whole line) to overhaul early on their next depot visit. The default cost of overhaul in the absence of being specified in the .dat file would probably be something like 1/5th of the purchase cost (although I should be interested in any data).

The vehicle replacer would continue to work largely as it does now, except that the replacement would occur on the next scheduled depot visit rather than ad hoc as at present.

Until convoy re-combination can be implemented, it will be assumed that all vehicles can refuel/replenish without visiting the depot or discharging their cargo. However, this should now take a minimum amount of time. This would be implemented as follows: when the schedule is created/amended, a set of range stops will be calculated. These are the stops on the schedule (ignoring the depot and any waypoints) where the vehicle needs to refuel/replenish. For example, suppose that a vehicle with a range of 100km had 10 scheduled stops, each 30km apart: it would have to make one range stop every 100km, so stops 4 (after 90km, the next stop being 120km) and 8 (after 180km, the next being 210km) would be range stops, where the convoy would wait longer than at other stops. It could continue to load/unload whilst replenishing, so this would just increase the minimum loading time, and might not affect at all the loading time for vehicles, such as ships and aircraft, that take a long time to load. This would not alter the convoy's state. The range stops should be marked on the schedule.

I should be grateful for people's views on these ideas, which are aimed at expediting the balancing of the game, which has been seriously delayed to date.

[zook2]

With current depot building and maintenance costs, having a depot for every line, or most lines, would be prohibitively expensive. So we'd have to separate maintenance docks from shipyards, for example.

Also, if I understand your concept correctly, working out complex schedules for rail lines would become moot, as any maintenance/refueling stop would easily upturn the entire schedule.

[jamespetts]

One would not have to have a depot for every line: a number of lines could share a single depot.

As to schedules, I will have to give some consideration as to how players might control what happens to convoys when they leave depots after having been sent there automatically, but the aim should be to allow players to allow for depot visits in their schedules, for example, by having extra convoys or having a sufficiently long lay-over at one end of the trip that a depot visit can be accommodated there should one be needed. Giving players control of what happens to a convoy on leaving a depot (whether it leaves the depot straight away or waits for a particular point in time, and whether it goes into lay-over, etc., for example) should help to make this possible.

[AndrewTraviss]

Cities in Motion uses a system similar to this, and it mandates that all lines must originate from a depot, which is probably the simplest and most intuitive rule; the vehicles on a line will initially emerge from a depot, after all.

Rather than having to micromanage the maintenance frequency, perhaps having two settings on the line itself would suffice:
- minimum km of wear before vehicle maintenance
- number of vehicles in simultaneous operation on the line

Vehicles beyond the configured number would enter the depot and receive any needed maintenance, remaining at the depot even if all maintenance is completed. Once a vehicle that is actively operating the line reaches the wear threshold, it would plan to drop what it is carrying at the stop before the depot and check in for maintenance. The vehicle with the least remaining maintenance in the depot would be dispatched to the same stop to pick up the passengers/goods that were dropped and continue the route.

This allows the player to balance quality of service vs maintenance costs through a relatively simple mechanism that clearly relates to the vehicle statistics available to them.

[Ves]

From on top of my head, I would think it was better to implement the recombination of vehicles first as that somehow seems more fundamental. But i trust that you make the right decision! :-)

I'm all for controlled automation! That is, I want ultimately to be able build a line with all the small details I want, and then it works like that until I change it (or become bankrupt). If there are problems, I want to be properly notified what is the problem so I can take care of it.

Doing the decision on a per line basis sounds nice, especially if the convoy recombination also will work on a per line basis. Having all the controls the same place is very handy!
However, it would also be nice to have the possibility to make these decisions directly to a vehicle, without taking it away from its schedule. Say you have a line with some different vehicles in that have quite different needs, it would be very convenient to have only one schedule but be able to say that these five convoys can travel two times back and forth, but these five can only travel one time back and forth.

All this makes me wish that the depot is not a single tile building that the trains disappears into. How cool would it be if the "depot" where actual tracks so you could see and click on the trains being in there.
This would also make players build depots at more strategic and thought out locations, due to its possible size, rather than everywhere you might need a depot. Big depot can serve many vehicles, but small ones could only serve a few at a time.

[jamespetts]

Thank you both very much for your input: that is very helpful.

Andrew - those are interesting ideas, and could work well (although, given the way that schedules work in Simutrans, it would not be any different in practice to mandate that a route starts from a depot than that it includes a depot somewhere, and the latter would be more flexible; but creating a new schedule might start with the current depot (set to a maintenance visit) as the default, perhaps). You have devised, I think, quite a good way of simplifying the interaction with this in a workable way (and I remember that this aspect of things worked quite well in Cities in Motion 2, despite that game's other flaws). There may well be something to be said for Ves's idea, however, of also allowing players to alter the minimum distance before maintenance setting on a per convoy basis given that a line might well have different types of vehicles running on it. (Someone a while ago had an interesting idea about groupings of similar lines with slight differences between them that could all be edited together as if they were one line, and even volunteered to code it, but then sadly disappeared; this would have helped here, I think).

We might also, until the implementation of convoy re-combination, use depot stays as the way of achieving lay-overs (i.e., periods of time when convoys are at rest and not incurring fixed maintenance costs), and leave the idea of lay-overs out of depots (which realistically would only be likely to be used for trains in any event) until the implementation of convoy re-combination.

As to convoy re-combination, the reason to put this behind the maintenance features is that the maintenance features are essential before balancing work can begin, whereas the convoy re-combination features are not, and there really is only half a game without economic balance: all that one can really do is play a sort of sandbox game. Convoy re-combination will be a particularly challenging task: just look back at how much work that the signalling has involved, and the enormous number of subtle and tricky bugs each of which take many hours to find and fix: the convoy re-combination I estimate will be similar, but on a considerably larger scale, and touching a greater number of fundamental parts of the game.

As to multi-tile depots, that would be a good thing to have, but it would involve again very considerable and fundamental changes to the way that depots work, especially for spawning new vehicles, which would take a lot of work to implement and would not at this stage of Simutrans-Extended's development justify that time which could be spent on preparing the game for balancing. In economic terms, the cost of depots can encourage players to have no more than a realistic number of them, and it would be relatively easy to put a limit on the number of convoys that a depot can maintain at once, having the large/small distinction without a difference in the physical size.

[A.Badger]

openttd has depot maintenance and it's a bit of a pain because it adds a requirement into scheduling that doesn't match up with either factory and passenger generation or time to traverse a route.

In my openttd play-style, mitigating the pain is usually a matter of scheduling one (or more because route length sometimes exceeds how often a train needs to be maintained) or more depot stops as part of the route.  There is not a maintenance cost so too frequent maintenance does not have a detrimental effect on profits.  Time taken to maintain is basically the same as the train making any other stop so the primary consideration is just to place the depots in a convenient location along the tracks (usually near stations at either end of a linear route or at every single station).  Depots are not expensive to buy or maintain (I'm not sure if openttd even has maintenance fees for depots.... track and signals dominate the costs) so I often end up with a depot at every station and intermediate ones on very long routes.

One thing that is lacking in openttd is drive-through depots.  station layout can be optimized for through-put by having trains enter one side and leave the other but depots only have one entry and exit so there's always a portion of track that is bidirectional.

Another way that openttd makes this (and other scheduling where there may be a mismatch between travel time and readiness to depart) is having conditions within scheduling.  "If train is within 10% of refit time, go to depot, else skip to the next schedule entry".  (In non-depot related scheduling, it can also be used for cargo handling and other decision making "If Train has X% cargo, then go to station else skip to schedule entry #") The interface would need to be more complex with each component having separate refit needs but having conditionals probably becomes even more necessary for automation as well.

trying to think of other ways in which separate maintenance schedules for each component affects game play, in the real world, if a train pulled into a depot and only the locomotive needed to be maintained, wouldn't the depot just perform maintenance on the locomotive?  it seems like they'd either ignore the cars it is attached to or unhitch the locomotive from the cars inside the depot, service the locomotive, and then reattach the locomotive and send the convoy back out.  Seems like modelling that would be a time saver and ease automation as well.

[jamespetts]

Thank you for your feedback. I hope to find a system of depot visit maintenance that does not make it impossible or excessively difficult for players to have sensible schedules; what do you think of Andrew's idea as posted above?

I should note that there is no plan to have a specific cost associated with visiting depots: maintenance will be based on the number of kilometres travelled.

Conditional schedules are an interesting idea, but are likely to be tricky to implement and even trickier to make easily understandable to the user. If anyone would like to have a go at implementing these in Simutrans-Extended, I should be likely to incorporate such a patch if it worked reasonably well.

I am a little unclear about the last paragraph, in particular how you imagine that this would actually work in the game. Can you elaborate?

[A.Badger]

Ah, nevermind my last paragraph.  I see that I misread your plans on how full convoys being maintained should operate.  Your plan when there's a lack of automated convoy recombination seems to match with what I was thinking.

Conditional schedules aren't very tricky to make a gui for.  OpenTTD is quite easy to use.  They aren't great to maintain, though... For a programmer, it's a partial return to spaghetti code (If condition goto schedule entry X.  [the else is always to fall through to the next entry]).  The impact is made slightly better because the gotos are linked to an entry's id, not their visible number: when adding more entries, the gotos automatically update to continue pointing to the correct entry.

Coding of conditionals may not be too hard but depends on what assumptions the code already makes.  Basically, when a train leaves a station, it looks at the next entry in the schedule.  If it's a condition, it needs to evaluate the condition to decide where to go next.  So if the code already makes the information available that you want to allow conditions to address, things are easy.  If not, then there's some restructuring to do.  There may also  be work needed if the schedule's data structure is not flexible enough to hold entries for conditions in addition to entries for locations.

I'm trying to figure out the differences between your initial idea and Andrew's idea... If I understand what you were thinking, I may like yours better.  It sounds like with your idea, you can have a single depot anywhere on a route.  When the train passes the depot, if some number based on the availability percentage has been exceeded, then the train would need to go into maintenance otherwise it could continue on (the user could also set the train to maintain every time it passes the depot or some number in between if they wish).

One other thing... I realize reading this idea over again that overhaul is different from maintenance.  Instead of having running cost increase with time between overhauls, would it make more sense for availability percentage to go down (which would influence costs because it would increase the amount of time in which a train is out-of-service)? It feels like as a vehicle accumulates more miles, the parts wear and there's more need for repair (which would fall under maintenance) rather than a decrease in fuel economy or salaries paid to the staff manning the vehicles.

[jamespetts]

Thank you very much for your feedback: that is most helpful.

The trouble with the code in Simutrans is that it is not very modular: accessing the schedule is done in lots of different places all over the code at a fairly low level (in terms of the structure of the schedule); for example, the code that determines the service frequency to estimate the waiting time before actual waiting time data are available, the code to check whether a particular line calls at a particular stop for the purposes of routing, the code to check whether the next stop is within range all (separately) access the schedule's basic data directly in order to work. There is no definitive list of which things do this in the code, so it is hard to tell whether any change to the schedule code would be violating an implicit assumption somewhere.

Moreover, there is code which allows the schedule to be traversed forwards or backwards (to allow for automatic reversing of schedules), and, again, at present, there are different bits of this code that do essentially the same thing in different places for different functions, so any addition of conditional schedules would have to take account of this (both by actually checking the schedule's direction and by anticipating that the schedule may be traversed in either direction).

I am afraid that, over the years that I have been working on Simutrans-Extended and extending the code from Simutrans, I have copied the coding style from the Simutrans-Standard (often as it was some years ago before improvement), and copied in many places some of the weaknesses in the coding style from that original codebase (which were probably rather less serious weaknesses when that code was simpler in any event).

It would certainly be possible to implement conditional schedules, but I suspect that this would involve quite a lot of re-writing the schedule code to make it more modular. If anyone would like to do this, it would be a very helpful thing.

Edit: I realise that I replied only to the part relating to the scheduling code: my apologies.

My original idea was to have a specific depot on the schedule: having a specific depot in a schedule is already possible, but the vehicle will stay in the depot and the depot entry will be deleted from the schedule when the vehicle enters it. The idea of having an abstract call for a vehicle to visit any depot (is this what you meant?) would be more difficult to implement in the code, as it would be more different from the current schedule code, and would potentially add a whole layer of unpredictability for the player. The idea would be not for the availability percentage to determine when the vehicles need to go to the depots, but rather how long that they spend there when they do: the idea would be for the timing of going to the depots to be based on a fixed (and somewhat generous) distance interval.

In relation to an increase of running costs as against a reduction in the availability percentage as vehicles grow older, I suspect that the more realistic thing would be to have both (as more mechanics' time would be needed to maintain the vehicles as they got older, and likewise more spare parts and materials), but I wonder whether altering the availability percentage in this way would upset schedules in a way that would require constant attention by players in order to optimise, which in turn would make semi-unattended play (as in large, long network games) non-viable? If you can think of a way around this, however, I should be most interested.

[zook2]

Could you please elaborate these points for me:

"Because at present a convoy entering or leaving a depot triggers a re-run of the path explorer, this would have to be altered so as only to run the path explorer when entering a depot for storage, not for maintenance. The path explorer would ignore depot visits for the purpose of calculating routes."
I don't know what exactly the explorer does, or why that change is necessary.

"Further, convoys should be able to enter a state of layover at any stop, as set by the schedule: but this would require discharging all of the passengers/mail/cargo at that stop, and have a minimum dwell time for putting the vehicle into a state of layover. During a layover, no fixed maintenance costs would be charged."
I'm not sure I understand what the purpose of layovers would be, as opposed to refueling.

Also, I think a lot would depend on how the parameters for overhauls, availability, refueling etc. are actually being set in the pak. For example, a city bus that usually takes 2-3 minutes to load/unload at each stop shouldn't take 20 minutes to refuel, or it might block the stop for that time and cause serious traffic jams and disruptions in a tight network. Alternatively, the player would have to build a large number of choose-stops (if that's the term) for stops where refueling is required. Or you'd need to make refueling non-blocking.

[jamespetts]

Could you please elaborate these points for me:

"Because at present a convoy entering or leaving a depot triggers a re-run of the path explorer, this would have to be altered so as only to run the path explorer when entering a depot for storage, not for maintenance. The path explorer would ignore depot visits for the purpose of calculating routes."
I don't know what exactly the explorer does, or why that change is necessary.

The path explorer is the code, written by Knightly some time ago, which calculates the route that all passengers, mail and goods take to get from any stop to any stop. This is quite computationally intensive, so it is set to be run only when necessary. At present, a convoy entering a depot triggers the path explorer being re-run because it suggests that something has changed in the way in which the schedules are arranged. This will have to be altered when this new system is implemented.

"Further, convoys should be able to enter a state of layover at any stop, as set by the schedule: but this would require discharging all of the passengers/mail/cargo at that stop, and have a minimum dwell time for putting the vehicle into a state of layover. During a layover, no fixed maintenance costs would be charged."
I'm not sure I understand what the purpose of layovers would be, as opposed to refueling.

The concept of a layover is a state in which a convoy is dormant and accrues no fixed maintenance cost because it is not being attended by staff (e.g. a 'bus parked in the garage, etc.). When fixed maintenance costs are fully implemented in the pakset, it will be important to be able to have layover states in order to allow convoys/vehicles to remain dormant for periods without attracting considerable cost. There will have to be some restrictions on the layover state to prevent exploits (such as layovers at every stop for the duration of loading): a layover requiring no passengers/mail/goods be on the vehicle or being loaded should probably suffice for most purposes, although a delay for entering and leaving layover might also be necessary.

Also, I think a lot would depend on how the parameters for overhauls, availability, refueling etc. are actually being set in the pak. For example, a city bus that usually takes 2-3 minutes to load/unload at each stop shouldn't take 20 minutes to refuel, or it might block the stop for that time and cause serious traffic jams and disruptions in a tight network. Alternatively, the player would have to build a large number of choose-stops (if that's the term) for stops where refueling is required. Or you'd need to make refueling non-blocking.

Refuelling I imagine would take closer to 5 minutes for road vehicles, and there is a long-term plan to make all road vehicles non-blocking when they are stopped.

[Ves]

This is a really interesting topic, and I'm looking forward to see it in the game!
Am I making the right assumption that there are three levels of this:
Range = the max distance before the vehicle needs replenishing/fueling
Maintenance (distance) = the max distance before a minor maintenance must occur, i.e. Clean the vehicle, refill oil, check brakes, fill air in tires etc
Overhaul (distance) = the max distance before a major overhaul must occur, i.e. Replace engine, rust removal etc.

I too would think that having conditions is very (VERY) handy with a thing like this.
I wrote earlier that it would be nice to have on a per schedule basis, but I'm more and more convinced that a dedicated "vehicle maintenance window", a standalone window not bound to any vehicle, is the best way to go. Let me explain:

In the real world, (I assume) the vehicles are grouped more together on a per type basis than a per schedule basis. If the train to London and the train to Liverpool are copies of each other, the individual cars and loco of the London train would likely have more in common with their twin in the Liverpool train than with the other types of cars running in their own train in respect of maintenance needs. This will be especially true if vehicle recombination allows for physical sharing of cars between the two lines.

The vehicle maintenance window would be brought up by a button in the schedule, vehicle window, schedule window and maybe also from the menu bar and would look the following:
On the top, similar tabs as on the schedule window to select different means of transportation, including "all".
Below that, four fields of lists next to each other, the first being "groups", second being "schedules", third being "vehicle models" and fourth being "individual vehicles".
All these four fields would start with "all" so all individual vehicles can be made visible in the right most window.

The "groups" are groups of vehicle models/schedules/individual vehicles that the player can put together to ease modifying. Say you have a big bunch of kind of similar vehicles but they might be just a little different but not enough to justify individual maintenance schedules, you can put them in the same groups. If it is easier to put entire schedules in the same groups then that should be possible too.

The "schedules" field would show all the schedules that you are currently operating (if not filtered away by "groups").

The "vehicle models" are all different kinds of vehicles that you currently own (if not filtered by "groups" and "schedules"). It is not the actual vehicles but it groups together all vehicles of the same kind.

The last "individual vehicles" are the actual vehicles that you own. If the three previous fields shows "all" then all your vehicles will be shown in the last box.

All below settings are stored at the individual vehicles and the above sorting method is just to select the specific vehicles. Now that you can select precisely which vehicles to make corrections to, this should go underneath. If multiple vehicles are selected, the max/min displays the worst case:

* Display availability percentage
* Display range
* Display vehicle maximum travel distance/time before maintenance need (from vehicle dat.file)
* Set maximum travel distance before maintenance
* Display max years or distance to overhaul
* Set overhaul frequency (years or distance)
* set minimum km of wear before maintenance
* Display minimum maintenance duration from vehicle dat.file)
* display the age of the vehicle, if more than one, display the range (i.e. 4-9 years old)
* display the different costs associated with maintenance if more than one type of vehicle is selected, show both the worst case of the selection as well as the sum.
* Set wether the vehicle should "overhaul" to original condition or to an upgraded version if available.
* Specify which depots (if not any) that might be used to perform maintenance and overhaul.
* Set maintenance grouping
* possibly some more info/settings as well

When changing settings for a group of vehicles (i.e. a schedule with different vehicles), the vehicles should keep their settings that have been changed individually and only change the settings which are collectively set.

In the schedule it self, the range stops are calculated automatically but should be modifiable so I can change if I want another stop to be a range stop. Also I specify at which point/points in schedule where it should check if any of the vehicles operating the schedule needs to do any maintenance or overhauls. If, at the maintenance check, it finds that the entire convoy can make it to the next "maintenance check" it should proceed.
Also, being able to have several depots along the route to be able to perform the maintenance and overhauls would allow for some really long routes (one end of the map to the other).


Btw, the layover's, are they supposed to be performed in the depot or on a station?
Anyway, since that is a schedule thing and not a maintenance thing, it should belong to the schedule window.

Also, maybe consider the possibility to add conditional good loading, ie only load books at this stop, or only unloading at this stop in Y direction.

[jamespetts]

Thank you for the feedback.

The idea behind the specific outline that I gave in the opening post is to simplify the idea enough that it is a reasonable task to implement within a reasonable time given the very limited coding resources currently available to us. Additional features, such as conditional schedules and convoy recombination, are things that might be added later if and when they are practical - but it should be possible to get the game to balance without having to do all that work, and it is important to get the game to balance sooner rather than later, as, without proper balance, it really is only half a game. Once the game is balanced, hopefully it will attract considerably more players, some fraction of whom may in time themselves contribute content and code, so there is a definite strategy to proceeding in this way.

As to the vehicle manager window, this seems as though it would be a good idea in principle, albeit rather a lot of work to code; but if you and/or Andrew are able to do this, then it would certainly be a welcome addition. I wonder whether vehicle replacement could be linked to this display in some way, too?

As to layovers, the current plan is for these to occur in depots only until convoy re-combination is implemented.

As to conditional goods loading, that is an interesting idea, albeit quite distinct from this topic.

[Ves]

The conditional good loading suggestion was just in case the schedule window anyway was about to be recoded. Then that could at have been thought of and perhaps prepared.

I will see what I can accomplish!

[Bear789]

As to the shipyard, the plan is to add a feature whereby it will be necessary for vehicles regularly to visit depots

It's slightly off topic, but I'm really unsure about this bit. One of the reasons why I prefer Simutrans over OpenTTD is that it doesn't have the silly breakdowns, maintenance is abstracted as a cost. This is a good thing in a time scale in which a month passes in merely a few minutes. Breakdowns and maintenance/repair visits to the depots (even if low mainteinance does not cause breackdowns) in this time scale cause an amount of disruption to the normal operations that is massive compared to the real life conterpart, and is therefore highly unrealistic.

It's the trite and mildly frustrating issue of simulation games making rather mundane stuff tricky and harder than they should be because of the discepancy between the in-game time scale and the interactions time scale. Like in The Sims, where you have to either wake up at dawn or choose between peeing, showering or having breakfast because each of these things takes a whole hour; or a village of a dozen people in The Settlers needing an army of butchers or risk starvation every time the man goes to have a beer at the pub. Or indeed a gridlock that lasts half a year in TTD when a single vehicle breaks down. All these things require either abstraction (like the way it's currently handled in Simutrans), or a more realistic and slower time scale, plus tools to set up replacement vehicles/services, plus passengers/goods AI smart enough to figure that out (which seems rather hard to implement).

[jamespetts]

Bear - I have moved this post into the thread that discusses the feature on which you are commenting, as it is better to be here than to go off-topic in the post specifically about the range of small sailing ships.

I do suggest that you read the above discussion on this feature to understand in some detail how it is intended to work: it is very specifically intending to take account of the timescale (that is, the short timescale, measured in hours rather than months) with some precision and to use the timings as an important part of the simulation of realism.

[jamespetts]

The time has now come to move towards implementing this. I infer that Andrew Traviss has unfortunately not had time to do this, so I will have to start work on this myself (although any contribution from Andrew to this or any other feature would still be welcome).

The initial focus, it seems to me, needs to be on precisely how these features would impact scheduling, and a discussion of that (in some techincal detail) can be found here.

[jamespetts]

Work has started on this set of associated features in the vehicle-management branch on Github.

[Ves]

Hi James,
I will continue in this thread, so the other doesn’t get too long with mixed content and me shooting arrows in the mist.

Could you elaborate step by step, how do you imagine the player should create a schedule, create convoys, create the hash-tables, and then send the convoy out on the network?

In other words, what actions and decisions must the player take and do in order to get it working?

[jamespetts]

That is not entirely straightforward, as many of the steps are to be optional depending on what a player wants to do and how the player wants to do it. At minimum, a player would create a schedule in the same way as at present, but have a depot in the schedule with a conditional skip command which would not skip (causing the vehicle to enter the depot) whenever the vehicle needed maintaining (quite what counts as the vehicle needing maintaining I have yet to devise).

The hasthables to which you refer are to be the internal storage system for the planed convoy re-combination data, and any convoy re-combination would be optional.

If you wanted more specific information, perhaps you could let me know what specific that a player might do for which you want a step by step outline?

[Ves]

Ok, I will try to be more specific!
What would the steps for the player be to setup the following:

Stop A ==== Stop B ==== Stop C

One locomotive serves the line: Stop A <-> Stop B
Another locomotive serves the line: Stop B <-> Stop C
We want one car to travel all the way from Stop A to Stop C, and subsequently back again.

We do not consider overhaul or anything more advanced than the above.

[jamespetts]

The steps need not necessarily be followed in this exact order.

(1) Create the convoy in the depot for the A > B section.
(2) Create the schedule as normal for a line for the whole route.
(3) Create a new convoy consisting of only the locomotive for the A > C section at a depot at B.
(4) Set its schedule to a line consisting of be B depot > B.
(5) Set a conditional depart flag from B depot with a trigger of, e.g. 1 for the locomotive only convoy/line.
(6) Set a conditional trigger on arrival for the main convoy at B with the number 1 and the target of the line of the locomotive.
(7) Set the main convoy to have both a couple and uncouple flag at B
(8) Set the consist orders at B to comprise the train with the old locomotive detached and the new locomotive attached.
(9) Add a new line from B > B depot
(10) Set the uncouple target to this line with the unique entry ID for B so that the locomotive that detaches from the train goes to the depot after the train departs
(11) Set a conditional depart from the depot with this schedule with a trigger number of, e.g. 2.
(12) (The steps to repeat the process in reverse for replacing the locomotive for the B > A run should be able to be inferred from the above).

[Ves]

Thank you for the break down! I understand somethings better now, but other things i would still like some clarifications on:

(1) Create the convoy in the depot for the A > B section.

The "convoy" in this sense means both the first locomotive (A <-> B) as well as the car?

(2) Create the schedule as normal for a line for the whole route.

So create a schedule with these entries, as well as ticking the "reverse" tag:
Stop A
Stop B
Stop C

I call this schedule "Schedule 1"

(3) Create a new convoy consisting of only the locomotive for the A > C section at a depot at B.

Maybe it is just a mistype, but we did not want any locomotive to travel between A and C, only the car. Should I assume you mean ... consisting of only the locomotive for the B > C section ...?

(4) Set its schedule to a line consisting of be B depot > B.

Ok, so a second line is created "Schedule 2"

(5) Set a conditional depart flag from B depot with a trigger of, e.g. 1 for the locomotive only convoy/line.

Is the "1" just a name/number for the trigger? In which case, could I theoretical name it what I want (extension request )?
You say I set it from the depot entry of the schedule, so this would mean that the locomotive will in this case stay inside the depot until the trigger is released?
I call it "Trigger 1"

(6) Set a conditional trigger on arrival for the main convoy at B with the number 1 and the target of the line of the locomotive.

Great, so when this convoy arrives at the station, it releases Trigger 1. That makes the locomotive in the depot wake up and continue its schedule, out from the depot.
I assume the triggers are set in the schedules.

(7) Set the main convoy to have both a couple and uncouple flag at B

Again, this is set in the Schedule 1?

( Set the consist orders at B to comprise the train with the old locomotive detached and the new locomotive attached.

Here is one of the big questions: How should I acces the consist orders at B? via Schedule 1, Schedule 2, clicking on a button in the info window of station B to perhaps see all consist orders to be performed on this station?
I remember you talked about using the gui convoy assembler together with the consist orders, so I assume it is going to be a new window, separate from the schedule.

But asside from that, I understand that now the original convoy we created will be altered, so the locomotive traveling A-B is detached and the locomotive traveling B-C is attached. A new convoy will be formed, which is the detached locomotive, and the already existing convoy, consisting of only the B-C locomotive, will be terminated.

(9) Add a new line from B > B depot

Schedule 3. However, what differs this from Schedule 2? is it just the direction (towards the depot, instead of away from)?

(10) Set the uncouple target to this line with the unique entry ID for B so that the locomotive that detaches from the train goes to the depot after the train departs

You might have to elaborate this a bit more.
Is it in Schedule 3 we set Trigger 1? or with "unique entry ID" you mean something third?
I dont understand this instruction.

(11) Set a conditional depart from the depot with this schedule with a trigger number of, e.g. 2.

Sorry, but is this Schedule 3 again? Why does it need another trigger?

(12) (The steps to repeat the process in reverse for replacing the locomotive for the B > A run should be able to be inferred from the above).

Great! 

[jamespetts]

Thank you for the break down! I understand somethings better now, but other things i would still like some clarifications on:
The "convoy" in this sense means both the first locomotive (A <-> B) as well as the car?

Yes, indeed, the whole train in its A > B journey.

So create a schedule with these entries, as well as ticking the "reverse" tag:
Stop A
Stop B
Stop C

I call this schedule "Schedule 1"

You would not be able to use the reverse flag for this, as I cannot think of any sensible way of inferring what the reverse consist orders ought to be (this could get monumentally complex and extremely prone to error). Thus, when using consist orders, you would need to specify a schedule manually as
A
B
C
B

This is important, as the consist orders for the second B would be different to the consist orders for the first B, each of which would need to be specified independently.

Maybe it is just a mistype, but we did not want any locomotive to travel between A and C, only the car. Should I assume you mean ... consisting of only the locomotive for the B > C section ...?

Yes, my apologies: this was a typing error. I intended B > C section.

Ok, so a second line is created "Schedule 2"

Is the "1" just a name/number for the trigger? In which case, could I theoretical name it what I want (extension request :) )?

The 1 is the trigger number: this can be in the range 0 - 15. This needs to be a number as bitfields are used. In theory, this could be represented by a name in the UI - but this would have to be saved somewhere, and that would take a lot of data just for saving these names. A trigger number in the range 0 - 15 is not inherently hard to understand.

You say I set it from the depot entry of the schedule, so this would mean that the locomotive will in this case stay inside the depot until the trigger is released?

Yes, with the conditional depart flag.

I call it "Trigger 1"
Great, so when this convoy arrives at the station, it releases Trigger 1. That makes the locomotive in the depot wake up and continue its schedule, out from the depot.
I assume the triggers are set in the schedules.

Yes, indeed.

Again, this is set in the Schedule 1?

If by "schedule 1", you mean the schedule of the first convoy described, then yes.

Here is one of the big questions: How should I acces the consist orders at B? via Schedule 1, Schedule 2, clicking on a button in the info window of station B to perhaps see all consist orders to be performed on this station?
I remember you talked about using the gui convoy assembler together with the consist orders, so I assume it is going to be a new window, separate from the schedule.

I had not finalised a UI design, as I thought that it might be better to leave that to your discretion if you were doing the UI coding. There are various possibilities for this: one might access it from a button in the schedule window, or from a button in the convoy window (perhaps to replace the existing "Replace" button). The actual dialogue itself I imagine as being similar to the GUI convoy assembler dialogue, with graphics showing the final consist, and silhouetted graphics of a vehicle representing more abstract rules, the silhouetted graphic representing a currently available vehicle that matches all of the rules (currently available as in either available to buy or already in the player's fleet).

But asside from that, I understand that now the original convoy we created will be altered, so the locomotive traveling A-B is detached and the locomotive traveling B-C is attached. A new convoy will be formed, which is the detached locomotive, and the already existing convoy, consisting of only the B-C locomotive, will be terminated.

Yes, indeed.

Schedule 3. However, what differs this from Schedule 2? is it just the direction (towards the depot, instead of away from)?

This schedule would have a different trigger condition for departing from the depot than the other locomotive's schedule: it would be triggered to depart from the depot in the second instance of the main convoy arriving at stop B, whereas the other convoy would be triggered to depart on the first such instance.

You might have to elaborate this a bit more.
Is it in Schedule 3 we set Trigger 1? or with "unique entry ID" you mean something third?
I dont understand this instruction.

By instruction no. 10, I meant that the next stop in what you call schedule 3 is the depot, so that the detached locomotive heads to the depot after uncoupling.

Sorry, but is this Schedule 3 again? Why does it need another trigger?

Yes: as explained above, this A>B>depot>B>A locomotive needs to be triggered to leave the depot when the train enters B heading towards A, whereas the B>C>B>depot locomotive needs to be triggered to leave the depot when the train enters B heading towards C.

[Ves]

Thank you, it is getting much clearer!

So in order to perform this operation we need:
* Three schedules
* Two consist orders
* Three vehicles:
*  - Loco 1, for which we wish this route: A->B->Depot B->B->A
*  - Loco 2, for which we wish this route: Depot B->B->C->B->Depot B
*  - Car, for which we wish this route: A->B->C->B->A

The "Schedule 1":
Stop A
Stop B - Trigger 1 + Couple + Uncouple
Stop C
Stop B - Trigger 2 + Couple + Uncouple

The "Schedule 2":
Depot B - Conditional Depart (Trigger 1)
Stop B

The "Schedule 3":
Stop B
Depot B - Conditional Depart (Trigger 2)


"Consist order 1":
Detach "Loco 1" and assign to "Schedule 3"
Attach "Loco 2" from "Schedule 2"

"Consist order 2":
Detach "Loco 2" and assign to "Schedule 2"
Attach "Loco 1" from "Schedule 3"


Questions:

* Dont I need to set Couple flags for Schedule 2 and 3? Or will that just happen automatically due to it already been initiated by the Couple command from "Schedule 1"?

* Would it be possible to create this example "the other way round", with just two schedules? Something like:
Schedule 1:
Stop A
Stop B - Trigger 1 + Uncoupe
Depot B - Conditional Depart (Trigger 2)
Stop B - Couple

Schedule 2:
Stop C
Stop B - Trigger 2 + Uncouple
Depot B - Conditional Depart (Trigger 1)
Stop B - Couple

"Consist order 1":
Detach "car" from "Schedule 1" and attach to "Schedule 2"

"Consist order 2":
Detach "car" from "Schedule 2" and attach to "Schedule 1"


(I know the Schedule 2 is backwards, but since the convoys anyways travel in a circle, I kept it like that for ease of readines)

You would not be able to use the reverse flag for this, as I cannot think of any sensible way of inferring what the reverse consist orders ought to be (this could get monumentally complex and extremely prone to error). Thus, when using consist orders, you would need to specify a schedule manually as
A
B
C
B

This is important, as the consist orders for the second B would be different to the consist orders for the first B, each of which would need to be specified independently.

I would really hesitate to remove the "reverse" button! It is so extremely convenient, so its worth finding a replacement in this case. Perhaps, a fancy version of the Standard "copy backwads" or what it says, which would technically copy the entrances, but it would not be displayed in the schedule window other than an extra set of buttons appear, or something like that. Unticking the button would automatically delete the extra entries. Would something like that be possible?

...from a button in the convoy window (perhaps to replace the existing "Replace" button)...

This is one part that I still dont understand: We are not expected to manually change the order of the consists each time? I keep getting the impression that the consist orders are tied to the convoy, but I really cannot understand how that is supposed to work with convoys forming and splitting and forming again automatically in a complex layout. Since you easily can have 1000 of different vehicles on the same lines, you would need different consist orders dependent on what train is arriving at a station and what cars that particular train is made up from. If the orders are tied to the convoys, how will the consist orders survive?


What I would like is something like a "Consist order Center", where all consist orders are permanently listed, and where you can add, edit and remove orders. It would create an overview, so you can debug your network and find out why stuff might not be working.

[jamespetts]

Thank you, it is getting much clearer!

So in order to perform this operation we need:
* Three schedules
* Two consist orders
* Three vehicles:
*  - Loco 1, for which we wish this route: A->B->Depot B->B->A
*  - Loco 2, for which we wish this route: Depot B->B->C->B->Depot B
*  - Car, for which we wish this route: A->B->C->B->A

The "Schedule 1":
Stop A
Stop B - Trigger 1 + Couple + Uncouple
Stop C
Stop B - Trigger 2 + Couple + Uncouple

The "Schedule 2":
Depot B - Conditional Depart (Trigger 1)
Stop B

The "Schedule 3":
Stop B
Depot B - Conditional Depart (Trigger 2)

This is correct so far.

"Consist order 1":
Detach "Loco 1" and assign to "Schedule 3"
Attach "Loco 2" from "Schedule 2"

"Consist order 2":
Detach "Loco 2" and assign to "Schedule 2"
Attach "Loco 1" from "Schedule 3"

This is not how consist orders would work: they would not specify what vehicles are to be attached and detached: rather, they would specify the end-state of the convoy after all coupling/uncoupling, and what attaching/detaching, if any, needs to be done to reach that end state would be calculated automatically.

For example, suppose that we use the following symbols to have the following meanings:

L1: Locomotive no. 1
L2: Locomotive no. 2
Cb: Brake carriage
C: Non-brake carriage.

The train leaving A would have the following formation:

L1-Cb-C-C-C-Cb

The train leaving B would need to have the following formation:

L2-Cb-C-C-C-Cb

Thus, the consist order at B (heading towards C) would be:

L2-Cb-C-C-C-Cb

Each of the slots between the hyphens could be taken by a list of alternative vehicles, and/or a set of rules about what vehicles may or may not form part of the end-state convoy.

There would be no "attach" or "detach" data in a consist order.

Questions:

* Dont I need to set Couple flags for Schedule 2 and 3? Or will that just happen automatically due to it already been initiated by the Couple command from "Schedule 1"?

Yes, I think that you would need to set the couple flag in schedules 2 and 3 as well.

* Would it be possible to create this example "the other way round", with just two schedules? Something like:
Schedule 1:
Stop A
Stop B - Trigger 1 + Uncouple
Depot B - Conditional Depart (Trigger 2)
Stop B - Couple

Schedule 2:
Stop C
Stop B - Trigger 2 + Uncouple
Depot B - Conditional Depart (Trigger 1)
Stop B - Couple

"Consist order 1":
Detach "car" from "Schedule 1" and attach to "Schedule 2"

"Consist order 2":
Detach "car" from "Schedule 2" and attach to "Schedule 1"

(I know the Schedule 2 is backwards, but since the convoys anyways travel in a circle, I kept it like that for ease of readines)

I repeat what I wrote above about how consist orders are to work.

As to the remainder, something like this might work, but you would still need to specify at stop B that the carriages are to couple with a locomotive of schedule 2, or else the passengers on the train would have no way of knowing that the train continues to C, and would all get off at B (and the path explorer likewise would not treat this as a direct connexion between A and C).

I would really hesitate to remove the "reverse" button! It is so extremely convenient, so its worth finding a replacement in this case. Perhaps, a fancy version of the Standard "copy backwads" or what it says, which would technically copy the entrances, but it would not be displayed in the schedule window other than an extra set of buttons appear, or something like that. Unticking the button would automatically delete the extra entries. Would something like that be possible?

The idea is not to remove the "reverse" button; but it would only be able to be used when the schedule flags need to be the same for each stop in both directions (as each entry has only one set of flags; in this case, we need different flags at stop B on the outward than the return route). This should still allow the "reverse" button to be used in most cases of simple schedules (including 'bus schedules, for which it is especially useful).

This is one part that I still dont understand: We are not expected to manually change the order of the consists each time? I keep getting the impression that the consist orders are tied to the convoy, but I really cannot understand how that is supposed to work with convoys forming and splitting and forming again automatically in a complex layout. Since you easily can have 1000 of different vehicles on the same lines, you would need different consist orders dependent on what train is arriving at a station and what cars that particular train is made up from. If the orders are tied to the convoys, how will the consist orders survive?


What I would like is something like a "Consist order Center", where all consist orders are permanently listed, and where you can add, edit and remove orders. It would create an overview, so you can debug your network and find out why stuff might not be working.

Remember that where the button is in the UI is very different from where the actual data are stored. The idea is that consist orders are stored in both lines and convoys. In this case, there would be lines for schedules 1, 2 and 3, and so the consist orders would be retained in the lines. One might also want to add a consist order button somewhere in the line management window. Also, you may recall that, even without lines, setting an uncouple target convoy ID causes the schedule of that convoy to be copied to the uncoupled portion of the convoy. This should probably also include, not just the schedule, but the consist orders of the target convoy.

[Ves]

Ok, so the consist order only tells in which combination the convoy will be leaving the station. Where exactly do you then state what lines the detached vehicles should join? In the schedule entry for that particular stop?
In which case, can you enter multiple targets for a single schedule entry, so many cars can be detached and go to different lines?

I was thinking, now that ACarlotti has come around, perhaps he or she would like to participate in the creation of the GUI?

[ACarlotti]

Probably not 'creation' as such for now, but I'll quite happily take your ideas/code and throw some suggestions/fixes/improvements at them.

At present I'm primarily intending to fix existing bugs (including those that I discover while reading the code), or make other minor improvements, and in doing so learn more about the codebase. Then maybe at some point in the future I'll start creating new stuff. But I suppose it largely depends where I end up on a random walk through the codebase.

[jamespetts]

Ves - to answer your question, the detached vehicles will either be loose vehicles if no target line or convoy be specified, or will be formed into a new convoy with the schedule or line of the line or convoy specified in the target_id_uncouple data member in the schedule entry corresponding to the relevant consist orders if this be a valid non-zero value.

[Ves]

Ok, so you can specify multiple target_id_uncouple's?

[jamespetts]

Ok, so you can specify multiple target_id_uncouple's?

No, as there is only the one variable. I do not think it practical to have a vector in a schedule_entry_t object, and in any event, specifying which vehicles would be assigned to which convoys/lines would hugely increase the complexity.

The better thing to do would be to have the first stop on the new schedule one which itself has an uncouple command, and so one, so that one can effectively cascade the commands.

[Ves]

Hmm, ok but will this not be overly complex for players? So the convoy dropping of multiple cars should assign one schedule to all those cars, a schedule where the first entry is the same stop as where it is currently located and which also has a drop command, which states “this” many cars are to be dropped of into a new convoy and have another schedule, again with “this” stop as their first entry, and with another couple command etc. That could potentially be a lot of “ghost schedules”, since you might very well be in the situation that the different cars are to be picked up by other lines, which can just have a couple command at that particular station, rendering all these schedules to just take the consist apart with a feeling of “work around” for the player. I’m sorry, but I don’t think that is less confusing than having, say an array of target schedules per schedule entry, or some other means where the player can specify directly what should happen to particular vehicles. And then we are not even talking about the complexity and micromanagement it requires just for the player to maintain all these potential ghost lines. Imagine having to alter the consist orders of 10 lines, just because it is the “last” line in the row that needs some alteration. 

Are you sure there is not a more flexible way?

[jamespetts]

Can you think of a practical example of where a player might need to do this which: (1) cannot be done by dropping off loose vehicles and leaving other convoys to attach to them; and (2) is likely to be encountered sufficiently frequently so as to justify the very significant amount of work and potentially performance degradation that such a change is likely to engender?

[Ves]

Can you think of a practical example of where a player might need to do this which: (1) cannot be done by dropping off loose vehicles and leaving other convoys to attach to them; and (2) is likely to be encountered sufficiently frequently so as to justify the very significant amount of work and potentially performance degradation that such a change is likely to engender?

But, Im really puzzled now. Are you saying that it is indeed possible to do this setup:

Lines:
Stop X ==== Stop Y

Stop Y ==== Stop A
Stop Y ==== Stop B
Stop Y ==== Stop C

You want this train to travel between Stop X and Stop Y:
L1-C1-C2-C3

At stop Y you want to disconnect all cars and attach one new locomotor to each:
L2-C1
L3-C2
L4-C3

If the schedule of the line traveling between Stop X and Stop Y can only specify one target schedule/line at Y, how can this be done?
Remember that there are good in the cars, so they need to go to the correct stops.

The only way I can think of is if you specify the same stop multiple times in the schedule, and specify a different line target to each entry, but that too seems to be walking across the river for water...