Servicing behavior
Moderator: OpenTTD Developers
Servicing behavior
There are some problems with the current servicing system in OpenTTD. First I'll describe how it works, then some of the possible solutions and finally I'd like to hear some ideas about how it should work.
How it currently works
There are 5 global settings, and 1 per vehicle setting. In 0.7.x the global settings are really global, in trunk the global settings are actually per-company settings. These global settings are:
servint_ispercent - If this is true, then the other settings are a percentage of the maximum reliability. If this is false, the other settings are a number of days.
servint_trains - The default servicing interval for trains.
servint_roadveh - The default servicing interval for road vehicles.
servint_aircraft - The default servicing interval for aircraft.
servint_ships - The default servicing interval for ships.
When a new vehicle is build, the servicing interval for that vehicles is set to the default for that vehicles type.
Vehicles without a service order
I'll explain this for trains, but the process for other vehicles types is similar. As soon as a train reached any junction, it'll check whether it needs servicing. This depends on the global servint_ispercent setting. When it's true, it checks if the current reliability is lower then the maximum reliability * servicing interval. If it is, then the train needs servicing. If the servint_ispercent setting is false, it checks the number of days since the last servicing. If that's higher then the servicing interval, the train needs servicing. If a train needs servicing, it'll look for a nearby depot.
Vehicles with at least one service order
As soon as the service order is reached, it'll check whether the train needs servicing. That check is the same as described above. If it needs servicing, it goes to that depot, otherwise, it'll carry on with the next order.
The problems
The main problem is that servint_ispercent is a global (per-company) setting. You can't give one vehicle a servicing interval of 200 days and tell another to service when their reliability is less then 80% of the max. reliability for that engine. (Then there is also a bug that values can go out-of-range when changing the global setting from days to percent, but that's not important now).
Possible solutions
Several solution are possible:
Solution 1: Store servint_ispercent per vehicle, so switching the global setting doesn't invalidate the vehicle settings. We'll also need a new button in the vehicle details window to switch this setting per-vehicle.
Solution 2: Remove the servint_ispercent setting and give every vehicle a servint_days and servint_percent, so they go so servicing when either the nr. of days is reached or when their reliability is too low.
Solution 3: Simplify the settings by removing either the option to set it in days or as percent of max reliability.
Some other servicing-related ideas
- It might be nice to change the servicing settings for all vehicles in a group or for all vehicles with shared orders.
- Your idea here ...
What I'd like to hear from you
- Do you change the servicing settings at all or do you just leave them to the default?
- What is the value of servint_ispercentage? Is it on or off?
- What is your preferred solution? (Other solution are also welcome of course)
How it currently works
There are 5 global settings, and 1 per vehicle setting. In 0.7.x the global settings are really global, in trunk the global settings are actually per-company settings. These global settings are:
servint_ispercent - If this is true, then the other settings are a percentage of the maximum reliability. If this is false, the other settings are a number of days.
servint_trains - The default servicing interval for trains.
servint_roadveh - The default servicing interval for road vehicles.
servint_aircraft - The default servicing interval for aircraft.
servint_ships - The default servicing interval for ships.
When a new vehicle is build, the servicing interval for that vehicles is set to the default for that vehicles type.
Vehicles without a service order
I'll explain this for trains, but the process for other vehicles types is similar. As soon as a train reached any junction, it'll check whether it needs servicing. This depends on the global servint_ispercent setting. When it's true, it checks if the current reliability is lower then the maximum reliability * servicing interval. If it is, then the train needs servicing. If the servint_ispercent setting is false, it checks the number of days since the last servicing. If that's higher then the servicing interval, the train needs servicing. If a train needs servicing, it'll look for a nearby depot.
Vehicles with at least one service order
As soon as the service order is reached, it'll check whether the train needs servicing. That check is the same as described above. If it needs servicing, it goes to that depot, otherwise, it'll carry on with the next order.
The problems
The main problem is that servint_ispercent is a global (per-company) setting. You can't give one vehicle a servicing interval of 200 days and tell another to service when their reliability is less then 80% of the max. reliability for that engine. (Then there is also a bug that values can go out-of-range when changing the global setting from days to percent, but that's not important now).
Possible solutions
Several solution are possible:
Solution 1: Store servint_ispercent per vehicle, so switching the global setting doesn't invalidate the vehicle settings. We'll also need a new button in the vehicle details window to switch this setting per-vehicle.
Solution 2: Remove the servint_ispercent setting and give every vehicle a servint_days and servint_percent, so they go so servicing when either the nr. of days is reached or when their reliability is too low.
Solution 3: Simplify the settings by removing either the option to set it in days or as percent of max reliability.
Some other servicing-related ideas
- It might be nice to change the servicing settings for all vehicles in a group or for all vehicles with shared orders.
- Your idea here ...
What I'd like to hear from you
- Do you change the servicing settings at all or do you just leave them to the default?
- What is the value of servint_ispercentage? Is it on or off?
- What is your preferred solution? (Other solution are also welcome of course)
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: Servicing behavior
I don't play often with breakdowns. If I do, though, I adjust my servicing settings and play with a service interval in days and give explicit service orders. But I don't want to argue that the percentage setting is useless at all, so I prefer solution 2Yexo wrote:Solution 1: Store servint_ispercent per vehicle, so switching the global setting doesn't invalidate the vehicle settings. We'll also need a new button in the vehicle details window to switch this setting per-vehicle.
Solution 2: Remove the servint_ispercent setting and give every vehicle a servint_days and servint_percent, so they go so servicing when either the nr. of days is reached or when their reliability is too low.
Solution 3: Simplify the settings by removing either the option to set it in days or as percent of max reliability.
Some other servicing-related ideas
- It might be nice to change the servicing settings for all vehicles in a group or for all vehicles with shared orders.
What I'd like to hear from you
- Do you change the servicing settings at all or do you just leave them to the default?
- What is the value of servint_ispercentage? Is it on or off?
- What is your preferred solution? (Other solution are also welcome of course)
Given the different reliabilities and thus servicing needs for different vehicles it makes IMO perfect sense to integrate that with the grouping and shared orders of vehicles. Having to adjust that for every vehicle will be a pain.
On a not 100% related note: this described bigger flexibility in vehicle management options would make a more sophisticated vehicle management interface desirable in the form of nested groups as described here by Brianetta some time ago: http://www.tt-forums.net/viewtopic.php?p=728175#p728175 . Else it will be easy to lose track of what vehicle does what...
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: Servicing behavior
I usually change them to 365 days for each vehicle type. I do usually play without breakdowns though, but still like to have my vehicles visit the depot every now and then. That's where the R-word comes into play: when serviced regularly in real life, vehicles don't break down as often as the lowest breakdown setting in OpenTTD (which is still way to often for my flavour).Yexo wrote:- Do you change the servicing settings at all or do you just leave them to the default?
That be off.Yexo wrote:What is the value of servint_ispercentage? Is it on or off?
From the available options, I'd pick number 2. I'd only use it to its full extent if the breakdown system gets revised as well in order to make the number of breakdowns more user-friendly and therefore more realistic. I have to do some ingame-tests to see how I would like the breakdown system to be revised before I can do any suggestions on that particular topic. But that's something for a different topic.Yexo wrote:What is your preferred solution?
Something else related-but-not-entirely-on-topic:
When a train has reserved a path past a depot but hasn't passed the depot yet, it cannot find that particular depot when clicking on the goto depot button. Would it be possible to change that behaviour so that trains can revise their chosen path when the depot-button is clicked so that it will actually find a depot along a reserved path? Ofcourse it should only change it's reservation if it's safe to do so. Otherwise it may continue to the next depot.
Re: Servicing behavior
I'm still using the default TTD system for this (servicing periods are in days for the all vihicles)... Breakdowns are always on... Servicing orders aren't used at all...
Percentage feature is useless (IMHO)...
If I try to set the different servicing periods (in days or in percentage) for the every vihicle independently (if I'll have them much more then 500), then it will give me a really big headache, even if I'll do it in the different periods of time during the game...
For me: the global setting is the number one choice, in other words: this thing don't needs to be changed (IMHO)...
BTW, Yexo, I've send e-mail with those saves...
Percentage feature is useless (IMHO)...
If I try to set the different servicing periods (in days or in percentage) for the every vihicle independently (if I'll have them much more then 500), then it will give me a really big headache, even if I'll do it in the different periods of time during the game...
For me: the global setting is the number one choice, in other words: this thing don't needs to be changed (IMHO)...
BTW, Yexo, I've send e-mail with those saves...
Life is the moving train on the tracks...
(Transport Tycoon Deluxe for the real)
(Transport Tycoon Deluxe for the real)
Re: Servicing behavior
I always play with breakdowns and no service orders, and sometimes change the day setting to 100-120 days instead of the default 150 days for a few trains.
I have never played with percentages, and see no reason to, so that setting can be removed entirely as far as I am concerned.
I have never played with percentages, and see no reason to, so that setting can be removed entirely as far as I am concerned.
Re: Servicing behavior
My two biggest irritations with breakdowns.
1) Has been covered elsewhere, I think - but the fact that multiple units/multiple headed trains have the same reliability as a single locomotive. A train with more than one power car/loco should really continue (possibly at reduced speed, or perhaps just reduced power would make more sense) and head for servicing soon. I'm not sure how this would work on a GRF by GRF basis - but shouldn't a triple-car DMU be able to continue with 2/3 power if one engine goes? Of course, some breakdowns should be as normal - not everything is engine based.
2) My biggest peeve, if I happen to get a traffic jam the reliability of all trains slowly reduces. By the time I clear it, every single train starts to break down - taking forever to unblock and causing secondary jams further out. Perhaps a minimum reliability would help, or a minimum distance between breakdowns.
1) Has been covered elsewhere, I think - but the fact that multiple units/multiple headed trains have the same reliability as a single locomotive. A train with more than one power car/loco should really continue (possibly at reduced speed, or perhaps just reduced power would make more sense) and head for servicing soon. I'm not sure how this would work on a GRF by GRF basis - but shouldn't a triple-car DMU be able to continue with 2/3 power if one engine goes? Of course, some breakdowns should be as normal - not everything is engine based.
2) My biggest peeve, if I happen to get a traffic jam the reliability of all trains slowly reduces. By the time I clear it, every single train starts to break down - taking forever to unblock and causing secondary jams further out. Perhaps a minimum reliability would help, or a minimum distance between breakdowns.
Jon
- caveatemptor
- Route Supervisor
- Posts: 432
- Joined: 12 Apr 2009 20:38
Re: Servicing behavior
This is definitely a good point IMO. The DMU-loco distinction should be reflected in the reliability system. The particular solution put forward by audigex is a good idea; another less accurate but simpler idea (I don't know if OTTD development subscribes to the KISS principle) would simply be to give DMUs more reliability than locos.1) Has been covered elsewhere, I think - but the fact that multiple units/multiple headed trains have the same reliability as a single locomotive. A train with more than one power car/loco should really continue (possibly at reduced speed, or perhaps just reduced power would make more sense) and head for servicing soon. I'm not sure how this would work on a GRF by GRF basis - but shouldn't a triple-car DMU be able to continue with 2/3 power if one engine goes? Of course, some breakdowns should be as normal - not everything is engine based.
Re: Servicing behavior
it's off topic here, though, as this is about servicing, not about breakdowns.
anyway, i generally play without breakdowns and servicing...
anyway, i generally play without breakdowns and servicing...
Re: Servicing behavior
The OP does ask for "servicing related" ideas - breakdowns are certainly related to servicing. If it's not relevant, it can easily be ignored 

Jon
Re: Servicing behavior
Servicing is only relevant if playing with breakdowns, which i don't. However, breakdowns would be challenging (instead of just annoying) if servicing were handled better IMO. Here is one player's thoughts on the matter (both perfectly relevant and slightly irrelevant).
1. Vehicles should run based on something we could call Maintenance Level, where performance is based on when was the last time it was serviced in relation to how often it SHOULD be serviced (i guess that's the same thing as Reliability
). I'd rather see this on a vehicle type basis (so that newer models may have higher reliability and will need servicing less times (per year for example) than older models.
2. When service time isn't met, reliability goes down and vehicle performance deteriorates, as audigex and many others have suggested. Perhaps travelling speed or acceleration time is reduced, or load/unload times are increased, or capacity is diminished, depending on the strengths of the given model. I would rather see the .grf author decide this penalty, but in lieu of the difficulty of that implementation, it could be hard-coded based either on year or vehicle type (train rather than plane).
3. Only when servicing is REALLY ignored, then they start breaking down and causing problems for traffic flow. This is where autorenew becomes important for HUGE transport fleets.
If breakdowns were handled better, i'd go for solution 2. But you didn't tell us Yexo what the pro's and con's of each solution is. Since i don't normally play with breakdowns (and servicing, since there's no penalty for low reliability), i admit to some short-sightedness on the effects of each choice.
1. Vehicles should run based on something we could call Maintenance Level, where performance is based on when was the last time it was serviced in relation to how often it SHOULD be serviced (i guess that's the same thing as Reliability

2. When service time isn't met, reliability goes down and vehicle performance deteriorates, as audigex and many others have suggested. Perhaps travelling speed or acceleration time is reduced, or load/unload times are increased, or capacity is diminished, depending on the strengths of the given model. I would rather see the .grf author decide this penalty, but in lieu of the difficulty of that implementation, it could be hard-coded based either on year or vehicle type (train rather than plane).
3. Only when servicing is REALLY ignored, then they start breaking down and causing problems for traffic flow. This is where autorenew becomes important for HUGE transport fleets.
If breakdowns were handled better, i'd go for solution 2. But you didn't tell us Yexo what the pro's and con's of each solution is. Since i don't normally play with breakdowns (and servicing, since there's no penalty for low reliability), i admit to some short-sightedness on the effects of each choice.
Re: Servicing behavior
Thanks for all the response so far. Even though I haven't replied earlier, I've been reading every reply carefully. To avoid repeating myself, I'll try to answer each point once, even though multiple people may have written approximately the same thing. So far the outcome seems to be that nobody uses the servint_ispercent setting (everybody specifies the settings in days), but at the same time nobody wants to remove that feature.
About the reactions from audigex, caveatemptor and (part of) SirXavius: While there are some very valid points, my reaction is the same as for above, I'm not trying to change the breakdown system now. I do agree that would be nice, but it's a lot of work to figure out a system with enough flexibility that enough people like. Maybe I'll try to do so someday, but for now I have other interesting projects.
As for the effects of solution 1 and 2: The current string in the vehicle details window is either "Servicing interval: xx%" or "Servicing interval: xx days".
With solution 1 there would be the same strings, but next to that a button you can use to switch from percent to days and back.
With solution 2 there would be a string like: "Servicing interval: xx% or yy days", with an extra set of buttons so you can increase/decrease both xx% and yy days.
It is certainly a good idea to create a more flexible interface, but it's not really in the scope of what I'm trying to do now (fixing the servicing settings).planetmaker wrote:On a not 100% related note: this described bigger flexibility in vehicle management options would make a more sophisticated vehicle management interface desirable in the form of nested groups as described here by Brianetta some time ago: http://www.tt-forums.net/viewtopic.php?p=728175#p728175 . Else it will be easy to lose track of what vehicle does what...
Same as above, the breakdown system may also need an overhaul to allow for more settings (as even reduces gives a lot of breakdowns), but (as you already say), that too is out of scope now.FooBar wrote:...I'd only use it to its full extent if the breakdown system gets revised as well in order to make the number of breakdowns more user-friendly and therefore more realistic. I have to do some ingame-tests to see how I would like the breakdown system to be revised before I can do any suggestions on that particular topic. But that's something for a different topic.
It's actually not really related, it might be best to open a feature request / bug report at bugs.openttd.org, so it'll go to the right people (michi_cc probably).Something else related-but-not-entirely-on-topic:
When a train has reserved a path past a depot but hasn't passed the depot yet, it cannot find that particular depot when clicking on the goto depot button. Would it be possible to change that behaviour so that trains can revise their chosen path when the depot-button is clicked so that it will actually find a depot along a reserved path? Ofcourse it should only change it's reservation if it's safe to do so. Otherwise it may continue to the next depot.
About the reactions from audigex, caveatemptor and (part of) SirXavius: While there are some very valid points, my reaction is the same as for above, I'm not trying to change the breakdown system now. I do agree that would be nice, but it's a lot of work to figure out a system with enough flexibility that enough people like. Maybe I'll try to do so someday, but for now I have other interesting projects.
Pros/cons are hard to give. The only con is for solution 3: it removes a previously usable option.SirXavius wrote:If breakdowns were handled better, i'd go for solution 2. But you didn't tell us Yexo what the pro's and con's of each solution is. Since i don't normally play with breakdowns (and servicing, since there's no penalty for low reliability), i admit to some short-sightedness on the effects of each choice.
As for the effects of solution 1 and 2: The current string in the vehicle details window is either "Servicing interval: xx%" or "Servicing interval: xx days".
With solution 1 there would be the same strings, but next to that a button you can use to switch from percent to days and back.
With solution 2 there would be a string like: "Servicing interval: xx% or yy days", with an extra set of buttons so you can increase/decrease both xx% and yy days.
Re: Servicing behavior
When playing breakdowns (occasionally) I use percentages 
It makes more sense to me to have a train which is at 100% "health" so to speak, and as that gets lower it's more likely to break down.
SirXavious - I think lack of accelleration would come under a loss of power/lowered max speed.
I, for one, have never been on a train which has just broken down in the middle of the tracks (although I've seen it happen) - but plenty of times I've been on one which has continued at reduced speed or stopped at the next station. Next station has the advantage that many stations allow more than one train in each direction, eg mine often have 2 in each direction (at least one dedicated, and usually one or more bi-directional... so they can get in the way without destroying traffic flow. I think for most people their objection to breakdowns is the whole "dead stop, and throw out smoke" system in place from the original - OTTD has grown out of that, I think.

It makes more sense to me to have a train which is at 100% "health" so to speak, and as that gets lower it's more likely to break down.
SirXavious - I think lack of accelleration would come under a loss of power/lowered max speed.
I, for one, have never been on a train which has just broken down in the middle of the tracks (although I've seen it happen) - but plenty of times I've been on one which has continued at reduced speed or stopped at the next station. Next station has the advantage that many stations allow more than one train in each direction, eg mine often have 2 in each direction (at least one dedicated, and usually one or more bi-directional... so they can get in the way without destroying traffic flow. I think for most people their objection to breakdowns is the whole "dead stop, and throw out smoke" system in place from the original - OTTD has grown out of that, I think.
Jon
- caveatemptor
- Route Supervisor
- Posts: 432
- Joined: 12 Apr 2009 20:38
Re: Servicing behavior
I agree that it "makes sense" that services would be based on health rather than timing, but what makes less sense IMO is the idea of the health of the vehicle being known without a service. Of course a lot of wear and tear would be visible or easily discoverable by the driver of some other member of staff, but I would imagine that a lot of wear which could bring down reliability would be latent and only discoverable by a service (that is, after all, the function of a service; to find out what is wrong AND to fix it). I don't know how it works with trains in real life but I presume services are based on time rather than health. Indeed, that's how it works with cars; the mechanic won't tell you to bring your car back for a service when it is 40% reliable. So in that way it makes more sense, to me anyway, to use time rather than reliability.audigex wrote:When playing breakdowns (occasionally) I use percentages
It makes more sense to me to have a train which is at 100% "health" so to speak, and as that gets lower it's more likely to break down.
Now I know there are issues with basing gameplay on realism. Realism is not a necessary aim of the game but some people do like to play games which correspond more with reality, and my guess is that if you are playing with breakdowns, and particularly if you are suggesting some of the improvements that have been suggested here, a game which corresponds in some way with the reality of train maintenance favourable.
Re: Servicing behavior
Some very valid points, good sir.
Firstly - I'm not that bothered if I can "see" the 'health' (totally the wrong word still, but you know what I mean), but I'd suggest service intervals should be much longer and "problem" breakdowns do occur - x train has lost power to one axle, Y train's air conditioning/heating has failed (time of day/year based) and it has to stop at the next station. These sorts of things should happen randomly, but much more likely as the time between services increases.
My main point is that breakdowns should be fewer and further between, and for once I think much closer to realism is the answer - trains have a quick check over every x0,000 miles, a service every x00,000 and a massive service ever x,000,000 miles (or something along that sort of scale) - working out as perhaps a check every few weeks taking an hour or two, a service every 6 months perhaps, and a major service every 5/10 years. My point being that the service isn't daily, and an TTD journey can take upwards of 3 months... so relatively speaking, servicing every 300 days is frustrating, you either build it into each timetable rotation or let it screw up your ordering every 3/4 journeys.
Firstly - I'm not that bothered if I can "see" the 'health' (totally the wrong word still, but you know what I mean), but I'd suggest service intervals should be much longer and "problem" breakdowns do occur - x train has lost power to one axle, Y train's air conditioning/heating has failed (time of day/year based) and it has to stop at the next station. These sorts of things should happen randomly, but much more likely as the time between services increases.
My main point is that breakdowns should be fewer and further between, and for once I think much closer to realism is the answer - trains have a quick check over every x0,000 miles, a service every x00,000 and a massive service ever x,000,000 miles (or something along that sort of scale) - working out as perhaps a check every few weeks taking an hour or two, a service every 6 months perhaps, and a major service every 5/10 years. My point being that the service isn't daily, and an TTD journey can take upwards of 3 months... so relatively speaking, servicing every 300 days is frustrating, you either build it into each timetable rotation or let it screw up your ordering every 3/4 journeys.
Jon
Re: Servicing behavior
As I read from the previous posts, I don't think the real problem is servicing. The problem is the impact of servicing - breakdowns.
Instead of breakdowns, I would like to have increased running cost for vehicles with service overdue. This way I still have to challenge of servicing without the annoyances of chainbreakdowns and long trains breaking down while pulling out of depot (blocking the depot).
Instead of breakdowns, I would like to have increased running cost for vehicles with service overdue. This way I still have to challenge of servicing without the annoyances of chainbreakdowns and long trains breaking down while pulling out of depot (blocking the depot).
Re: Servicing behavior
I play without breakdowns, they happen way too often even at the lowest setting. However, there is a reliability for each vehicle, and I don't like the idea of ignoring that when buying one, since it does make things more interesting and balanced. This is where I found the percent servicing to be useful. I calculated that trains lose about 45% reliability / year. So, I put servicing for trains at 45%. That means a train with 100% reliability will service once a year, while a train with 50% will service twice a year. Less reliability means the train will visit the depot for servicing more often. Road vehicles lose about 70% reliability / year, so I put 35% servicing meaning a 100% reliable bus will visit the depot twice a year for servicing, while a 50% one will visit it 4 times.
So, I hate breakdowns but I don't want to lose the reliability factor of the vehicles. Percent servicing offers me a way to play with no-breakdowns without ignoring the reliability totally. It's not the perfect solution but it works for me. Just my 2 cents
So, I hate breakdowns but I don't want to lose the reliability factor of the vehicles. Percent servicing offers me a way to play with no-breakdowns without ignoring the reliability totally. It's not the perfect solution but it works for me. Just my 2 cents

Re: Servicing behavior
I play with breakdowns on also. Like other folks, I wish there was a lower setting.
For reliable vehicles, I use a "service at" order when they are passing the depot anyway. For less reliable vehicles, or vehicles that are on "wait for full load" I use a "go to depot" order, again when they pass the depot anyway. Whenever possible I service when the vehicle is empty.
For passenger trains, I use the following:
Go to A
Go to B (no loading)
Go to depot
Go to B
That way the passengers aren't cooling their heels onboard the train while the engine is being serviced.
Reliability is a big factor in my decisions to buy a vehicle. I usually play with either UKRS or NARS2. On a single-track, single-train line from a mine to a transfer point, I don't worry so much about reliability- just buy the cheapest horsepower that will do the job. Yeah, I know, the stupid mine owners love to see shiny new high speed trains for some reason. But on a busy main line, I try to keep reliability as high as possilbe. Sometimes, I will even use "go to depot"orders at both ends of a long run.
Road vehicles are also an issue with reliability- I play with eGRVTS, or occasionally the HOVs UK bus set and default vehilces (plus the Heavy Equipment set). Again, do I upgrade those trucks or not? How reliabile is the new one vs. speed and capacity?
For reliable vehicles, I use a "service at" order when they are passing the depot anyway. For less reliable vehicles, or vehicles that are on "wait for full load" I use a "go to depot" order, again when they pass the depot anyway. Whenever possible I service when the vehicle is empty.
For passenger trains, I use the following:
Go to A
Go to B (no loading)
Go to depot
Go to B
That way the passengers aren't cooling their heels onboard the train while the engine is being serviced.
Reliability is a big factor in my decisions to buy a vehicle. I usually play with either UKRS or NARS2. On a single-track, single-train line from a mine to a transfer point, I don't worry so much about reliability- just buy the cheapest horsepower that will do the job. Yeah, I know, the stupid mine owners love to see shiny new high speed trains for some reason. But on a busy main line, I try to keep reliability as high as possilbe. Sometimes, I will even use "go to depot"orders at both ends of a long run.
Road vehicles are also an issue with reliability- I play with eGRVTS, or occasionally the HOVs UK bus set and default vehilces (plus the Heavy Equipment set). Again, do I upgrade those trucks or not? How reliabile is the new one vs. speed and capacity?
Who is John Galt?
Re: Servicing behavior
ostlandr wrote:Reliability is a big factor in my decisions to buy a vehicle.
What?ostlandr wrote:I don't worry so much about reliability

Re: Servicing behavior
"On a single-track, single-train line from a mine to a transfer point, I don't worry so much about reliability."
If the only train on one of these feeder branches breaks down, it doesn't tie up the main line and delay those crack passenger trains and fast freights.
If the only train on one of these feeder branches breaks down, it doesn't tie up the main line and delay those crack passenger trains and fast freights.
FooBar wrote:ostlandr wrote:Reliability is a big factor in my decisions to buy a vehicle.What?ostlandr wrote:I don't worry so much about reliability
Who is John Galt?
Re: Servicing behavior
I leave servicing interval at default values (been used to it since - oh I don't know when (TTO)).
Therefore the servint_ispercent is OFF.
My preferred solution is the way things are now, because anyone can set per-vehicle service intervals quite efficiently through the use of conditional orders. I've tested it on some servers with servicing set to OFF and no breakdowns (I like my vehicles serviced regularly) and it works sufficiently.
Therefore in my opinion there is no need for any complication/overhauling of the service subsystem.
Example of one of those conditional orders for a passenger train (with global servint at default and ispercent at OFF):
1: Go to Oranienfeld Central,
2: Go to Fuerstendorf,
3: Jump to order 1 when Reliability is more than 40,
4: Go to Freidorf Train Depot.
Therefore the servint_ispercent is OFF.
My preferred solution is the way things are now, because anyone can set per-vehicle service intervals quite efficiently through the use of conditional orders. I've tested it on some servers with servicing set to OFF and no breakdowns (I like my vehicles serviced regularly) and it works sufficiently.
Therefore in my opinion there is no need for any complication/overhauling of the service subsystem.
Example of one of those conditional orders for a passenger train (with global servint at default and ispercent at OFF):
1: Go to Oranienfeld Central,
2: Go to Fuerstendorf,
3: Jump to order 1 when Reliability is more than 40,
4: Go to Freidorf Train Depot.
NewGRF: Oil Wells in Temperate terrain now can Increase production, Better vehicle names, Use-able default aircraft, Oil Rig for Snowland and Desert, Speed for Suspension bridges.
Patches (OpenTTD): Improved smooth_economy [in trunk], More (diesel) smoke [in trunk], Realistic_acceleration finetune.
Keep 'em rollin'!
Patches (OpenTTD): Improved smooth_economy [in trunk], More (diesel) smoke [in trunk], Realistic_acceleration finetune.
Keep 'em rollin'!
Who is online
Users browsing this forum: No registered users and 3 guests