News:

SimuTranslator
Make Simutrans speak your language.

Overhauls and renewals

Started by Spenk009, November 09, 2014, 06:00:09 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Spenk009

Moderator note: This topic was split from this topic regarding updating the pakset as it diverged into discussion of new features in the code.

Quote
Have you managed to get the way-improvements branch compiled yet? If so, you are making good progress.

I was using the yoshi.simutrans.com SVN sources and MSVC was telling me when compiling that it couldn't find the library file. I'll be able to take a better look early next week, it's probably because I got the wrong locations for the .h & .lib files in MSVC.

QuoteFar better would be to add way maintenance based on the vehicle's axle load every time that the vehicle passes over it: this will also be much simpler to code, as the block reserver is very complicated.
I see your point about the reserver, I assumed there was a return of the function I could use. Making the vehicle add its weight to the tile usage statistic when it enters the tile is probably easier and more detailed.

For Github, I took a look at it and it looks very simple and effective. Will fork pakbritain-experimental and work on it. On the topic of graphical improvements, are the problematic looks of reversing trains fixable by tweaking the images/dat files?

jamespetts

Quote from: Spenk009 on November 09, 2014, 06:00:09 PM
I was using the yoshi.simutrans.com SVN sources and MSVC was telling me when compiling that it couldn't find the library file. I'll be able to take a better look early next week, it's probably because I got the wrong locations for the .h & .lib files in MSVC.

I think that Yoshi's SVN repository is for Standard only; so far as I am aware, only Github has been used for Experimental. If you can be more precise about what libraries that you are missing, I can try to assist you, but it might be easier for you to have a go at compiling from Github yourself first and let me know of the problems that you cannot easily overcome when doing that. As with the pakset, I recommend that you create your own Github repository based on the Simutrans-Experimental repository (way-improvements, preferably).

QuoteI see your point about the reserver, I assumed there was a return of the function I could use. Making the vehicle add its weight to the tile usage statistic when it enters the tile is probably easier and more detailed.

This is probably the best way of doing it. You will need something like "tonnes since last renewed", together with a renewal system and a system for increasing the maintenance of way tiles that need to be renewed but have not been renewed; you will probably also need a system for working out how much traffic that a way tile can handle before its next renewal. In fact, "tonnes since..." is not quite the thing, as we need this to vary by axle load, so you will need to think of a formula that works, is realistic (I am told that there is an exponential increase in wear with an increase in axle load), can be calibrated effectively (the axle load wear for a dirt track will need to be very different to the axle load wear on a high speed railway) and not take significant amounts of processing power for every tile of vehicle movement (as Simutrans-Experimental needs to be able to work with absolutely huge maps with very large number of vehicles in motion at the same time).

I suggest that you look at the code and then describe how you want to proceed on this thread before committing anything to the code, as there are lots of things that have to be taken into account. (Alternatively, you could just experiment with different approaches, albeit there is then a large risk of significant amounts of coding not being used; but you may find this useful for learning purposes in any event).

QuoteFor Github, I took a look at it and it looks very simple and effective. Will fork pakbritain-experimental and work on it. On the topic of graphical improvements, are the problematic looks of reversing trains fixable by tweaking the images/dat files?

I have tried with this approach, using offsets in the .dat files (see the narrow gauge trains as an example), but this was not effective. It might conceivably be possible to fix this by completely re-aligning all the vehicles, but this would be such a gargantuan task that it would be easier to fix in the code (and more desirable, since it is not ideal that graphics that work fine in Standard go wrong in Experimental in any event). However, I have never understood the graphics code well enough to be able to do this.

Thank you again for your help with this - it is very much appreciated.
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.

DrSuperGood

QuoteThis is probably the best way of doing it. You will need something like "tonnes since last renewed", together with a renewal system and a system for increasing the maintenance of way tiles that need to be renewed but have not been renewed; you will probably also need a system for working out how much traffic that a way tile can handle before its next renewal. In fact, "tonnes since..." is not quite the thing, as we need this to vary by axle load, so you will need to think of a formula that works, is realistic (I am told that there is an exponential increase in wear with an increase in axle load), can be calibrated effectively (the axle load wear for a dirt track will need to be very different to the axle load wear on a high speed railway) and not take significant amounts of processing power for every tile of vehicle movement (as Simutrans-Experimental needs to be able to work with absolutely huge maps with very large number of vehicles in motion at the same time).
As good as realism is, are you sure that it will not become excessively complicated? I mean from a user perspective having the maintenance depend on the usage would be far easier than having automatic track renewal with usage and things. The only time track renewal would be useful is if the simulator actually covered way construction and the line having to close at some stage to allow for renewal but that would probably ruin the game for many people.

What you are proposing is also not even that realistic as axel load only has to do with part of it (especially roads). Rails have other kinds of wear such as from breaking and accelerating which produce a lot of friction on the steel rail (especially if sand is used). This is why segments in busy stations are changed quite often yet the entire line (which is as busy) is not changed at the same time, even if both were originally laid at the same time.

What I would do is add another counter "wear" to go with convoys. The convoys themselves are then responsible for producing appropriate wear. The actual wear does not change based on track type, only how efficiently it converts into maintenance. This means that a fully loaded freight train could produce more wear than a partly loaded or empty freight train. It could also allow you to factor in acceleration for a more accurate model. It also means that steel tracks could better handle wear than wrought iron tracks in the form of less maintenance for the same wear.

Ways would then be balanced with very low standing maintenance cost. This would cover the natural wear (from environment) and also labour needed to keep the track working (remove plants, fences etc). The rest of the maintenance would come from wear multiplied by some way type dependent factor. This represents the average amount that would need to be spent per month replacing tracks due to use.

Querying a tile shows the usage metric for both last month and the current month and the costs associated with that. To prevent iterating through every tile at end of month to compute maintenance, two counters could be used. One in each tile which represents the wear that tile received. The other is then associated with the way type for the owner company and represents the total wear on that particular track type for fast computation of track maintenance. An alternative approach would be to charge for wear as it occur (the train moves over a way) in which case the maintenance can be real time as the wear occurs instead of at the end of each month paying for all the wear that occurred.

What is also good is that wear generated can be added as a logged convoy statistic. So querying a convoy or line could allow you to see the total wear it generated per month from operation. This would be very useful as if a replacement could significantly lower wear it might save quite a bit of money. Both wear generated and cost from wear could be graphed allowing one to check a convoy if it still breaks even.

jamespetts

Some interesting thoughts. The current system for maintenance of ways is very computationally efficient: there is a single figure per player for way maintenance, which is deducted from the player's finances every month. This figure is altered whenever ways are added, upgraded or removed. We really do not want to deviate from this very efficient approach.

The idea of renewal was, in part, to preserve this system, but also because it is important for some balancing dynamics for the costs not to be spread evenly throughout the lifetime of an asset (which is realistic). This was discussed, I believe, in around 2011. Renewal has other significant benefits, too. Firstly, renewal and upgrading are closely related. I envisage a system in which people can mark a way to be upgraded to another way of the same type whenever it next needs renewing. The cost of renewal will always be the upgrade cost to the way to which the renewal is to be made (even if it is the same as the current type), so this would be a significant feature. Also, renewals, when they occur without the player having specified a specific waytype, would use the closest currently available way to that being renewed (i.e., the cheapest currently available way with at least the same axle load and speed limits) if the current way has become obsolete. This would prevent obsolete ways from lingering forever (except on mothballed lines) and provide automatic upgrade paths to, for example, public roads, the upgrading of which is currently excessively laborious.

The wear dynamics idea is quite interesting, although my concern with that is how one would actually calibrate and research what values that every vehicle should have (I assume that this would actually be set by vehicle not by convoy?). If there is no mathematically deterministic relationship between this figure and some or other researchable real life metric, then this will be a calibration nightmare. It is also sub-optimal in that it will require a vast amount of time to be consumed in adding these data to every single vehicle in the pakset (and there are a vast number of them), so any solution that does not involve doing this would be preferable.

I do like the idea of rail junctions being considerably more expensive to maintain than straight track, however. Any thoughts as to quite how that might be achieved would be most welcome. (I do not think that there is any sensible way of simulating the wear caused by sanding, and basing wear on acceleration and deceleration seems to be more difficult than it is probably worth).
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.

DrSuperGood

QuoteThe idea of renewal was, in part, to preserve this system, but also because it is important for some balancing dynamics for the costs not to be spread evenly throughout the lifetime of an asset (which is realistic). This was discussed, I believe, in around 2011. Renewal has other significant benefits, too. Firstly, renewal and upgrading are closely related. I envisage a system in which people can mark a way to be upgraded to another way of the same type whenever it next needs renewing. The cost of renewal will always be the upgrade cost to the way to which the renewal is to be made (even if it is the same as the current type), so this would be a significant feature. Also, renewals, when they occur without the player having specified a specific waytype, would use the closest currently available way to that being renewed (i.e., the cheapest currently available way with at least the same axle load and speed limits) if the current way has become obsolete. This would prevent obsolete ways from lingering forever (except on mothballed lines) and provide automatic upgrade paths to, for example, public roads, the upgrading of which is currently excessively laborious.
However any sort of spread cost simply becomes another maintenance. Ultimately in real life the installation cost of the lines ends up being a small fraction of the maintenance cost spent to maintain them and keep them running due to things like them needing to be renewed periodically. All renewal like that would do is make track "maintenance" burst every few months or years instead of a smooth continuous figure withdrawn every month. In the end the result is the same which ever approach is used, every unit of time you are having to pay some figure to keep the track and the figure is largely related to utilization and usage. An example could be engines that wheel spinned often generate more wear (no traction control) than modern electric engines (which try to minimize the spin). These constants could be filled in over a long period of time as the default formula exists that applies to all convoys. I would suggest factors of the default formula or modifications of convoy physical properties as otherwise the constants could become out of balance if the formula is ever adjusted.

Renewal could still exist with my suggestion as part of the way wear is converted into cost. The total amount of wear for a track type divided by the wear per renewal times the cost to renew could be the monthly amount spent on track renewal. Being monthly the figure is smooth and it allows for way type variances with resilience (amount for renewal) and cost (amount each renewal costs). The renewal cost could then be preserved for line upgrading and things.

Passive way type migration could occur over time. The length of time required would be based on the determined replace rate (how much wear the way type is receiving). This corresponds to a number of tiles to replace with the new way type. To force faster migration (which players may want at times) they could adjust a "bonus" factor which migrates tracks faster but at a slight cost each (to represent lost track life). This would work for global passive migration (from obsolete track to not obsolete track) but might run into issues if there are lines not being used. Selective way upgrading (choosing a section to migrate) would be more difficult and might need its own objects that are periodically checked to total the usage across the section or which upgrades them with a probability based on usage.

QuoteThe wear dynamics idea is quite interesting, although my concern with that is how one would actually calibrate and research what values that every vehicle should have (I assume that this would actually be set by vehicle not by convoy?). If there is no mathematically deterministic relationship between this figure and some or other researchable real life metric, then this will be a calibration nightmare. It is also sub-optimal in that it will require a vast amount of time to be consumed in adding these data to every single vehicle in the pakset (and there are a vast number of them), so any solution that does not involve doing this would be preferable.
Since in most cases the entire convoy passes over a tile when moving, it would be sufficient to compute a "wear" amount when the convoy departs a station. This would be the sum of wear generated by all the convoy units that make up a convoy. How wear is computed could be entirely based on weight and axel number (not axel load as that would mean a full convoy would generate the same wear as an empty convoy, also since this is run only when leaving a stop the calculation can be more complex) however for certain special convoys which were notorious for producing more or less wear there might be fields for them (which modify or overwrite the normal formula).

QuoteI do like the idea of rail junctions being considerably more expensive to maintain than straight track, however. Any thoughts as to quite how that might be achieved would be most welcome. (I do not think that there is any sensible way of simulating the wear caused by sanding, and basing wear on acceleration and deceleration seems to be more difficult than it is probably worth).
In the easiest implementation a factor could be applied whenever the convoy is breaking or accelerating as that is when the most force is being applied against the way to move the convoy. Although for cars it should be very minor (if not none at all) for trains this is important as it usually is the time sand is used. The factor could be something like double wear when stopping at a stop (the approach deceleration) or when under half the desired speed (putting maximum effort to accelerate the convoy). It does not need to be an accurate sand simulation, purely a bonus factor to wear at approximately the situations sand would be used for trains. It could be set based on way type as trains are notorious for it due to the use of sand yet cars not so much as they way they work is different. Things like maglev may also not be affected by such wear as they do not have physical friction.

It also places some incentive to make efficient lines so that you do not constantly start and stop trains quickly at signals as that would generate more ware. That is if such mechanics are supported.

An important part is usability. Since wear is a metric that convoys produce onto ways when moving, it is quantifiable which is very important. An approximation could be given for a certain assembly in the depot allowing players to gauge how much wear it will produce. When replacing you could compare expected wear metrics to see if a new convoy will cost you more or less from "way replacement". It also could be a billable quantity for shared ways. It also opens up the possibility of special purpose ways which are more efficient at dealing with wear but are more expensive to build and higher maintenance. Wear is also a good metric for line utilization since unlike convoys per month which does not factor in convoy length (you could send 64 single tile convoys or a single 64 tile convoy which do the same work), wear sort of scales with it. A line seeing a lot of wear would be a good indicator of it being well utilized and that most of the cost would be from the wear rather than the maintenance.

As far as balancing goes. Way maintenance could be lowered but now a considerable amount would be going based wear. The result is that ways going to single lowly used industries would be far more affordable (low monthly cost) while highly used lines in the middle of a junction or such would cost a lot more to maintain so be less profitable.

Junna

Would this 'renewal' involve the player having to, as it were, relay entire sections of track? This would seem to be a very arduous task if so, all the technical and programming aspects disregarded, for the player to have to do; and how would, for example, the player identify easily all the points where this was needed? It is quite cumbersome as it is to manage a very extensive network, and jams and problems might already not so easily be noticed until a message of a crowding somewhere comes up...

Aquin

As tempting as the idea of renewal sounds. I don't think it will improve gameplay.
Scenario 1: renewal cannot be automated, this will lead to a huge amount of micromanagement and random distortions in the network.
Scenario 2: renewal can be automated, this will lead to cost appearing randomly, leading to frustration if your company runs on the edge
Scenario 2b: The infrastructure is owned by the public player, then basically nothing happens.

A function to globally upgrade all roads/tracks of a specified type to a new type could be more useful.

Also on the programming side it sounds like a lot of the calculations will be done twice without any benefit.
As I understand it, what you want to have is:
1. infrastructure has some maintenance based on usage
2. some vehicles cause more maintence costs then others

To 1: there already is a statistic for vehicles that passed the tile this month, using a simple cost per vehicle gives a usage based amount.
I would not differentiate further between different vehicle types, loaded or not, accelerating,... this will be hell to implement and balance
To 2: if some vehicles should cause more maintenance costs, then just increase their maintenance/tile value, and consider that specific value is the maintenance of both the vehicle and the infrastructure damage caused by it. If you really want to make a difference between loaded and empty vehicles, you could give this a load based part.

DrSuperGood

QuoteTo 1: there already is a statistic for vehicles that passed the tile this month, using a simple cost per vehicle gives a usage based amount.
I would not differentiate further between different vehicle types, loaded or not, accelerating,... this will be hell to implement and balance
Except then one would simply use larger convoys. I could send down a 64 tile long train (yes they do exist in experimental) instead of 64 1 tile trains.

The idea of a "wear" metric is to cope with the dynamics of vehicles in a way that sending a 64 tile train or 64 single tile trains would generate similar wear.

QuoteTo 2: if some vehicles should cause more maintenance costs, then just increase their maintenance/tile value, and consider that specific value is the maintenance of both the vehicle and the infrastructure damage caused by it. If you really want to make a difference between loaded and empty vehicles, you could give this a load based part.
This does not model the differences in durability of ways. For example continuously welded steel track should be able to deal with wear better (costs less) than wrought iron rails from the 1850s. That said, as an alternative implementation it is not bad.

jamespetts

#8
Thank you all for your thoughts. Firstly on renewals: the plan was definitely for renewals to be automated: it would be insane for players to do this manually. If the player takes no action at all, the renewal would be to the same waytype if that is still available, or to the nearest available waytype if it is not. The renewals system is intended to link to the idea of a lower cost for upgrading a way than building a new way (what I have termed in the past the "forge cost": the cost of forging a new way on virgin territory, as opposed to the cost of the tarmac or rails/sleepers (etc.) themselves), which is already implemented in the way-improvements branch: the renewal cost would simply be the lesser of those costs. However, it would also be possible for a player (by, for example, dragging a new way over an old way whilst holding down the SHIFT or ALT keys - I will have to look into the UI more carefully to see which would work: I know that CTRL is already taken) to mark the way as to be upgraded to a particular way type at the point of next renewal. This would potentially be a more cost effective way of renewing a way, as only the upgrade cost to the newer way would be charged, and it would be charged only at the last possible moment, getting the most wear out of the existing way.

As to the issue of a large amount of money being deducted suddenly, this is not inherently unrealistic, although it would, I suppose, help to have some sort of warning. Indeed, this is intended to be an important mechanism, as paying, for example, 100,000c every 10  years is not in any way identical in gameplay terms to paying 833c every month: in 10 years (or 2, 5, 15 or 20 years, or some other arbitrary figure depending on the waytype and degree of use), a player might have built up a large pool of capital or a much larger income stream, and only have been able to do so because he/she was paying 833c/month less than would otherwise have been necessary. It also means that players have to cope with non-constant expenses, which might interfere with capital projects in the 10th year in a way in which the 833c/month would not. Further, I plan to add the dynamic of variable inflation (that is, whole categories of things each having different rates of inflation). If in those 10 (etc.) years, the cost of way renewal has increased at a different rate than the revenues, putting the whole amount at the end of the 10 (etc.) years potentially makes a significant difference to spreading it evenly.

The tricky part is developing a decent UI with which to warn the players of impending renewals: any suggestions not involving major new UI elements (which would take forever to program) would be most welcome. (I should add that something similar will also be needed for vehicle overhauls when this system is implemented, too). The most difficult part is guessing what the cost will be in any given period in the future.

Incidentally, what I suggest in relation to renewals is intended to be instead of varying the monthly amount for maintenance based on usage: the idea is to have a fixed monthly maintenance amount per way type/tile, as now, and add a renewal mechanism based on wear.

As to a wear figure, what we need to avoid is a completely arbitrary scale. I made the mistake of implementing comfort as an arbitrary scale many years ago, and it has been a nightmare to balance (I have eventually found a way of translating it into a meaningful scale of maximum comfortable journey time, which is much easier to understand and calibrate). Dr. SuperGood's basic idea for a wear figure is a good one, however. One approach might be to express wear negatively: in other words, each way tile when laid or renewed starts with a wear value of, say, 255 or 65535 meaning that it is in perfect condition, and this is reduced by a certain amount every time that a convoy passes over it until it reaches 0, at which point it must be renewed. The wear figure displayed to the end user should be as a percentage, converted from the base figure only when needed for the UI. We have to be careful about the number of bits, however. Too large a figure would increase memory consumption and bandwidth as there are a lot of tiles on a huge map; too small a figure would mean that rounding errors would be a serious problem: it would significantly distort gameplay if convoys regularly rounded down the wear per tile to zero. Realistically, this might need a 32-bit integer.

The next tricky question is what to do with an insolvent player when renewal time comes. Currently, maintenance is allowed to continue to be spent whilst a player has exceeded her/his credit limit until the player eventually becomes bankrupt. However, in some senses, renewal is a capital expense, and a renewal involving an upgrade might well, if the credit limit were disapplied, be a way of circumventing the credit limit. One of two solutions is desirable here: either renewing to a mothballed waytype, which would prevent the passage of all vehicles, or not renewing, but greatly increasing the monthly cost to keep a worn out way going past the end of its ordinary working life, perhaps in line with a multiplier specified in the simuconf.tab file. Perhaps also, a speed limit could be imposed (of X% of the way's base speed) on worn out ways. I prefer the latter solution, as it is less disruptive to players in financial difficulty, probably more realistic, and will allow for players manually deciding to suspend renewals of ways, which should help players to manage their cash flow, which could be built into the UI described above. This system (costs multiplied by Y, maximum speed reduced to X%, players given option to suspend renewals manually) could also work equally well for vehicle overhauls, and the use of the same system in both cases would give a helpful level of consistency to the interface.

Edit: One miscellaneous matter that I initially forgot to mention: hammer blow is an important variable factor for wear on railways by steam locomotives.
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.

Aquin

Quote from: jamespetts on November 10, 2014, 09:15:30 PM
Thank you all for your thoughts. Firstly on renewals: the plan was definitely for renewals to be automated: it would be insane for players to do this manually. If the player takes no action at all, the renewal would be to the same waytype if that is still available, or to the nearest available waytype if it is not. The renewals system is intended to link to the idea of a lower cost for upgrading a way than building a new way (what I have termed in the past the "forge cost": the cost of forging a new way on virgin territory, as opposed to the cost of the tarmac or rails/sleepers (etc.) themselves), which is already implemented in the way-improvements branch: the renewal cost would simply be the lesser of those costs. However, it would also be possible for a player (by, for example, dragging a new way over an old way whilst holding down the SHIFT or ALT keys - I will have to look into the UI more carefully to see which would work: I know that CTRL is already taken) to mark the way as to be upgraded to a particular way type at the point of next renewal. This would potentially be a more cost effective way of renewing a way, as only the upgrade cost to the newer way would be charged, and it would be charged only at the last possible moment, getting the most wear out of the existing way.

I would make it even simpler. Have one text based window, in this window all (available) roads/tracks/... are listed, next to each is a selector for the waytype to upgrade to and a selector for the condition when to upgrade. The conditions for upgrade could be "when worn out and original unavailable", "when worn out and upgrade available", "as soon as possible, ignoring wear status". If you want to upgrade a specific connection at a different time then you have to do it manually.


Quote from: jamespetts on November 10, 2014, 09:15:30 PM
As to the issue of a large amount of money being deducted suddenly, this is not inherently unrealistic, although it would, I suppose, help to have some sort of warning. Indeed, this is intended to be an important mechanism, as paying, for example, 100,000c every 10  years is not in any way identical in gameplay terms to paying 833c every month: in 10 years (or 2, 5, 15 or 20 years, or some other arbitrary figure depending on the waytype and degree of use), a player might have built up a large pool of capital or a much larger income stream, and only have been able to do so because he/she was paying 833c/month less than would otherwise have been necessary. It also means that players have to cope with non-constant expenses, which might interfere with capital projects in the 10th year in a way in which the 833c/month would not. Further, I plan to add the dynamic of variable inflation (that is, whole categories of things each having different rates of inflation). If in those 10 (etc.) years, the cost of way renewal has increased at a different rate than the revenues, putting the whole amount at the end of the 10 (etc.) years potentially makes a significant difference to spreading it evenly.

The tricky part is developing a decent UI with which to warn the players of impending renewals: any suggestions not involving major new UI elements (which would take forever to program) would be most welcome. (I should add that something similar will also be needed for vehicle overhauls when this system is implemented, too). The most difficult part is guessing what the cost will be in any given period in the future.

One could look at all ways worn down to less than 5%, calculate the upgrade costs for them and send a message "123 tiles of road and 321 tiles of track have to be renewed soon, expected upgrade costs 1234567" To see where the bad parts of the infrastructure are there could be a map layer that indicates the wear status.

Quote from: jamespetts on November 10, 2014, 09:15:30 PM
Incidentally, what I suggest in relation to renewals is intended to be instead of varying the monthly amount for maintenance based on usage: the idea is to have a fixed monthly maintenance amount per way type/tile, as now, and add a renewal mechanism based on wear.

If it is on a per month basis then one can be sure that costs are evenly spread out. For a wear based system the costs may or may not spread out evenly over time. A large network that has slowly grown should be more likely to generate evenly spread maintenance, while networks where large lines are put into service at one point will generate more spikes.

Quote from: jamespetts on November 10, 2014, 09:15:30 PM
As to a wear figure, what we need to avoid is a completely arbitrary scale. I made the mistake of implementing comfort as an arbitrary scale many years ago, and it has been a nightmare to balance (I have eventually found a way of translating it into a meaningful scale of maximum comfortable journey time, which is much easier to understand and calibrate). Dr. SuperGood's basic idea for a wear figure is a good one, however. One approach might be to express wear negatively: in other words, each way tile when laid or renewed starts with a wear value of, say, 255 or 65535 meaning that it is in perfect condition, and this is reduced by a certain amount every time that a convoy passes over it until it reaches 0, at which point it must be renewed. The wear figure displayed to the end user should be as a percentage, converted from the base figure only when needed for the UI. We have to be careful about the number of bits, however. Too large a figure would increase memory consumption and bandwidth as there are a lot of tiles on a huge map; too small a figure would mean that rounding errors would be a serious problem: it would significantly distort gameplay if convoys regularly rounded down the wear per tile to zero. Realistically, this might need a 32-bit integer.

I guess this will be hell to balance as well.

Quote from: jamespetts on November 10, 2014, 09:15:30 PM
The next tricky question is what to do with an insolvent player when renewal time comes. Currently, maintenance is allowed to continue to be spent whilst a player has exceeded her/his credit limit until the player eventually becomes bankrupt. However, in some senses, renewal is a capital expense, and a renewal involving an upgrade might well, if the credit limit were disapplied, be a way of circumventing the credit limit. One of two solutions is desirable here: either renewing to a mothballed waytype, which would prevent the passage of all vehicles, or not renewing, but greatly increasing the monthly cost to keep a worn out way going past the end of its ordinary working life, perhaps in line with a multiplier specified in the simuconf.tab file. Perhaps also, a speed limit could be imposed (of X% of the way's base speed) on worn out ways. I prefer the latter solution, as it is less disruptive to players in financial difficulty, probably more realistic, and will allow for players manually deciding to suspend renewals of ways, which should help players to manage their cash flow, which could be built into the UI described above. This system (costs multiplied by Y, maximum speed reduced to X%, players given option to suspend renewals manually) could also work equally well for vehicle overhauls, and the use of the same system in both cases would give a helpful level of consistency to the interface.

Edit: One miscellaneous matter that I initially forgot to mention: hammer blow is an important variable factor for wear on railways by steam locomotives.
A speed and axle load limit of say 75% of the original could to the job, but since it is mostly a multiplayer thing, this could also be a server setting.

jamespetts

Quote from: Aquin on November 11, 2014, 08:01:02 AM
I would make it even simpler. Have one text based window, in this window all (available) roads/tracks/... are listed, next to each is a selector for the waytype to upgrade to and a selector for the condition when to upgrade. The conditions for upgrade could be "when worn out and original unavailable", "when worn out and upgrade available", "as soon as possible, ignoring wear status". If you want to upgrade a specific connection at a different time then you have to do it manually.

This would not give sufficient control to players: a player might only be able to afford to upgrade some but not all routes of a particular sought, or might desire to upgrade a more heavily used route with one type of road/track, and a more lightly used route with another type.

QuoteOne could look at all ways worn down to less than 5%, calculate the upgrade costs for them and send a message "123 tiles of road and 321 tiles of track have to be renewed soon, expected upgrade costs 1234567" To see where the bad parts of the infrastructure are there could be a map layer that indicates the wear status.

That's not a bad idea, actually: a warning based on percentage wear. Probably the best way to do this is, when each tile reaches the set threshold, add a sum representing the upgrade cost to the way to which that tile will be upgrading (either the one manually selected or otherwise the default) to a central figure representing the "renewals required soon" amount, then deduct this from that figure whenever the way is in fact upgraded or deleted.

QuoteIf it is on a per month basis then one can be sure that costs are evenly spread out. For a wear based system the costs may or may not spread out evenly over time. A large network that has slowly grown should be more likely to generate evenly spread maintenance, while networks where large lines are put into service at one point will generate more spikes.

The whole point is so that costs are not evenly spread out in reality, and that has significant economic consequences which it is important to simulate (as discussed above).

QuoteI guess this will be hell to balance as well.

I suspect that it probably will be rather difficult; if anyone has any ideas of a mathematically deterministic way based on historical data to calculate these figures, I should be very grateful.

QuoteA speed and axle load limit of say 75% of the original could to the job, but since it is mostly a multiplayer thing, this could also be a server setting.

The percentage would have to be set in simuconf.tab, which would, on multi-player games, become a server setting.
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.

DrSuperGood

QuoteAs to the issue of a large amount of money being deducted suddenly, this is not inherently unrealistic, although it would, I suppose, help to have some sort of warning. Indeed, this is intended to be an important mechanism, as paying, for example, 100,000c every 10  years is not in any way identical in gameplay terms to paying 833c every month: in 10 years (or 2, 5, 15 or 20 years, or some other arbitrary figure depending on the waytype and degree of use), a player might have built up a large pool of capital or a much larger income stream, and only have been able to do so because he/she was paying 833c/month less than would otherwise have been necessary. It also means that players have to cope with non-constant expenses, which might interfere with capital projects in the 10th year in a way in which the 833c/month would not. Further, I plan to add the dynamic of variable inflation (that is, whole categories of things each having different rates of inflation). If in those 10 (etc.) years, the cost of way renewal has increased at a different rate than the revenues, putting the whole amount at the end of the 10 (etc.) years potentially makes a significant difference to spreading it evenly.
Except when you get to be the size of the companies on the experimental server (A-train, Sarlock's transport company and GRANITE) then there is no way you can possibly plan anything like that. I doubt any of us remember >70% of what we built, especially Sarlock who could literally be said to have built half the map. In such a case having it as a steady monthly decrement would be far more useful than as noise onto your monthly profit graph.

QuoteThe tricky part is developing a decent UI with which to warn the players of impending renewals: any suggestions not involving major new UI elements (which would take forever to program) would be most welcome. (I should add that something similar will also be needed for vehicle overhauls when this system is implemented, too). The most difficult part is guessing what the cost will be in any given period in the future.
Great... So now players can have their UI spammed with ~500 renewal warnings. Not the most user friendly? Or if you go with the suggestion of a single message then that really is meaningful (why not just take my money already?).

From a user perspective paying per month is far easier. As you then know for certain a line is profitable since it is covering its expenditure. Otherwise if it barely breaks even you will go in solvent when the line renewal comes around which is basically prolonging the inevitable. It also becomes virtually impossible to measure how profitable something is as you have all these hidden future expenditures. In real life they cover these with expenditure predictions which ultimately they will average out to come out with actual meaningful profit. If you know that in 10 years you need to replace the track then you add that as part of the cost per unit time of owning it as it just makes a lot more sense that way. What I suggest is this is done automatically as part of the implementation so that people do not need to care about if it will break even or not in some variable amount of time.

Aquin

Quote from: jamespetts on November 11, 2014, 10:10:58 AM
This would not give sufficient control to players: a player might only be able to afford to upgrade some but not all routes of a particular sought, or might desire to upgrade a more heavily used route with one type of road/track, and a more lightly used route with another type.

The player can of course always manually upgrade, that is build a new way on top of the other, wasting the remaining wear. But with some timing on the player side this can be reduced to a few %. Otherwise you have to store for each waytile the information "upgrades to ..."

Quote from: jamespetts on November 11, 2014, 10:10:58 AM
That's not a bad idea, actually: a warning based on percentage wear. Probably the best way to do this is, when each tile reaches the set threshold, add a sum representing the upgrade cost to the way to which that tile will be upgrading (either the one manually selected or otherwise the default) to a central figure representing the "renewals required soon" amount, then deduct this from that figure whenever the way is in fact upgraded or deleted.
sounds efficient
Quote from: jamespetts on November 11, 2014, 10:10:58 AM
The whole point is so that costs are not evenly spread out in reality, and that has significant economic consequences which it is important to simulate (as discussed above).

I suspect that it probably will be rather difficult; if anyone has any ideas of a mathematically deterministic way based on historical data to calculate these figures, I should be very grateful.
As historical data the costs for a renewed (in comparision to a newly build) will be needed as well as the time to the next renewal. Also information if it a heavily trafficked or a less busy way is necessary. To calculate the wear one needs the time between renewals and a maximum number of convois that can use the way per month. Assuming a usage percentage (80%+ for heavly used ways, 20% for side roads) one can calculate the number of convois that will wear down that specific way.
In the end the should be at least 2 different waytypes, one for heavy traffic with high build costs, but also high wear resistance, and one for side roads which should be cheaper to build but wear down really fast.  In the end it there sould be a distinct usage threshold where one road becomes less costly to operate than the other, and this should also be in a range that is relevant for gameplay.

Aquin

Reaching back a little:
Quote from: DrSuperGood on November 10, 2014, 08:19:08 PM
Except then one would simply use larger convoys. I could send down a 64 tile long train (yes they do exist in experimental) instead of 64 1 tile trains.

The idea of a "wear" metric is to cope with the dynamics of vehicles in a way that sending a 64 tile train or 64 single tile trains would generate similar wear.
This does not model the differences in durability of ways. For example continuously welded steel track should be able to deal with wear better (costs less) than wrought iron rails from the 1850s. That said, as an alternative implementation it is not bad.
Just split the wear costs, one part is a per convoi cost, so that you can differentiate between ways that are meant for heavy traffick or side tracks.
The other part goes to the vehicle, that will make sure that the cost is the same if you send them one by one or in one go. And there will be other gameplay mechanisms like needed station lenght, minimum spacing between convois, high costs for engines vs. low costs for waggons, that will make reasonably long convois the option to go for

Quote from: DrSuperGood on November 11, 2014, 06:40:49 PM
Except when you get to be the size of the companies on the experimental server (A-train, Sarlock's transport company and GRANITE) then there is no way you can possibly plan anything like that. I doubt any of us remember >70% of what we built, especially Sarlock who could literally be said to have built half the map. In such a case having it as a steady monthly decrement would be far more useful than as noise onto your monthly profit graph.
When I think of existing games, I don't think that wear can be activated retroactively, this will lead to really nasty spikes in the maintenance as complete lines will go for renewal highly synchronized.
But in huge companies it would actually most likely the case that there is no noticeable difference, statistics should take care of equalizing the costs. It makes no difference if you pay 1% of the renewal costs for 100% of your tracks or 100% for 1% of the tracks.



Quote from: DrSuperGood on November 11, 2014, 06:40:49 PM
Great... So now players can have their UI spammed with ~500 renewal warnings. Not the most user friendly? Or if you go with the suggestion of a single message then that really is meaningful (why not just take my money already?).
Yes either death by micromanagement, or reduce it to a meaningless anoyance.

Quote from: DrSuperGood on November 11, 2014, 06:40:49 PM
From a user perspective paying per month is far easier. As you then know for certain a line is profitable since it is covering its expenditure. Otherwise if it barely breaks even you will go in solvent when the line renewal comes around which is basically prolonging the inevitable. It also becomes virtually impossible to measure how profitable something is as you have all these hidden future expenditures. In real life they cover these with expenditure predictions which ultimately they will average out to come out with actual meaningful profit. If you know that in 10 years you need to replace the track then you add that as part of the cost per unit time of owning it as it just makes a lot more sense that way. What I suggest is this is done automatically as part of the implementation so that people do not need to care about if it will break even or not in some variable amount of time.
I completely sencond you on that.

Sarlock

As a quick supporting note, I would shy away from adding anything that adds more micromanagement to the game.  When you run large companies/networks, the last thing you want to have to do is spend more hours micromanaging your company than you do already.

Large intermittent spikes in costs should be avoided -- as mentioned, go with the monthly route.  If the cost is X after 10 years, spread that cost over 120 months instead.  In the "real" world, such things are averaged out accounting-wise, though the cash outlay is usually at a specific date in time.  Keep it simple.  Reduces player fatigue/frustration and makes for less bugs to have to squash.  In the real world, a transportation company has a team of accountants working in an office crunching numbers.
Current projects: Pak128 Trees, blender graphics

jamespetts

The ultimate idea is for the code to simulate all the accountants in the back office crunching numbers so that the player only has to make the high level strategic decisions; but it has to simulate them well and accurately for the game to balance properly, and the player needs to have the full range of strategic options open to her/him.

The intermittent nature of the cost of renewal is highly significant economically for the reasons that I described earlier, especially for smaller companies. One of the real balancing challenges, that this, as part of a set of improvements, is intended to address, is the disparity between the cash flow of a small company and the cash flow of a large company. At present, it is very difficult indeed to make ends meet as a small company, and trivially easy to do so as a large company. Moblet discussed in some detail as long ago as 2011 some measures that were necessary to redress this, one of which being renewal costs: the important thing is that players are using the asset that will eventually have to be renewed for years (and all the while building additional sources of revenue) before having to meet the large capital payment for renewal. The focus on small companies may seem trivial given the huge companies that dominate the online game, but it is actually very significant: if things can be made relatively easy for new, small companies, the whole balance can be altered to make larger companies make a little less profit, ensuring that the financial challenge remains real even when a player has amassed a large network. Another piece of economic significance is that it is possible in the way that I describe above in to postpone renewals, which, although financially disadvantageous in the long term, can provide a temporary cash flow remedy in the short term for players that need it which would not be possible if the amortised cost of renewal had already been deducted monthly for the past (e.g.) ten years. There is a further problem balancing for fully amortised costs: historical maintenance figures are unlikely to be based on renewal costs, so calibrating using historical figures is unlikely to work if an amortised cost of renewal must be included.

There remains the challenge of how to do this without making the game tedious or excessively difficult. Micromanagement of a repetitive type should be avoided, but players should be able to act efficiently. In particular, players should be able to use renewal as an opportunity to upgrade (in other words, renew with the upgraded waytype, or, in vehicles, to replace rather than overhaul). This is not possible where the amortised cost of renewal has already been deducted: the player would have to pay all over again to upgrade. This has the potential to make quite a significant difference for a player in terms of expenditure. (To answer Aquin's point, this would indeed require a pointer in each way tile to a waytype to which to upgrade, but this should not cause much difficulty, as it would not be accessed very often: raw memory usage is not a serious resource problem for Simutrans-Experimental on modern computers at present, unlike memory bandwidth).

As to the UI for this, this will need careful thought. Sending players hundreds of little messages is clearly not sensible. Aquin's earlier idea is not at all a bad one: in a window somewhere, have a display showing the number of way tiles of each type that are within X percent of wear needing renewal and the cost of renewing them with the currently selected waytype, and have the ability (perhaps in the same window) to suspend all renewals. It might also be useful to have a way of temporarily suspending renewal of particular way tiles, although the UI for this would be very hard to implement (this would be much easier to implement for vehicles, and could easily be done by line or convoy). Incidentally, as to the speed reduction, it would probably be sensible for vehicles to have a power reduction instead of a speed reduction when they are worn out, which probably reflects more accurately the effect on performance of being in poor condition. This would be in addition to the multiplied per kilometre costs to represent having to work harder to maintain the vehicle.
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.

DrSuperGood

QuoteThe intermittent nature of the cost of renewal is highly significant economically for the reasons that I described earlier, especially for smaller companies. One of the real balancing challenges, that this, as part of a set of improvements, is intended to address, is the disparity between the cash flow of a small company and the cash flow of a large company. At present, it is very difficult indeed to make ends meet as a small company, and trivially easy to do so as a large company. Moblet discussed in some detail as long ago as 2011 some measures that were necessary to redress this, one of which being renewal costs: the important thing is that players are using the asset that will eventually have to be renewed for years (and all the while building additional sources of revenue) before having to meet the large capital payment for renewal. The focus on small companies may seem trivial given the huge companies that dominate the online game, but it is actually very significant: if things can be made relatively easy for new, small companies, the whole balance can be altered to make larger companies make a little less profit, ensuring that the financial challenge remains real even when a player has amassed a large network. Another piece of economic significance is that it is possible in the way that I describe above in to postpone renewals, which, although financially disadvantageous in the long term, can provide a temporary cash flow remedy in the short term for players that need it which would not be possible if the amortised cost of renewal had already been deducted monthly for the past (e.g.) ten years. There is a further problem balancing for fully amortised costs: historical maintenance figures are unlikely to be based on renewal costs, so calibrating using historical figures is unlikely to work if an amortised cost of renewal must be included.
Aiming a feature for such a rare specific case is kind of a waste of resources. Companies will spend most of their time being big, only small at the start. You either make profit at the start or you do not, deferring it 10 years in the end is pointless. Also is it 10 years? Maybe it will be 7.5 or perhaps 20 years.

QuoteThere remains the challenge of how to do this without making the game tedious or excessively difficult. Micromanagement of a repetitive type should be avoided, but players should be able to act efficiently. In particular, players should be able to use renewal as an opportunity to upgrade (in other words, renew with the upgraded waytype, or, in vehicles, to replace rather than overhaul). This is not possible where the amortised cost of renewal has already been deducted: the player would have to pay all over again to upgrade. This has the potential to make quite a significant difference for a player in terms of expenditure. (To answer Aquin's point, this would indeed require a pointer in each way tile to a waytype to which to upgrade, but this should not cause much difficulty, as it would not be accessed very often: raw memory usage is not a serious resource problem for Simutrans-Experimental on modern computers at present, unlike memory bandwidth).
Global replacements could be done as I mentioned before. On top of recording the wear of each tile every month, it also adds to a player based "total wear cost" value. Every time a train moves over a tile and produces "wear" on it, it computes the cost associated with that ware and adds it to a player based value similar to profit. This value could be real time and generated as the month progresses (people may argue why not just add it to running cost of the convoy) or it could be buffered and deducted at the end of month (probably more realistic and it becomes more like maintenance). It could even be regulated with some control algorithm so that it changes gradually over years to its correct value (to reflect that freshly laid track does not need immediate replacing).

You could then have some probability every month to work out the fraction of rails to upgrade. I believe there is an ownership list for ways (used when removing companies) which is what you would get the ways to upgrade from. That way rails could be phased out over a few years to make it more realistic. The random nature would be an issue but something is better than nothing (Island Hopper could really do with such a feature for his lines!).

QuoteIncidentally, as to the speed reduction, it would probably be sensible for vehicles to have a power reduction instead of a speed reduction when they are worn out, which probably reflects more accurately the effect on performance of being in poor condition. This would be in addition to the multiplied per kilometre costs to represent having to work harder to maintain the vehicle.
Should only apply between services. New motors or engines can be restored brining power back up. If the structure is damaged (aircraft is old) then a replacement is purchased, often with the engines of the old plane going on to become spare parts selling for quite a lot. Again this can work out as a monthly amount that each convoy costs to keep it working within a certain percentage of power. The main time maintenance should increase is after it becomes obsolete as then it does become harder to maintain since new parts are no longer available and re-conditioned parts might not perform as well due to mechanical wear or improvisation. A real life example could be a capacitor where by electrolytic ones have an end of life (usually they pop and fizzle) however until then the capacitance will remain within the designed range as specified by the data sheet. This should apply to vehicles I would imagine in that the quoted power is the power they promise to deliver over the intended usage period (between overhauls in which case the power would be restored).

This leaves only the annoying "send to depot" mechanic needed to overhaul engines and planes. If you ever played OpenTTD you will know just how annoying that is and what a disruption it can cause to your transport network. Sorry passengers from "Newton", you passengers will just need to be stranded for an hour odd as all my trains that were placed in service at about the same time have decided they need to be maintained so have stopped accepting passengers. Until (if?) there is a "off-peak" time simulation in Simutrans I would advise against this.

Ves

When the pop up window appears, add a time factor to it:
"Upgrade tracks/vehicles over the next [player specifies how many months] months"

This makes the player decide how much (s)he wants to spread out the costs, and in the convoy-situation also prevents all convoys to go at the same time.

The game just needs to be able to spread out the number of tiles or vehicles evenly during the months.

Aquin

Another thing to consider is the book value of a way. I think it should start with a value equal to its building costs, and a worn out way should hav a value of building costs - renewal costs.
The momentary value should be linked to the actual wear status, thus slowly drop with the way gradually being worn out. Otherwise companies, the small ones for sure but maybe even some large ones, will face a serious thread of bankrupcy if a major part suddenly loses 75% of its book value. As the net capital is the important figure for going bankrupt, not if there is some money in your account or not. But then renewal is just moving money from your cash account to the book value of your company, which doesn't affect net wealth at all. The important deduction from net wealth has already occured as the way lost value due to wear.

Spenk009

The big disagreements we have here it seems are:
1. Monthly deduction vs. renewal at end of life
2. Manual control to a certain degree over waytype renewal management
3. Penalties for badly maintained ways (monetary or power orientated)

Maybe we should vote for what we want (bearing in mind what is within reasonable scope for the beginner I am, if I am to work on the project).

My suggestion is that a vehicle will use its values (speed, weight, axle load, vehicle type) to determine how much damage it is doing and write that to the tile. Pros of this are: fast calculation(?) and simple coding necessitation another step in the function of the tile entering algorithm and adding a damage value with "stamina" to waytypes for wear.
At the end of the month, a window appears with the amount of tiles to be upgraded and their cost. This would be paid up to the credit limit, from which point on only higher used ways will be upgraded and un-upgraded ones receive a speed penalty (simply simulating a lower speed limit due to safety concerns). See attachment 1.
A gui tool that allows the player to automatically upgrade waytypes as renewal comes along or allows them to upgrade anyway. See attachment 2. Also have it pre-calculate all tiles could be convenient.
Pressing Alt or Shift to upgrade a way when renewing comes along.

I'm leaning towards the idea of having upgrades when the track wears out, because it would improve the start of a game too.

edit: I missed out on explaining the updater window, which would include "From:" and "To:" before the ways, an area of costs and tiles replaced, and a section to see the "orders" given to the updater tool in a list form to see what is being worked on.

jamespetts

Thank you all for your contributions to this interesting discussion. Firstly, I am afraid that presenting a player with a dialogue every month will not be workable: firstly, it will be annoying for players to have whatever they are doing interrupted fairly frequently by something demanding immediate attention, but secondly, and even more importantly, it will not work well in multi-player games when players might not be around at the month's end, or even for several months.

As to the question of amortisation, let me deal with Dr. Supergood's response:

QuoteAiming a feature for such a rare specific case is kind of a waste of resources. Companies will spend most of their time being big, only small at the start. You either make profit at the start or you do not, deferring it 10 years in the end is pointless. Also is it 10 years? Maybe it will be 7.5 or perhaps 20 years.

I suspect that I have not explained the reasoning as clearly as I might have done: my apologies. The point is that, as things are now, profit margins are big enough that big companies have practically infinite money, but it is very difficult starting out. The profit margins cannot be made any less, or else it would be impossible ever to get big companies, as they would become insolvent quickly. The disparity between the profit of small, new companies and large, established companies is too great (greater than realistic), and a number of mechanisms are needed to reduce this disparity. One of those mechanisms is renewal costs payable as a lump sum when things have worn out. The small, new company will not have to pay these until it has become a somewhat less small, somewhat less new company, when its profits are higher. (Companies that always intend to stay small will have to use lower maintenance ways whose renewal costs are less, such as light rail or the more basic types of road, etc.).

The result of this will be that (1) it will be a little easier to establish new companies; and (2) it will be more challenging to maintain existing, large companies. Any system of amortisation could not achieve both (1) and (2) at the same time, nor could it allow the cost of upgrading a way not to duplicate the cost of renewal, which is a very important mechanism in reality.

What is very important, however, is for players to be able selectively to mark certain ways for upgrading to a particular way type when it comes time for renewal by the means that I described earlier, as anything else would be either too blunt or require too much repetitive work by players ("micromanagement"*).

Quote from: DrSuperGoodhould only apply between services. New motors or engines can be restored brining power back up. If the structure is damaged (aircraft is old) then a replacement is purchased, often with the engines of the old plane going on to become spare parts selling for quite a lot. Again this can work out as a monthly amount that each convoy costs to keep it working within a certain percentage of power. The main time maintenance should increase is after it becomes obsolete as then it does become harder to maintain since new parts are no longer available and re-conditioned parts might not perform as well due to mechanical wear or improvisation. A real life example could be a capacitor where by electrolytic ones have an end of life (usually they pop and fizzle) however until then the capacitance will remain within the designed range as specified by the data sheet. This should apply to vehicles I would imagine in that the quoted power is the power they promise to deliver over the intended usage period (between overhauls in which case the power would be restored).

If by "services" here you mean overhauls, that was what I had in mind: it was only vehicles that were overdue for an overhaul that I had envisaged having increased per km maintenance costs and reduced power (and likewise ways overdue for renewal having increased monthly maintenance costs and a reduced speed limit owing to being in poor condition). However, the cost of the vehicle overhauls should increase over time (perhaps on the basis that each overhaul is more expensive than the last by x%). You refer to obsolescence; I had envisaged the current obsolescence system (based on time) being discontinued because the inflation modelling together with overhauls renders it unnecessary; the inability to obtain parts for older vehicles only applies in the last 50 or so years of the 260 year timeline of Pak128.Britain, as for most of the period they would simply have been made in the company's own workshops at cost price. The current obsolescence feature cannot be balanced using historical figures as the feature does not directly simulate any real life economic variable.

I should add that before anyone plunges into the unknown and starts coding any of this, we need to think very carefully indeed about exactly how the wear mechanism will work. Anything other than tonnes passed since last renewed is potentially very complicated and will need extremely careful and exacting thought to ensure that it is able to be balanced using only historical figures (rather than guesswork and/or exhaustive trial and error). What formula could we use to get from speed, weight, axle load and vehicle type to get to a percentage wear per convoy passing figure that accurately fluctuates such that using real life figures for speed, weight, axle load and vehicle type will produce (reasonably) realistic values for wear?

In any event, thank you everyone for your input, and especially Spenk009 for volunteering to work on coding: it is much appreciated.

* This term is perhaps a little inept, as "micromanagement" really means "managing small details", whereas what we are concerned with is players having to perform repetitive actions rather than take high-level decisions.
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.

DrSuperGood

#21
QuoteHowever, the cost of the vehicle overhauls should increase over time (perhaps on the basis that each overhaul is more expensive than the last by x%).
Except once you reach a certain point it does not cost more to overhaul something. There are only so many parts to replace before you replace the entire thing. Once you replace the entire thing you will not need to replace it anymore so it would go down. As such there would be an overhaul equilibrium around the life expectancy of the convoy where by further overhauls would not cost more as already the maximum number of parts to replace has been reached.

Obsolescence refers to the parts no longer being made. Since our company does not have a convoy factory one can assume it purchases them from other companies that build them. As such when a convoy obsoletes it becomes harder to get spare parts (need to be purpose made) so it would increase the costs. I know this is not what really happened but if you start to simulate the railway factories as part of your company then you need to introduce things like R&D costs and things.

Quote* This term is perhaps a little inept, as "micromanagement" really means "managing small details", whereas what we are concerned with is players having to perform repetitive actions rather than take high-level decisions.
Once a line is working I should never be bothered with it ever again until it needs to be upgraded. I do not even care if it needs line replacement since I factored that into the economics of the line.

QuoteThe result of this will be that (1) it will be a little easier to establish new companies; and (2) it will be more challenging to maintain existing, large companies. Any system of amortisation could not achieve both (1) and (2) at the same time, nor could it allow the cost of upgrading a way not to duplicate the cost of renewal, which is a very important mechanism in reality.
It only defers costs until X years later. If you are small or big you still need to eventually pay it and it still will work out as a monthly cost.

The issue with big companies having too much money is natural. That is how monopolies came about as the natural growth rate is exponential. Trying to change that to anything else would be unfair. The reason people end up with so much money is purely because they cannot spend it on reasonable things faster than they earn it. All you are offering here is "lets make it so each line you have earns less" which can be achieved simply by lowering shipment values of cargo or applying a tax. Raising micro and adding options to renew lines does not make the game deeper, it just provides you with choices that ultimately end up not affecting the game play much.

When I start out I have a good feeling what is profitable. When I make a line it makes profit. Sure with line renewal I will start out making more profit for a while and have periodic spikes for renewal but the fact is I made a line that makes profit. I do not stop to consider "oh dear maybe the line maintenance in either 5 or 25 years time (as I cannot calculate it) might result in less profit" as it will either make profit or not. If I make a line that does not make profit I will scrap it, start a new company and try again with a "better" line.

The simplest solution to that would be to allow players to donate to the public service provider for "economic development". That would act as the ultimate cash sink, especially once proper public service provider economics is built.

In real life all the money ends up going to private people who buy expensive cars, big houses and travel in first class or better. Since this is not the Sims you will need to think of a more altruistic end destination for all the extra profit.

Thus I provide you with the idea for 3 money sinks.

  • Donate to public service provider. Maybe even allow "funding" of expensive structures. Helps economic growth which in turn can bring more money or progress the map faster.
  • Incorporate some kind of company talent system similar to those from various RPGS. Pay money into it to unlock things improving your company in various ways from more efficient engines to unlocking certain convoy types. New companies start off somewhere around the average across all existing companies.
  • Give some idea of private ownership. The money you then pay yourself translates into silly statistics like "cars owned". Totally pointless but it would be pretty funny boasting "I own 279,000 cars and 50,000 mansions and 789 boats.

The game is meant to be about shipping stuff. I aim for high passenger/mail/production% as my goal of playing. I do not want to be bogged down concerning myself with thinking about line replacements which are hard to compute and will end up adding nothing next to another window and be a way to upgrade tracks (which could be a much simpler window). I would rather have railroads and trucks being viable for freight (currently they are not) than some way to defer costs when I start out. Or have some tool allowing me to join distant station parts instead of having to wastefully build and destroy long elevated sections of light rails to connect remote areas. Or have a metric showing how many timetable slots my line missed so I can get the right number of convoys on it without having to guess based on station statistics. Or have usable late game super container ships which do not haul less than wooden ones from the 1800s. Or have the ability to give bridges to the public service provider so that when I bulldoze vast rural areas I do not have to pay to keep them connected when I do not even own road vehicles. Or have usable horse pulled carts early game. Or have long distance "outside bounds" shipping. Or have single tile wide railway tracks. Or have a decent power mechanic. There are lots of other features that would add more to the game than having a window every month giving you various order options for replacing track which could be done from a single window when I wanted it and automatically deducted from my account every month.

Sarlock

Wonderful discussion, you've awakened the gamer/accountant/business owner in me.

From my experience in playing, the small company challenge (which, to me, is the most fun time) is due to other factors than those mentioned.

When starting out, it is a challenge to find a good initial network location that provides a high enough volume of goods to be profitable.  This is either due to existing players already tapping in to the good sources or due to the early game (especially 1750) providing very few viable options.  You have to carefully scan the map for open opportunities.  This is where player experience plays a huge part.  You have to know what will and won't work with the volumes and the convoy technology currently available.
When we started out on the big server map, milk and lumber were the two big earners.  The players that knew this, either from experience playing before, or from offline experimentation, made a very quick profit, while other players suffered and quickly went bankrupt.  Coal earned a reasonable return, but pretty much everything else was either low profits or completely unprofitable at the volumes and prices available.  Within a few years, we (mostly AEO and I) had captured the bulk of the available high profit freight lines.  We rolled in the profits while most other players struggled with failing pax/mail lines or low profit freight lines.
With this money I set up a losing mail/pax operation on the east island.  I knew it wouldn't make money at the volumes currently available, due to the small size of the cities at the time and the low demand in the 1700's, but it was important to establish claim over a continuous area and began the process of growing the cities.  By the mid 1800's, these mail/pax lines were generating as much or more profits than my freight lines.

What I am getting at is this: it's a combination of player experience/knowledge and time invested that will determine the bridge between the small and large companies.  The players that are good at analyzing the data and finding the most efficient combinations of cargo and convoys will become the big companies.  Whatever mechanics are put in place to help arrest this dynamic will largely fail, as it will still always favour those players/companies.

The more complex the economics become, the more little niches skilled players will find to exploit.  95% of the locomotives are useless, as their combination of operating cost, power and speed make them completely unviable.  Most of the ships have little to no use.  Road convoys are barely economical.  It's the players who can parse all this information and find the little advantages that can quickly come out ahead.  You can make the economics more complex, but this will only benefit those types of players even more, and serve to confuse and frustrate the players who are more casual or less experienced with the game.

Bottom line, as I see it, is to keep it super simple.  All of these mentioned costs can be captured with a simple fixed maintenance cost and fixed/variable convoy cost.  If desired, the fixed monthly infrastructure maintenance cost can be reduced and a variable component introduced -- rather than trying to perform a complex calculation and hordes of coding effort (and the bugs that result), just do a rough estimation: [total rail tonnage transported in the month / km of rail network] * multiplier.  Do the same for roads.  Ships and air if desired.  This lowers maintenance cost for small companies that do not have a high utilization rate for their network and increases it for larger companies that have a higher infrastructure utilization rate... and avoids adding a layer of complexity and confusion.

The more variables that are added, the more complex it becomes to try and balance the pakset.
Current projects: Pak128 Trees, blender graphics

Aquin

If you just want to nerf big companies, introduce admistrative costs for Lines, Stations, Vehicles, and make them scale with the number of similar item already owned. Like the first station costs 1$ per month, the 2. 2$, the 3. 3$ and so on. This will limit company size fairly fast.
All other things will be used by big and small companies alike, so playing around with that will not make a difference.

DrSuperGood

QuoteIf you just want to nerf big companies, introduce admistrative costs for Lines, Stations, Vehicles, and make them scale with the number of similar item already owned. Like the first station costs 1$ per month, the 2. 2$, the 3. 3$ and so on. This will limit company size fairly fast.
All other things will be used by big and small companies alike, so playing around with that will not make a difference.
The issue is there is no reason to limit company size. If you are playing single player and want to dominate the map shipping 100% of everything then you should be able to.

zook2

May I suggest a very small baby-step towards a solution: start simply with a statistics window telling the player how many tiles of each waytype he actually has, and how much each type costs in monthly maintenance. Currently there is no such information available (while you're at it, add a tab for vehicles, their total numbers and costs, and for other infrastructure). Do I own 5,000 or 50,000 miles of track in my (rather large) game? I have no idea.

That should give us an idea what numbers we're talking about. After all, you can't simulate high-level decision making without the necessary high-level information.

jamespetts

Thank you all very much for your helpful input in this connexion: it is much appreciated.

Let me deal with the various points discussed in turn. Firstly, I realise that I forgot to reply to Aquin's suggestion above of having wear affect the book value of ways (and presumably also vehicles). Whilst at first an attractive idea, this would require the game to keep track of every tile of each waytype and take into account its value in current building costs (remember, inflation is planned) and wear proportion. Instead, what might be more sensible is to use standard accounting methodology and assign a depreciation value for assets over time. I have not considered in detail how this might be done, however.

Quote from: DrSuperGoodExcept once you reach a certain point it does not cost more to overhaul something. There are only so many parts to replace before you replace the entire thing. Once you replace the entire thing you will not need to replace it anymore so it would go down. As such there would be an overhaul equilibrium around the life expectancy of the convoy where by further overhauls would not cost more as already the maximum number of parts to replace has been reached.

Yes, this does make sense: the increasing cost of overhauls ought to be capped after a fixed number of overhauls.

QuoteObsolescence refers to the parts no longer being made. Since our company does not have a convoy factory one can assume it purchases them from other companies that build them. As such when a convoy obsoletes it becomes harder to get spare parts (need to be purpose made) so it would increase the costs. I know this is not what really happened but if you start to simulate the railway factories as part of your company then you need to introduce things like R&D costs and things.

Parts no longer being made (implying that they were mass produced to start with) is a very modern phenomenon. No 18th century canal boat would become obsolete because people stopped making wooden planks, tar, paint or nails. This is not really relevant until well into the 20th century, before which parts, even for vehicles made for outside contractors, could easily be fabricated in any workshop from the drawings. This greater increase in overhaul costs for older equipment might be reflected simply in a greater number of overhauls before the cap is reached in the system as described above.

QuoteIt only defers costs until X years later. If you are small or big you still need to eventually pay it and it still will work out as a monthly cost.

This deferral is important: if one has to pay Yc now as opposed to Yc in X years' time, one loses the ability to invest that money in the meantime and have it put to work to earn a substantial return upon it. This can make a big difference.

It is definitely not financially identical to a monthly cost. If you had a choice of two loans, both of £1,200 and at a nominal 10% rate of interest, one where you could pay back £1,320 in a lump sum in a year's time and one where you had to pay back £110/month for a year, which would you think better value? (This is why lenders are legally required to show an "APR" which would definitely not be as low as 10% for the second loan).

QuoteThe issue with big companies having too much money is natural. That is how monopolies came about as the natural growth rate is exponential. Trying to change that to anything else would be unfair. The reason people end up with so much money is purely because they cannot spend it on reasonable things faster than they earn it. All you are offering here is "lets make it so each line you have earns less" which can be achieved simply by lowering shipment values of cargo or applying a tax. Raising micro and adding options to renew lines does not make the game deeper, it just provides you with choices that ultimately end up not affecting the game play much.

There is nothing wrong in principle with big companies having plenty of money: but in reality, even the largest transport companies did not have the practically infinite financial resources that they have in this game. Even the Grand Junction Canal Company, the LNWR, Cunard, BOAC and Eurotunnel did/do not have the ability to purchase all the transport equipment that they could possibly want without regard to cost, and this is not just because shareholders want to be paid: this is and was so even for state run companies such as British Rail and British Airways (and even state run transport companies in countries which give a higher priority to state spending: the SNCF has never been able to build high speed lines to everywhere in France all at once). The aim is simply to impose realistic financial constraints on larger companies, by reducing profit margins generally, which is possible without making it impossible to start by allowing smaller companies, in effect, more time in which to pay a sizeable chunk of their operating costs.

QuoteThe simplest solution to that would be to allow players to donate to the public service provider for "economic development". That would act as the ultimate cash sink, especially once proper public service provider economics is built.

Incidentally, something similar to this is also planned: a tax on company profits to be paid to the public service player. The unlocking idea I am not fond of, as it seems arbitrary and does not simulate any specific real life state of affairs.

QuoteThe game is meant to be about shipping stuff. I aim for high passenger/mail/production% as my goal of playing. I do not want to be bogged down concerning myself with thinking about line replacements which are hard to compute and will end up adding nothing next to another window and be a way to upgrade tracks (which could be a much simpler window).

I am not sure quite what you mean by this. What I propose will in many cases mean: (1) automatic upgrades for ways where currently this has to be done manually; and (2) (ultimately) cheaper way and vehicle replacements.

I should add that I consider asset management, provided that it is stripped of repetitive tasks, is quite a fun thing in itself. It is a big part of real life transport planning (e.g., "we need to upgrade the Western route sometime within the next 5-10 years, but some of the rolling stock on it is quite new, so we need to consider whether to let it run for another 10 years, cascade it to another route (in which case we need to give the same consideration to the stock already on that route), or sell it now to another company, if there's someone willing to buy this sort of equipment; but the track needs renewing soon, and we need to decide whether to use the heavy weight track or the medium weight track to replace the existing track, and that will depend on what rolling stock will be using the route", and so forth).

QuoteI would rather have railroads and trucks being viable for freight (currently they are not) than some way to defer costs when I start out. Or have some tool allowing me to join distant station parts instead of having to wastefully build and destroy long elevated sections of light rails to connect remote areas. Or have a metric showing how many timetable slots my line missed so I can get the right number of convoys on it without having to guess based on station statistics. Or have usable late game super container ships which do not haul less than wooden ones from the 1800s. Or have the ability to give bridges to the public service provider so that when I bulldoze vast rural areas I do not have to pay to keep them connected when I do not even own road vehicles. Or have usable horse pulled carts early game. Or have long distance "outside bounds" shipping. Or have single tile wide railway tracks. Or have a decent power mechanic. There are lots of other features that would add more to the game than having a window every month giving you various order options for replacing track which could be done from a single window when I wanted it and automatically deducted from my account every month.

None of these things are mutually exclusive. Some of these things are planned (including, eventually, "outside bounds" transport for both passengers and freight, which would greatly enhance the air and sea related aspects of the game: we could actually find a proper use for ocean liners and Concorde), and some of these things (such as having viable freight rail and road networks) depends on balancing, which can only be done when planned economic changes, including this one, are complete.

(Incidentally, what do you mean by, "have some tool allowing me to join distant station parts instead of having to wastefully build and destroy long elevated sections of light rails to connect remote areas"? I do not fully understand this. Perhaps you could start a new thread to set out your thoughts?)

Incidentally, if you have lots of interesting feature ideas, I do encourage you to have a go at implementing some of them yourself. I get the impression that you have a good knowledge of IT and programming, and I very much doubt that you have much less spare time than I have.
Wonderful discussion, you've awakened the gamer/accountant/business owner in me.

From my experience in playing, the small company challenge (which, to me, is the most fun time) is due to other factors than those mentioned.

When starting out, it is a challenge to find a good initial network location that provides a high enough volume of goods to be profitable.  This is either due to existing players already tapping in to the good sources or due to the early game (especially 1750) providing very few viable options.  You have to carefully scan the map for open opportunities.  This is where player experience plays a huge part.  You have to know what will and won't work with the volumes and the convoy technology currently available.
When we started out on the big server map, milk and lumber were the two big earners.  The players that knew this, either from experience playing before, or from offline experimentation, made a very quick profit, while other players suffered and quickly went bankrupt.  Coal earned a reasonable return, but pretty much everything else was either low profits or completely unprofitable at the volumes and prices available.  Within a few years, we (mostly AEO and I) had captured the bulk of the available high profit freight lines.  We rolled in the profits while most other players struggled with failing pax/mail lines or low profit freight lines.
With this money I set up a losing mail/pax operation on the east island.  I knew it wouldn't make money at the volumes currently available, due to the small size of the cities at the time and the low demand in the 1700's, but it was important to establish claim over a continuous area and began the process of growing the cities.  By the mid 1800's, these mail/pax lines were generating as much or more profits than my freight lines.

That is interesting, but this, too, ought to be solved once other balancing issues are dealt with (including the extremely challenging issue of how to put a stop, in a realistic and practical way, to the massive profits generated by the intercontinental milk trade which could never have existed in reality: one possibility that has just occurred to me is simply to make milk and other perishables give a very low rate of return for longer distances, something which uses the existing fare stages feature and would only require small changes to the pakset).

The issue is that many of the issues that you describe are related to a basic lack of cost balance. This can only be solved once planned features have been implemented that will drastically affect balancing, as balancing is a gargantuan task and it would be insane to have to do it more than once. Also, adding these realistic features makes it much easier to balance from historical data in the first place, as I can simply convert the figures directly rather than have to find a way of factoring in additional types of costs not shown in real life figures for, e.g., regular maintenance.

Quote from: SarlockWhat I am getting at is this: it's a combination of player experience/knowledge and time invested that will determine the bridge between the small and large companies.  The players that are good at analyzing the data and finding the most efficient combinations of cargo and convoys will become the big companies.  Whatever mechanics are put in place to help arrest this dynamic will largely fail, as it will still always favour those players/companies.

The more complex the economics become, the more little niches skilled players will find to exploit.  95% of the locomotives are useless, as their combination of operating cost, power and speed make them completely unviable.  Most of the ships have little to no use.  Road convoys are barely economical.  It's the players who can parse all this information and find the little advantages that can quickly come out ahead.  You can make the economics more complex, but this will only benefit those types of players even more, and serve to confuse and frustrate the players who are more casual or less experienced with the game.

The reason that so many locomotives are useless is that there has been no significant attempt at cost balancing yet for the reasons given above. A more realistic economy and a (much) more accurately balanced pakset will, in some ways, make it easier, as players will only have to understand what would work in real life, rather than have a detailed understanding of the quirks of the game, as it is now. In that way, additional complexity, provided that it does not make it much more labour intensive for a player to interact with, has the potential, if done correctly, to have the opposite effect to that which you envisage. This has always been the design philosophy of Simutrans-Experimental, and it is quite fundamental to the way in which I approach design decisions.

Quote from: AquinIf you just want to nerf big companies, introduce admistrative costs for Lines, Stations, Vehicles, and make them scale with the number of similar item already owned. Like the first station costs 1$ per month, the 2. 2$, the 3. 3$ and so on. This will limit company size fairly fast.
All other things will be used by big and small companies alike, so playing around with that will not make a difference.

This would not be very realistic, and is also not the intention: see above.

QuoteMay I suggest a very small baby-step towards a solution: start simply with a statistics window telling the player how many tiles of each waytype he actually has, and how much each type costs in monthly maintenance. Currently there is no such information available (while you're at it, add a tab for vehicles, their total numbers and costs, and for other infrastructure). Do I own 5,000 or 50,000 miles of track in my (rather large) game? I have no idea.

That should give us an idea what numbers we're talking about. After all, you can't simulate high-level decision making without the necessary high-level information.

This is a good idea in principle, but might be tricky to implement programatically. It may be worth considering, though.
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.

zook2

QuoteThe simplest solution to that would be to allow players to donate to the public service provider for "economic development". That would act as the ultimate cash sink, especially once proper public service provider economics is built.

QuoteIncidentally, something similar to this is also planned: a tax on company profits to be paid to the public service player. The unlocking idea I am not fond of, as it seems arbitrary and does not simulate any specific real life state of affairs.

I'm always a bit skeptical about the "realism" argument when it comes to a game of such complexity as this. How much tax did a British stagecoach or shipping company pay in 1750? None. A hundred years later, maybe 5%. I can't say how much it would be today (even excluding the myriad loopholes in modern tax laws), but realism isn't the main point here, I think. Making the game more fun is.

If I recall correctly, Railroad Tycoon handled this problem by introducing variable "company overhead", which was basically the same idea as this "public tax" under a different name. The bigger you are, the more money just somehow evaporates, preventing you from buying the entire world after 20 years in business.

DrSuperGood raised the point of private ownership (the 279,000 cars and 50,000 mansions and 789 boats). IMO that could be they key here. Right now, all Simutrans companies are state-run because nobody ever withdraws any capital. Now let's say your company's dividend payments affected it's ability to raise capital for expansion. You begin with £200,000 and build a small network. Do you manage to pay 3% above inflation (almost non-existent in the old days), or 5%? The former means you aren't fired. The latter means you can attract another 200,000. If you guarantee 10% ROI (above inflation), you'll attract enough money to guild your locomotives (as well as your 789 boats).

Simutrans shouldn't become a stock market simulation, but a simple enough bonds system could bring some realism into the economic aspects of the game and slow down growth. To grow faster than at a snail's pace, you have to finance more debt.

jamespetts

Quote from: zook2 on November 16, 2014, 10:29:50 PM
I'm always a bit skeptical about the "realism" argument when it comes to a game of such complexity as this. How much tax did a British stagecoach or shipping company pay in 1750? None. A hundred years later, maybe 5%. I can't say how much it would be today (even excluding the myriad loopholes in modern tax laws), but realism isn't the main point here, I think. Making the game more fun is.

If I recall correctly, Railroad Tycoon handled this problem by introducing variable "company overhead", which was basically the same idea as this "public tax" under a different name. The bigger you are, the more money just somehow evaporates, preventing you from buying the entire world after 20 years in business.

DrSuperGood raised the point of private ownership (the 279,000 cars and 50,000 mansions and 789 boats). IMO that could be they key here. Right now, all Simutrans companies are state-run because nobody ever withdraws any capital. Now let's say your company's dividend payments affected it's ability to raise capital for expansion. You begin with £200,000 and build a small network. Do you manage to pay 3% above inflation (almost non-existent in the old days), or 5%? The former means you aren't fired. The latter means you can attract another 200,000. If you guarantee 10% ROI (above inflation), you'll attract enough money to guild your locomotives (as well as your 789 boats).

Simutrans shouldn't become a stock market simulation, but a simple enough bonds system could bring some realism into the economic aspects of the game and slow down growth. To grow faster than at a snail's pace, you have to finance more debt.

I don't think that we need to simulate the detailed intricacies of corporation tax: a flat percentage that can be altered (up to a limit) by the public player should suffice.

Incidentally, the mansions, luxury cars, etc., to which you refer are really in the category "cost of capital". That is another of the planned features, and is something similar to the bond system that you describe. This is intended to be as well as, rather than instead of, renewal/overhaul costs, however.
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.

DrSuperGood

QuoteI don't think that we need to simulate the detailed intricacies of corporation tax: a flat percentage that can be altered (up to a limit) by the public player should suffice.
Maybe allow players to add to that percentage with their own positive amount. In the case of a player who literally has nothing else to do with his money (as he is managing to build up quite a bit of profit) it would be a viable money sink that could help the overall map develop. Additionally the amount could be dynamic to some extent if there is ever a case that the public player cannot spend all the tax it earns (no point charging tax if it has nothing to spend it on such as if the map is fully developed and has huge tax income).

jamespetts

Quote from: DrSuperGood on November 17, 2014, 12:54:05 AM
Maybe allow players to add to that percentage with their own positive amount. In the case of a player who literally has nothing else to do with his money (as he is managing to build up quite a bit of profit) it would be a viable money sink that could help the overall map develop. Additionally the amount could be dynamic to some extent if there is ever a case that the public player cannot spend all the tax it earns (no point charging tax if it has nothing to spend it on such as if the map is fully developed and has huge tax income).

That is an interesting idea which can be considered in more detail when it comes time to implement the tax system.
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.

Sarlock

Ultimately what we are discussing is a way to flatten out an exponential curve.  The initial few lines a player establishes determines how quickly they rocket up in to this exponential profit growth (or go bankrupt).

"Real" companies do not experience this exponential growth in the form of growing cash reserves like we do in Simutrans.  This is because in the real world there are many more options for investing this excess cash: dividends, stock buybacks, taxes, acquisitions of companies outside of our primary investment sphere (railroad companies buying hotels, etc), and other options.  It is generally inefficient for a company to hold excess cash that has no immediate investment function (unless you're Apple) and more effective to put this cash to work in some other investment and then fund future growth with debt rather than cash.  Given that most of these mechanisms are absent in Simutrans, we are left with an ever-growing mountain of cash in our pockets.  Publicly owned railroads are generally not allowed politically to amass much cash or profits -- so they always find ways to keep them in line (or else their government owners skim it all!).

A graduated tax system that kicks in after, perhaps, 10-20 years of company operation, may assist in this matter, but the tax would have to be very aggressive to have any effect -- once a company has cash reserves of a sufficient size, even if you taxed them 75% of future profits, it would have no effect on their future operations.  It will have to be carefully designed to be effective, otherwise it will just be an irritating nuisance but have no limiting effect on large companies.  The system will also have to have a limited to no effect on small companies, otherwise we've inadvertently impacted small companies more than the large ones.

The track maintenance fees, while interesting, may not have the intended effect.  A large company owner won't even consider the impact of the cash hit, whether evened out or in one large sum, because their cash reserves will be sufficient to absorb any shock.  A small company just starting out, however, will have to very carefully plan for any cash hits in the future, as they may have the potentially to negatively affect their viability.
Current projects: Pak128 Trees, blender graphics

jamespetts

There are a great many relevant factors in the decision to have wear based costs, and to have them payable in a lump sum. There is what you describe as the flattening of an expontential curve, which is relevant both in the timing of the payments, as discussed previously, but also in the relationship between the cost and the intensiveness of use, which has not been discussed so far: smaller companies with less of a network are able to make only less intense use of their assets than large companies, so, where intensiveness of use is not reflected in cost, large companies are given an unrealistic advantage over small companies. This, too, I recall, was mentioned by Moblet as a reason back in 2011 for having a system such as this.

Also, as is discussed above, is the issue that asset management is an element of gameplay in itself: players might decide to withdraw a service entirely when the vehicles on it or the ways on which it runs need overhauling or reewing rather than overhaul, replace or them, as in real life: players may take the decision to do something different at the point of renewal (to electrify, for example). Less used vehicles and lightly used ways might last much longer than their more heavily used counterparts (and might need to last longer in order to provide adequate return on investment). Companies unable to finance investment in renewals or overhauls might have to struggle on with ageing equipment for a time, reducing the quality of service in the process.

There are thus a number of aspects of the proposed renewal/overhaul cost system that go beyond flattening the exponential curve. There are also ways of flattening the exponential curve that go beyond the proposed renewal/overhaul cost system. There is the enhanced version of the alternative destination system for passengers that is already finished in the way-improvements branch that should limit the exponentiality of passenger network growth. There is the idea of taxation (although I am not convinced by the idea of having a 10-20 year moratorium on new companies: this is unrealistic and arbitrary, and could lead to perverse incentives in the game whereby certain routes, for example, are profitable only if run by a new company). There is the plan for inflation to be simulated to dissipate the real value of cash reserves over time (and, indeed, variable inflation of different things that might well cause things that were formerly profitable to cease to be profitable merely as a result, for example, of the rising cost of labour, as with trams in the 1920s).

All of the various planned projects form between them a web of interlocking ideas which, together, will (hopefully) produce a realistically balanced economy and an enjoyable and interesting game.
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.

DrSuperGood

QuoteAlso, as is discussed above, is the issue that asset management is an element of gameplay in itself: players might decide to withdraw a service entirely when the vehicles on it or the ways on which it runs need overhauling or reewing rather than overhaul, replace or them, as in real life: players may take the decision to do something different at the point of renewal (to electrify, for example). Less used vehicles and lightly used ways might last much longer than their more heavily used counterparts (and might need to last longer in order to provide adequate return on investment). Companies unable to finance investment in renewals or overhauls might have to struggle on with ageing equipment for a time, reducing the quality of service in the process.
Except most time spent in multiplayer games is when you are not playing and someone else is. How do all these decisions get made if the owner is not there to make them? I mean who is there to order a renew or even look at the renew statistics most of the time?

You cannot have companies change too fast. Some times they might be left alone for 1-2 years during which time all kinds of things could happen to them if you make things too dynamic.

jamespetts

Quote from: DrSuperGood on November 18, 2014, 04:39:59 AM
Except most time spent in multiplayer games is when you are not playing and someone else is. How do all these decisions get made if the owner is not there to make them? I mean who is there to order a renew or even look at the renew statistics most of the time?

You cannot have companies change too fast. Some times they might be left alone for 1-2 years during which time all kinds of things could happen to them if you make things too dynamic.

The idea is that renewals of track and overhauls of vehicles will be automatic, so they will not need to be ordered manually. Where an upgrade is needed, this will be able to be set in advance to apply automatically upon the point of needing overhaul/renewal (for example, by shift-dragging new ways over old so that they are replaced with the new way at the point of renewal being required rather than immediately). It should also be possible to suspend vehicle overhauls individually by line or convoy.
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.

Sarlock

Quotealthough I am not convinced by the idea of having a 10-20 year moratorium on new companies: this is unrealistic and arbitrary, and could lead to perverse incentives in the game whereby certain routes, for example, are profitable only if run by a new company

It's not uncommon for new companies to get a tax break when starting out, especially where the added service(s) would be of economic benefit to the area served.

Taxes would not make a profitable line unprofitable - it only serves to make them less profitable.  A line with marginal profitability would have little to no taxation while a line that is unprofitable would be untaxed completely.

I echo some of DrSuperGood's thoughts, especially on the multiplayer front.  Making new lines and connecting new industries/cities is fun.  Routine maintenance is generally tedious and boring.

I am concerned that we are overcomplicating the economic model by adding things that can be just as effectively simulated with the existing systems in place.
Current projects: Pak128 Trees, blender graphics

Vladki

There was a short discussion in another thread about headquarters for pak128, about making them something more than voluntary money sink...

I think that the bigger companies have bigger overhead - more employees need more bosses and managers and they need higher salaries more benefits etc etc. This could be simulates by forcing companies to upgrade headquarters or to upgrade them automaticaly and incease the overhead costs automaticaly.

The main question is what should indicate how big the company is. Number of lines? Convoys? Stations? Length of tracks? Cash? Income? Cargo delivered ton*km/month?

Sent using recycled electrons.


DrSuperGood

QuoteI think that the bigger companies have bigger overhead - more employees need more bosses and managers and they need higher salaries more benefits etc etc. This could be simulates by forcing companies to upgrade headquarters or to upgrade them automaticaly and incease the overhead costs automaticaly.
Employees are directly proportional to company size. However the issue is that they are already factored in the maintenance and running cost of convoys and structures.

Although pay does increase for managers in larger companies, once can assume that you own 100% of your company and are the only manger getting paid anything special.

That said, you could force headquarter size based on profit per month. Without a suitably sized headquarter for your profit you incur a percentage profit penalty due to "inefficiency" which may get worse as the amount of profit rises (possibly to >100% causing you to never be able to make money). Eventually you reach a point where upgrading headquarters becomes a cost saving as the reduction in inefficiency (possibly to 0%) is worth the extra cost. Efficiency as a whole could be modelled with not only headquarters but the need for offices if you are really big and the headquarter cannot cope alone. It could also be open ended where the last headquarter upgrade gives you 0% inefficiency no mater how much profit you make.

zook2

Perhaps it would be best to keep it as simple as possible by having your CFO pay out a certain percentage of profits as dividends each quarter, or each year. Early on, investors understand that your company's goal is to grow and that you cannot pay much. Also, net losses equal no dividends that quarter. Later on, your industry behemoth is expected to take care of many, many rich widows and orphans. Say good-bye to 50% of your earnings. And the board, representing the shareholders, takes the weight of the decision off your shoulders, setting the payout rate automatically and without asking the CEO's (your) opinion.

Sarlock

I foresee this as the best solution to the issue, and the easiest to implement and understand.  A dividend rate that takes into account the past 5 years' earnings and sets a rate accordingly.  If the current year runs negative, then the dividend is suspended, to preserve cash.  This encourages the player to not accumulate cash and instead employ it, unless earnings are so healthy that there is no alternative but to let them accumulate and be paid out in aggressive dividends.

Combined with a public player directed taxation system, this would largely address the issue and act as a brake on large company excess cash accumulation.  And, as a bonus, it is entirely realistic and completely missing from the game currently.
Current projects: Pak128 Trees, blender graphics

zook2

Perhaps dividends shouldn't be dependent on earnings alone, but on changes in company net value. Otherwise, I'd spend my excess cash on a fleet of steamships and keep them in the depot, either for use at a later time or simply as a money sink to keep the cash in the company.

Sarlock

Adding the fixed maintenance cost for convoys would fix that.  I believe this is already in place, just needs to be added to the pakset.
Current projects: Pak128 Trees, blender graphics

DrSuperGood

Dividends could be based on the a certain type of profit (before construction/new vehicles but after maintenance/overhaul/running cost). This way you cannot exploit it by tying up profit in assets.

However I still think throwing it all out in tax and office overhead would be more fair.

Or maybe people could be given the choice of different sorts of company? I mean if they are state run then then their profits are taken 100% by the public service provider but every month they are given a budget based on their haulage performance (especially for passenger/mail, cargo less so). The main advantage of this sort of company is that making money is less important compared with haulage percentage as the public service provider can even take up some of the bill if you are providing good service.

A public traded company has to pay dividends from its profit. It also has issue buying assets as a result (less capital to spend) but has a new option to "rent" assets instead. Rented assets have a large monthly cost (the rent) but can easily be replaced or changed out for a small fee (representing the abrupt termination of a rent contact). The main advantage of these companies is their cheap way to upgrade convoys and their large starting capital allowing for huge initial growth. This sort of company should probably get bonus for hauling freight and mail while a slight penalty for hauling passengers (comfort maybe? such companies usually skrimp and save where possible which affects comfort).

A private company could keep all the profit however operate at a cost penalty (so making money is harder) representing fewer business connections and worse deals. Some lines which are profitable with the other two company types are not profitable with this as a result. It also has less starting capital but can buy convoys. It also gets a bonus when it comes to convoy maintenance being cheaper (since you own your convoys, you make sure that they are well maintained so they last longer).

Adding 3 distinct company play styles could be a great direction for the game. They might be differently defined than above but with each having distinct advantages and disadvantages would encourage people to specialize on certain areas rather than being a jack of all trades. Someone going a state run company would probably start off with building up a passenger network and every month or so adding new routes to it. A public traded company might want to start by rapidly expanding to several industries with a shipping network or freight network. Where as a private company might be for people who only want to play with a small company such as an island or maybe specialize on certain aspects such as only going timber products.

zook2

I'm dreaming about designing a large scenario where the player is in charge of the Transsiberian Railway in the late 1940's and has to deliver a certain amount of steel to Irkutsk every year or risk getting shot in the neck. After all, that's how a large SimEx game feels to me after a while. You need to set yourself goals when money is no object. (By the way, is there an overview somewhere of what you can do with scenarios?)

But while I absolutely agree that your idea for different company types would greatly enhance the game, it sounds like a balancing nightmare to get this right. It's probably a looong way off.

DrSuperGood

QuoteBut while I absolutely agree that your idea for different company types would greatly enhance the game, it sounds like a balancing nightmare to get this right. It's probably a looong way off.
Everything is a long way off if nobody does anything. For example JIT2 in standard used to be nothing more than people stating possible improvements while now it might eventually be incorporated into standard main.

The issue is there is far too little testing and far too little resource available. Ultimately what needs to be done is to try out all the ideas mentioned and then evaluate which is most fun. Even if one fails, you can revise it and improve. That is the development cycle at work, something lacking a bit recently due to lack of resources.

jamespetts

Quote from: DrSuperGood on November 21, 2014, 10:01:18 PM
The issue is there is far too little testing and far too little resource available. Ultimately what needs to be done is to try out all the ideas mentioned and then evaluate which is most fun. Even if one fails, you can revise it and improve. That is the development cycle at work, something lacking a bit recently due to lack of resources.

This indeed is the critical issue. Simutrans (both Standard and Experimental) is fantastically complex and there are very few people working on it. I am the only person working regularly on Experimental, although others have provided enormous amounts of assistance intermittently. I work full time and am entirely self-taught in programming (and do not have a software engineering background). This means that things are extremely slow, even not taking into account my current house move which makes it very difficult for me to concentrate on other large projects such as Simutrans (I should have more time to start catching up once I actually move in, but it is a slow process).

There needs to be a clear roadmap with design decisions taken before implementation decisions. In this case, the design decisions for overhauls, etc., were taken as long ago as 2011. The livery system is currently incomplete, and was always designed with overhauls in mind back when it was first introduced in 2011. Routinely changing course on something already decided would mean that no progress at all would be made, rather than merely very slow progress.

Overhauls and renewals will not by themselves balance the game, but they are one of many measures that are intended to do so. They will not require players to become involved in mere routine maintenance: just the very major overhauls that are a significant capital expense. Even these will be automated, intervention only being necessary if the player is short of money or is planning an upgrade in the future. The renewal system of ways will in some cases reduce the need for player intervention to replace obsolete ways.

Renewals and overhauls are intended to introduce new and interesting dynamics and things for players to consider without requiring the player to undertake tedious, repetitive work. Having assets that deteriorate with use will make a real difference to strategic decision-making in many aspects of the game, of which I have given a few examples above.

I should very much like if there were more resources in programming available to us, and anyone who would like to contribute is encouraged to do so.
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.

jamespetts

Returning to this issue again, I am in the process of designing a model for a wear based way renewal system, which I am planning to code in the coming weeks. I will describe this in some technical detail as that has been the focus of the discussion so far.

Each way tile will have an unsigned 32 bit integer value representing its condition. New ways will have a condition value of the maximum value of a 32-bit unsigned integer. When a way reaches 0, it will become unusable. These values will be reported to the player as percentages. When a way tile reaches 15% (or some alternative figure set in simuconf.tab), it will be automatically renewed (if the player has the money and has not disabled this), or otherwise will be treated as being in a degenerate state and will have a speed restriction imposed upon it of 60% of the normal speed limit, or some other figure as may be specified in simuconf.tab.

Each vehicle will report a value of "Standard Axles". That value will either be specified directly in the .dat file or to be calculated from the axle load in default thereof using a power specified in simuconf.tab per waytype (default: 4 for road, 1 for rail, 0 for water; rail has a linear relationship and water experiences no wear). This is based on research into the "forth power law" said to apply to roads, where an increase in axle load of X results in an increase in wear of X^4. There is no equivalent for rail, it seems, but some sources indicate a linear relationship or a lower degree of a progressive relationship (which can be represented with a power of 1 or 2).

Each convoy, when it changes its assemblage, will calculate a global convoy SA value. Each waytype will specify a number of standard axle passes before condition reaches zero (the SA capacity).

Each convoy passing over the way will deduct an appropriate number from the condition value based on the proportion of its SA rating to the way's SA capacity.

This system should allow SA values to be set in the vehicles' .dat files or left to be deduced by the program based on axle load, allowing basic vehicles to have their SA values calculated automatically, while vehicles with more complex requirements (such as steam locomotives with varying hammer blow) to have the values set manually.

There are some good data for calibrating this for roads: see:
http://www.pavementinteractive.org/2014/06/02/pavement-design-whats-my-structural-number/
http://www.pavementinteractive.org/article/equivalent-single-axle-load/
http://www.pavementinteractive.org/wsdot-esal-application/
http://www.kent.gov.uk/__data/assets/pdf_file/0012/13035/Making-it-Happen-Road-pavement-design-guide-July-2000.pdf

Road strengths are measured in "msa" in the UK, "msa" standing for "million standard axles". They are designed for a lifespan of 20-40 years (20 years being more common now). A "standard axle" is one of 8.0t, so a 16t lorry with 2 axles (such as the Leyland DAF 65 in Pak128.Britain) would exert a wear of 2 SAs. For other axle loads, the SA value is calculated by the fourth power law. Modern roads, of thin stone mastic asphalt, introduced in around the mid 1990s, and which is about 25% more hard wearing than traditional hot rolled asphalt, have msa values ranging from 0.5 for light roads to 30 or even 50 for the most heavily used roads. This means that, in their 20 year lifespan, the roads will take 500,000 - 20,000,000 standard axle passes before needing replacement.

For Simutrans-Experimental, some conversion is needed because of the timescale. At Pak128.Britan-Ex standards, 3.75 months = 1 day. However, this is a day without a night. Assuming 16 active hours in a day, this is closer to 2.5. 2.5 * 365 = 912.5 months per year, or 76 months per month. Real world msa values must therefore be divided by 76 to get to the equivalent in Pak128.Britain-Ex.

One must then account for the bits per month and meters per tile for which these things must be adjusted. Months are about 2x as long as they would be at default settings. The configuration files must therefore divide msa value by 152 (76 * 2) to get the number of standard axle passes for Simutrans-Experimental. That would produce:

Very heavy road, 50msa: 328,947 (50,000,000 / 152) SA
Heavy road, 30msa: 197,368 (30,000,000 / 152) SA
Medium heavy road, 20msa: 131,579 (20,000,000 / 152) SA
Medium road, 10msa: 65,789 (10,000,000 / 152) SA
Medium light road, 5msa: 32,894 (5,000,000 / 152) SA
Light road, 2msa: 13,158 (2,000,000 / 152) SA
Very light road, 0.5msa: 3,289 (500,000 / 152) SA

The Leyland DAF65 in the game has an 8t axle load, and 2 axles. This vehicle is therefore 2x SA per pass.

This would equate to the following:

50msa = 164,473 lifetime passes
30msa = 98,684 lifetime passes
20msa = 65,789 lifetime passes
10msa = 32,894 lifetime passes
5msa = 16,447 lifetime passes
2msa = 6,579 lifetime passes
0.5msa = 1,644 lifetime passes

For a 20 year life, this equates to:

50msa = 685 passes/month or 107 passes/hour
30msa = 411 passes/month or 64 passes/hour
20msa = 274 passes/month or 43 passes/hour
10msa = 137 passes/month or 21 passes/hour
5msa = 68 passes/month or 10 passes/hour
2msa = 27 passes/month or 4 passes/hour
0.5msa = 6.85 passes/month 1.07 passes/hour

This suggests that we do need some new road types (light/medium/heavy hot rolled asphalt, light/medium/heavy stone mastic asphalt, perhaps; or at least medium/heavy of each, leaving the lightest roads to the "tarmac" type currently in the game), which could be produced by varying the tone of the images in the GIMP without producing new images (using the traditional idiom of lighter colours equating to better ways, which has been applied successfully for rail).

I should be interested in any feedback from users (especially those who use a lot of road transport in the modern era) of whether anywhere near the wear scenarios described above for the medium and higher strength roads are likely to be encountered in actual use, and whether we need to calibrate the SA passes rather lower as a result to give a realistic lifespan.

Calibrating this for rail is harder as there is less information. This old book suggests that wear based costs are about half of the total cost of rail maintenance, the remaining cost effectively being fixed, albeit that was for conditions in the first decade of the 20th century. I suspect that the ratio for roads will be more weighted in favour of wear based costs (75%, perhaps?), although I have not found any data on this. Any such data would be most welcome.

This paper suggests that there might be some power law in effect for rail wear, but the current research is said to be inconclusive, and it refers to other sources that indicate a linear relationship. If anyone has any useful information in this respect, that, too, would be most welcome. I might have to back-calculate from the axle load limit for rail to work out what would be an unreasonably short lifetime to calculate the SA tolerance (e.g., if rail type X has an axle load limit of 12t, infer that this is so because, at its SA rating, it would deteriorate with only Y passes at > 12t, Y being so small as to make it highly undesirable/unsafe to use the railway with such rapid deterioration); any thoughts on a sensible formula would be most welcome.

Edit: Incidentally, this is the thread in which Moblet suggested the ideas that are the basis of this work. The most relevant part is the following:

Quote from: moblet
The character of Simutrans, like SimCity, is such that survival is difficult at the beginning, but if one gets established then money just keeps flowing in without any great challenge. This is encapsulated in this post. I believe that as a result of this dynamic, the value of these games is limited. How to address this? Some considerations:
1. If it's not addressed, then in multi-player games whoever gets established first can pull in enough money to suppress the competition, which also limits gameplay.
2. One way of stating the problem is that the price factor needs to be above a certain value for the player to have any chance of getting a start, but that value is too high to challenge a player with an established network. This is because...
3. Most of the real-world dynamics that increase profits for established networks are present in the game, but most of the dynamics that would reduce profits are absent. When an operation first starts up, its capital utilisation is usually quite poor, but as traffic builds utilisation improves, fixed costs are spread, and profit and return on capital increase. In the sim, one builds infrastructure and buys vehicles, and these things just keep going forever, whereas in the real world both of these things would wear out, and wear out in proportion to their usage. Road and rail needs to be relaid after an amount of traffic, busier lines have smaller maintenance windows requiring more intensive and out-of-hours (i.e. expensive) maintenance operations, busier lines need to maintain higher standards of individual unit reliability to maintain network reliability, there's the congestion operating cost issue I mentioned above, and so on. In the sim, infrastructure maintenance is a fixed cost over time, so if, say, I send 100t or 1,000,000t over a track in a year, I pay the same track maintenance cost.

I fully agree about the micro-management issue but the obsolescence ramp-up seems to me to cause much the same amount of micro-management as a simple age-based one would anyway - the player still has to weed out the individual vehicles that are costing too much to run. The only difference in the current sim is that the filter is already able to identify obsolete vehicles, and doesn't have the ability to, say, rank vehicles by their proportional maintenance cost. But I have thought of a different approach that might be simpler...

The upshot of increasing maintenance costs is that everything has a lifespan, so why not cut to the chase and impose a lifespan on every vehicle and way? You buy a loco that has a lifespan of, say, 1,000,000 km, and once that's up, you have to replace it or lose it. Same with road, rail, and runways, with lifespan measured in tonnes. For the player to be able to manage it the sim would have to be able to provide the following:
1. A list of all vehicles and infrastructure, ideally also colour-coded on the map, that are approaching expiry
2. A budget forecast of replacement expenditure
3. An option to have the sim automatically replace everything of each type or to prompt the player for a decision. Vehicles could be replaced in transit to avoid micro-managing them in and out of depots.
This would be highly realistic and do a great job of keeping rampant profits in check on a large network. Different modes have different lifespans (e.g. road vehicles less than rail ones). Maintenance costs could also increase with age but not be critical for replacement, that way the player's intuitive thinking that "this thing's getting old, it'll be costing more to run and soon I'll have to replace it anyway" is correct.
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.

jamespetts

I should note that I have now implemented the way related parts of this on the way-improvements branch.
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.

jamespetts

#48
I have found some good information about the effect of the hammer blow of steam locomotives on the pressure that they exert upon the track from p. 70 of this source (which was also cited in the "snippet of relative pricing information" thread in text only form). Although the source is primarily American, the physics should remain unchanged between there and here, save to note that the Americans tended only to use two cylinder locomotives and thus did not benefit from the reduced hammer blow of three or four cylinder locomotives.

The weights given in the below table, that I approximately reproduce from the original, are in pounds.

Type (wheel configuration)Weight on axle (main driver)Weight on axle (front or back drivers)Excess pressure due to hammer blow (one side only; main driver)Excess pressure due to hammer blow (one side only; front or back drivers)
4-4-255,00052,00012,0009,000
4-6-260,00056,00010,0007,000
4-6-055,00052,00011,00010,000
2-6-054,00053,00015,00011,000
2-8-054,00050,00014,0009,000

Edit: Pages 71-72 have some further interesting information on this topic, which is perhaps a better summary than the table above. The "dynamic augment" (U. S. terminology for hammer blow) force to be added to the static force of the wheels upon the rails is, apparently, 26% of the static force when the static force is over 25,000lb, and 75% on the main drivers, 60% on the front and back drivers and 26% on the trailing wheels for passenger locomotives and 66% on the main drivers, 45% on the front and back drivers and 26% on the trailing wheels for freight locomotives. Again, this is referring to American locomotives which were invariably of 2 outside cylinders, which was the type to have the highest hammer blow/dynamic augment.

Edit 2: Page 2 of the same book records,

QuoteAccording to Mr. R. Price Williams the average life of an iron rail, on the most heavily worked portions of the railways in the United Kingdom in the year 1878, may roundly be taken at 17 1/2 millions of tons.
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.