Author Topic: Balance discussion: cost (maintenance, convoy re-combination and others)  (Read 889 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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.

Offline 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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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.
« Last Edit: April 18, 2017, 03:41:04 AM by zook2 »

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.

Quote
"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.

Quote
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline Ves

Balance discussion: cost (maintenance, convoy re-combination and others)
« Reply #12 on: April 18, 2017, 01:38:48 PM »
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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 15419
  • Total likes: 376
  • Helpful: 171
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
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.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Offline 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! :)