Refining obsolescence - feedback requested

Topic: Refining obsolescence - feedback requested (Read 6362 times) previous topic - next topic

Refining obsolescence - feedback requested

April 20, 2010, 12:19:24 am

Following on from the discussion here, I should be interested in people's views on possible changes to the way in which obsolescence works in Simutrans-Experimental.

Currently, it works like this: there is an introduction date and a retirement date. Vehicles can be bought only after their introduction date. In recent versions, vehicles cannot be bought after the retirement date if a certain simuconf.tab setting is set. After the retirement date, the vehicle's running costs and fixed monthly costs increase in a linear fashion until a certain number of years after the retirement date (specified in simuconf.tab), and then reaches a plateau. The names of obsolete vehicles, and their running costs, appear as blue in any listings of vehicles, as do any convoys containing obsolete vehicles.

The problem that has been identified with that model is that, if the vehicles become obsolete soon after its replacement is introduced, there is not enough time to switch over to the new vehicles before the obsolescence price increase sets in. If, on the other hand, there is a large overlap period, the depot gets clogged with vehicles that nobody would want to buy from new because they have been superseded.

The solution mooted was to have two retirement dates: one after which the vehicle is no longer available to buy (unless "show obsolete" is selected in the depot window and that option is not disabled in simuconf.tab), and the other after which the maintenance cost begins to increase. The question is: do people think that this is a good idea? And, if so, some questions about how it should be implemented follow. There would have to be a default setting in case a vehicle did not specify the new type retirement date. My view at this stage is to have that default customisable in simuconf.tab. Is there any particular need to have different defaults for different kinds of vehicle (aircraft, ships, 'buses, etc.), or would such a step not justify the additional work required to program it? In either case - what would be a good default value? The blue colour for the name: should that appear after the first retirement date or the second retirement date? Would it be easier for pakset authors if the second retirement date was expressed as a specific date, or a certain number of months after the main retirement date (so that one can update both at once by changing just the one date, leaving the relationship between them the same)?

It seems clear that the actual dates on which vehicles were taken out of service can no longer be used as the "retirement date" as it is in current builds of Pak128.Britain, because those dates are often arbitrary, and depend on external factors more than the actual life cycle of the vehicles themselves. But what should be used instead? The dates of the actual production run? The last date at which such a vehicle would realistically have been made had there been a demand for it (and if so; how to deduce/guess such a date)? Something else?

Finally, I have also contemplated the possibility of increasing vehicle maintenance cost at the beginning of their life-cycle rather than just at the end. This is in line with reality, where new vehicles take time to bed in, and have lower availability and higher maintenance costs as a result. A vehicle's upkeep costs over its lifetime have been described to me as a "bathtub curve" by somebody in the industry. Should this be modelled? And if so, should the cost start coming down from the introduction date, or from the first date on which somebody actually buys (or even uses) such a vehicle? And how should this information be represented to the user?

I should be very grateful for feedback on any of these issues; don't feel the need to answer either everything or nothing at all; any amount of information is better than any lesser amount :-)

Re: Refining obsolescence - feedback requested

Reply #1 – April 20, 2010, 02:36:00 am

Quote from: jamespetts – on April 20, 2010, 12:19:24 am

The solution mooted was to have two retirement dates: one after which the vehicle is no longer available to buy (unless "show obsolete" is selected in the depot window and that option is not disabled in simuconf.tab), and the other after which the maintenance cost begins to increase. The question is: do people think that this is a good idea?

Yeah. "Still supported but not for sale" :-)

Quote

And, if so, some questions about how it should be implemented follow. There would have to be a default setting in case a vehicle did not specify the new type retirement date. My view at this stage is to have that default customisable in simuconf.tab. Is there any particular need to have different defaults for different kinds of vehicle (aircraft, ships, 'buses, etc.), or would such a step not justify the additional work required to program it?

No need.

Quote

In either case - what would be a good default value?

15 years after sales stop.

Quote

The blue colour for the name: should that appear after the first retirement date or the second retirement date?

Second.

Quote

Would it be easier for pakset authors if the second retirement date was expressed as a specific date, or a certain number of months after the main retirement date (so that one can update both at once by changing just the one date, leaving the relationship between them the same)?

Don't know!

Quote

It seems clear that the actual dates on which vehicles were taken out of service can no longer be used as the "retirement date" as it is in current builds of Pak128.Britain, because those dates are often arbitrary, and depend on external factors more than the actual life cycle of the vehicles themselves. But what should be used instead? The dates of the actual production run? The last date at which such a vehicle would realistically have been made had there been a demand for it (and if so; how to deduce/guess such a date)? Something else?

Quote

Finally, I have also contemplated the possibility of increasing vehicle maintenance cost at the beginning of their life-cycle rather than just at the end. This is in line with reality, where new vehicles take time to bed in, and have lower availability and higher maintenance costs as a result. A vehicle's upkeep costs over its lifetime have been described to me as a "bathtub curve" by somebody in the industry. Should this be modelled?

It sounds fun, but at the moment I'm still fighting crash bugs. :-/ I don't think it's actually worth putting in at this time. For now I would simply consider vehicles' *introduction dates* to be *after* the "running in" period. We don't buy experimental new technology in this company. ;-)

Re: Refining obsolescence - feedback requested

Reply #2 – April 20, 2010, 02:51:06 pm

In real life vehicles are used about 30 to 50 years. This time starts with actually using them. Thus I'd recommend starting a period of increasing maintenance costs after a time since built/bought or amount of kilometers (whatever ends first) of constant maintenance.

These thresholds should be vehicle dependent with a default value in simuconf.tab of 30 years and a kilometrage of say 10,000 hours * max speed (Horse: 25 km/h * 10,000 h -> 250.000 km*

, Concorde: 2,100 * 10,000 -> 21,000,000 km).

The raise of maintenance should be nonlinear, say 1% per year, which results in 33% after 29 years, 50% after 41 years, 100% after 70 years, and 170% after 100 years (2% p.a.: 32% after 14 years, 51% after 21 years, 100% after 35 years, and 625% after 100 years or 3% p.a.: 34% after 10 years, 51% after 14 years, 100% after 24 years, and 1800% after 100 years).

*) within 30 years this means 23 kilometers per day (with free Sunday 27 km/d

). About 1 hour running max speed per day only. ... and with a lot of care a horse can grow very old (evidence: see attached "Very old horse").

Re: Refining obsolescence - feedback requested

Reply #3 – April 20, 2010, 02:56:13 pm

Thank you both for your feedback. In relation to the idea of a per vehicle maintenance increase, this was discussed on the previous thread to which I linked in the opening post. Because that thread is long, I shall quote the relevant p****age:

Quote

Some time ago now, when I was first developing obsolescence, I raised the idea of obsolescence based on age. A vehicle's actual age is indeed stored already in Standard, so it would be fairly easy to accomplish.

However, an objection was raised, which I thought reasonable at the time, which was that, if a vehicle's maintenance costs increased with age, it would introduce an unacceptable level of micromanagement into the game in the following way: suppose that one has a line with 10 vehicles in 1960. The number of p****engers grows, and every year between 1960 and 1975, one buys two new vehicles. They all have a lifespan of 20 years. In 1980, one has to replace the original 10. Does one then have to remember to come back every year and replace the remaining two for the next fifteen years; or does one replace them all early, and waste a lot of their value?

The idea of obsolescence as currently implemented (incidentally, Simutrans-Experimental has never prevented players from buying obsolete vehicles, and has only recently merged in the Simutrans-Standard code to allow this to be done in simuconf.tab) is obsolescence of type, rather than natural entropy of particular vehicles. As types cease to be supported by manufacturers and/or become obsolete by design, maintaining them becomes progressively more expensive.

Re: Refining obsolescence - feedback requested

Reply #4 – April 21, 2010, 01:48:23 am

Well, if you are trying to avoid micromanagement...

How about this: If you are trying to maintain a piece of equipement from the 60s in 2010, your problems would most likely be sourcing replacement parts as well as finding someone who can maintain a 50 year old vehicule. So in essence, regardless of if a vehicule was built in 1960 or 1969, you have the same problem, and your running costs could be seen as being the same.

So how about setting the second obsolescence date to a static value, from when the vehicule is first available? Something like 15 years for road vehicules, and 30 for trains (I got these numbers from a transit forum I read frequently).

Re: Refining obsolescence - feedback requested

Reply #5 – April 21, 2010, 02:38:18 am

hm, somehow what i tried to post is lost.

I also think increasing the maintenance cost shortly after introduction of a vehicle is not a good idea. while it reflects a real issue, it's difficult to model in any reasonable way without a lot detailed knowledge about the vehicle. furthermore it is overall not a very important issue, compared to the simplistic way vehicles are purchased in game.

Unlike neroden i think it is neccessary to have diferent times between non-availability and obsolecence with cost increase for different types of vehicles. 15 years for road vehicles, 30 years for trains and also aeroplanes and unlimited for ships. With ships the only issue is the obsolescence of steam, and this should be handled in the same way as for locomotives.

Regarding this issue i have another suggestion, to avoid introducing a second date in the vehicle dat files. Include a value in the simuconfig.tab where the obsolecence of steam engines is defined. After this date the maintenance is increase by a fixed value per km, (unlike before not percentage). In that way it immediately becomes a large problem for steam lorries (Sentinel). After a while a real problem for locomotives. And only long after this a problem for large steam ships. This also reflects the labour cost increase much better. A steam engine needs at least 3 people to operate, even if it's a wee one.

An example for this suggestion:
Set the date to 1948, increase the costs by 0.5 simudollar per year. Sentinels would be unprofitable after a year already. Steam locomotives would become rather expensive to operate in 1954 (+3 1/km) and unbearably expensive in 1964 (+8) or 1968 (+10). That's when BR pulled the 9F out of service.

Implementation shouldn't be difficult, the engine type is already in the dat file. Else it's just another factor to include in the maintenance calculation.

As Lmallet pointed out, both increases in maintenance cost need to have an uper limit. I think using a heavyside function should take care of it quite well.

Regarding Bernds suggestion to base the obsolescence also on the odometer , i have the position as detailed in the thread mention in the initial posting. It's better to treat a vehicle in game not as a specific, individual single vehicle, but as a representation of interchangeable, indistinguishable vehicles. Where one vehicle in game just represents a metric to measure the flow of p****engers. (reminds me a bit of decoherence in quantum mechanics)

Re: Refining obsolescence - feedback requested

Reply #6 – April 22, 2010, 01:15:24 am

Quote from: sdog – on April 21, 2010, 02:38:18 am

Unlike neroden i think it is neccessary to have diferent times between non-availability and obsolecence with cost increase for different types of vehicles. 15 years for road vehicles, 30 years for trains and also aeroplanes and unlimited for ships.

Well, that's reasonable too. Remember, we are talking defaults, so I don't think *too* much time should be spent on it: I'm hoping most paks intended for experimental will in fact include both dates for every vehicles. I do think it's critical to make it *possible* to specify the "not available for sale" and "maintenance starts going way up" dates separately, as historically the difference between the two has ranged from very small (steam-powered road cars, where the entire technology went away) to quite large (Budd railway cars), to enormously long (horses)!

Quote

Regarding this issue i have another suggestion, to avoid introducing a second date in the vehicle dat files.

In contrast,

I really do think it's important to be able to introduce a second date in the dat files.

Re: Refining obsolescence - feedback requested

Reply #7 – April 22, 2010, 01:20:13 pm

Most vehicles are produce in a very short time slot (typically less than 10 years) until progress made then outdated. Sucessfull design where then still used until their retirement data (the one currently in the game). E.g. most steam engines were built before 1940 but still retired in the lat 70ies (depending on coutnry). Even the legendary ones were not built for more than 15 years at most. The american F3 which redefined diesel traction was built for only three years but was used . Even SD40-2 was only built from 1972-1986, fourteen years. The preussian P8 was built from 1906-1923 but was in service until 1974. GG1 was built between 1935-1943 but used until 1983. Or something less famous: BR Cl****45 built between 1960-62 and retired 1988.

One could think of a ten years or 1/5th of the time between intro and retirement date (the larger of both) to have them in the depot.

Re: Refining obsolescence - feedback requested

Reply #8 – April 25, 2010, 11:13:33 pm

I don't think you need a second date, just a calculation from the retirement date for the maintenance increases (they begin x years after retirement).
I do like the idea of the increases starting after 10,000 running hours calculated by distance traveled.

Re: Refining obsolescence - feedback requested

Reply #9 – May 24, 2010, 11:23:38 pm

Please note that this feature has now been implemented in Simutrans-Experimental 8.0, although I have not yet recalibrated Pak128.Britain-Ex to take full advantage of it.

Re: Refining obsolescence - feedback requested

Reply #10 – May 25, 2010, 04:21:32 pm

Out of curiosity, which way did you implement it?

Re: Refining obsolescence - feedback requested

Reply #11 – May 29, 2010, 12:03:47 am

Bit late but I think this is a great idea.
Just a couple of comments
I think having the second date relative to the first one (as in write "10 years" rather than "1965") is a good idea, it doesn't make it any harder to change the second date, but it does make it easier to change the first one. This will probably avoid many accidental errors in this regard.
I also like the idea of higher prices at the beginning of a vehicles production/use but it does make it harder at the beginning. So ideally it should come with an off-switch

Re: Refining obsolescence - feedback requested

Reply #12 – May 29, 2010, 10:31:38 pm

Apologies for the delay in response - have just come back from holiday. The way in which this has been implemented is that one can specify in a vehicle's .dat file how many years after the retirement date that it becomes obsolete, the time over which the maintenance cost increases and the percentage increase in cost at the end of that period of time. The increase remains linear during that period. Only the retirement date (the end of production date) is shown in the depot window: the existing "retirement date" is used as an end of production date.

If no values are specified in the individual vehicles' .dat files, default values from simuconf.tab are used (on a technical level, if nothing is specified in the .dat files, values of zero are used, which, when encountered, tell the program to use the simuconf.tab values instead).

I did not implement the increase of cost at the beginning of the life cycle as there did not appear to be much appetite for it - it may be implemented some time in the future, but that will have to be subject to further consideration. The present priority is fixing the bugs that have been reported.

Re: Refining obsolescence - feedback requested

Reply #13 – June 18, 2010, 03:58:08 pm

Quote from: jamespetts – on May 29, 2010, 10:31:38 pm

Apologies for the delay in response - have just come back from holiday. The way in which this has been implemented is that one can specify in a vehicle's .dat file how many years after the retirement date that it becomes obsolete, the time over which the maintenance cost increases and the percentage increase in cost at the end of that period of time. The increase remains linear during that period. Only the retirement date (the end of production date) is shown in the depot window: the existing "retirement date" is used as an end of production date.

If no values are specified in the individual vehicles' .dat files, default values from simuconf.tab are used (on a technical level, if nothing is specified in the .dat files, values of zero are used, which, when encountered, tell the program to use the simuconf.tab values instead).

Beautiful and elegant; nice work James!

Re: Refining obsolescence - feedback requested

Reply #14 – June 18, 2010, 05:35:46 pm

Thank you!