News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

Measuring work and fuel consumption

Started by jamespetts, December 08, 2015, 12:31:28 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

In the process of researching improvements to pakset data for steam locomotive physics (the previous extrapolations were incorrect, and resulted in power figures that were in some cases (especially freight and suburban locomotives) considerably too low), I have found data that suggests that there are orders of magnitude fluctuation in coal consumed per mile (as it was measured then; per km for Simutrans purposes) between slow freight trains and express passenger trains (figures for stopping passenger trains are harder to come by): there are various sources which I have not time to quote now, but a medium sized tank locomotive hauling a train of coal wagons up a hill could consume 95lb of coal per mile, whereas large express passenger locomotive hauling a 12 or so carriage passenger train may take less than 45lb of coal per mile.

This means that it is not possible to have a realistic balance by doing what I had previously planned to do, which is to use the existing per kilometre maintenance cost ("running cost") as a measure of fuel consumption. That will have to be reserved for the cost of general maintenance ("repairs" in the older literature), and a new system of charging entirely introduced for fuel consumption in addition to the fixed monthly cost (which was and is intended to reflect only the staffing cost of the vehicle: e.g, the cost of the driver's wages).

What will be needed is a third type of cost measured neither purely by distance nor purely by time, but by unit of work done. This will need, I think, to be in the form of fuel consumption per game month (which can readily be converted to consumption per hour, which figures are readily available or able to be calculated for multiple types of transport), which can then be adjusted by the amount of work done. It would be adjusted between an idle fuel consumption (which could be as low as zero for, e.g., an electric vehicle)  and a maximum fuel consumption figure, both specified in the .dat file, depending on the proportion of work that the vehicle has performed in any given unit of time compared to the maximum amount of work that could have been performed in that unit of time by the vehicle in question based on its characteristics (i.e., power rating).

The hard part will be measuring the amount of work done and storing this information in a way that can easily be utilised and does not consume excessive memory or bandwidth (as well as understanding the basic mathematics of how to calculate work from a convoy's weight, speed, current resistance and such other data as may be available). Also a challenge will be presenting this information to users in an easily digestible way. Adding to the complexity is the fact that the current physics engine in Experimental was written by neither I nor any of the Standard developers.

I should be very grateful for any suggestions in respect of these matters, as this will be a challenging but important thing to implement if we are ever to have a sensible and realistic balance.
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

Ultimately fuel consumption comes down to work done. Every tick a convoy moves it in theory does a certain amount of work. This is basic highschool physics.

The problem is the fuel economy, the conversion from work done into actual fuel and hence cost.

For example a car engine is most efficient around a certain RPM outputting a certain talk etc. Outside this range (eg an accelerating car) the efficiency decreases. To compensate cars use gear boxes which allow the engine to perform in its more efficient operating conditions while at slower or higher speeds. However the efficiency will still vary heavily, and it is the efficiency that converts work done into fuel used. This does not just apply to car engines, but also to steam engines, diesel engines and electric engines.

So where does work done go? The most obvious is acceleration, as to move an object needs to be given kinetic energy. With movement you have air resistance, and this is especially important with high speed trains and cars as it can account to significant losses of energy. Then you have friction/rolling resistance or whatever you want to call it which also loses energy. Since tracks are not flat you have gravity, which is mgh potential energy based on the change of height, gravity and mass. When a train is up to speed on a flat section of track the work done is simply the losses. If it goes up hill then it does more power per unit time in order to compensate for mgh conversion. When it goes down hill the opposite applies to the point the train may need to absorb work (break) to avoid over speeding. Obviously when a train is stopping it does not need to do any work, or it even does negative work if it features energy reclamation technology. If one gets all these calculations correct, and factor in efficiency you will have a work done which translates to a fuel volume and hence cost.

A big and unrealistic problem then is work done economy. There is such a term as driving economically and I can assure you what happens in Simutrans is anything but economical. What trains currently do in Simutrans is similar to what cars do in an overcrowded city. They accelerate to the maximum speed they can, and then break to stop when they have to. This constant acceleration (a lot of work done) and breaking (wasting all the work done) results in a lot more work being done. In real life trains avoid this, often slowing down instead of out right stopping and schedules are carefully engineered such that trains seldom needs to stop when moving at speed which reduces the total amount of work done. Currently if you had a slow goods train in front of a fast express passenger train then the express passenger train would constantly output full power to reach maximum speed until it encounters the reserved block of the goods train and then stops, repeating this every 1-2 signal blocks. With realistic energy economy this is very uneconomical and the express train would run up huge fuel costs because of its stupid behaviour. In real life the express train would slow to approximately the same speed as the goods train so that they pass the blocks at around the same rate so there is no need to stop. This runs up very low fuel costs since the train only has the low speed drag, rolling resistance and height changes to power.

jamespetts

Thank you for those reflections - that is interesting. I wonder whether a slightly simplified system might suffice: have three monthly rates of fuel consumption: (1) idle; (2) coasting; and (3) accelerating. I believe that the physics engine already distinguishes between accelerating and coasting for the purposes of determining whether to emit smoke graphics from deisel vehicles. The idle consumption could be used when stationary or braking.

To modify the work done economy issue, it might be worthwhile for players to be able to specify a maximum speed for each point to point journey in the schedule; I am planning on adding additional features to the schedule in any event.
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

Quote
To modify the work done economy issue, it might be worthwhile for players to be able to specify a maximum speed for each point to point journey in the schedule; I am planning on adding additional features to the schedule in any event.
Although this helps resolve the problem, it becomes yet another feature the player will have to spend countless hours dealing with when dealing with a large rail network.

It might be better in the end to simply cheat and give players free acceleration work. Instead the average amount of work done accelerating per km can be tagged onto the rolling energy costs. This will mean the running results will be approximately realistic even though the actual work done is not due to bad vehicle economy.

Sarlock

That would be simpler, and preferable, to a system that is mathematically complex and difficult to understand and convey to the player.  The player needs to be able to quickly calculate what the cost of each unit will be on a per km basis.  If they have to start to do complex calculations based on resistances, acceleration, etc, they will have a difficult time choosing which locomotive is the most effective choice for a given task.  All of the various impacts on operating cost can be approximated by using a base per km cost.  It isn't perfect, but it's close and for purposes of the game, sufficient.

I would add significantly more cost to the train cars and less to the locomotive, in order to better reflect the impact of weight on overall operating costs.  Running the locomotive by itself is far, far cheaper than when pulling 50 fully loaded cars.

Improving the quality of the simulation is great, adding more complexity for the player, less so.
Current projects: Pak128 Trees, blender graphics

jamespetts

Trying to average out the performance simply won't work because of the orders of magnitude difference between slow freight haulage and fast passenger haulage in fuel consumed per unit of distance. Trying to fix this by putting the cost onto the vehicles causes two fundamental and irresolvable problems: (1) there is no way of accounting for the different efficiency or power of the locomotives when doing this, which itself can entail orders of magnitude differences, so this will in many cases be orders of magnitude out; and (2) this would breach the fundamental balancing rule of Experimental that costs and revenues assigned to particular things should reflect the real life cost of those things. Breaching the second rule would make balancing impossibly difficult.

It should not be in principle too difficult to select railway locomotives or other vehicles with three fuel consumption rates (accelerating, coasting and idle), especially if there were a fixed ratio between each of them applicable to all vehicles of a certain traction type. That would then not in principle be materially more complex for a player than deciding where there is just the one figure: one would just compare the fuel cost with the power output, tractive effort, top speed, capital cost, maintenance cost and staffing cost (and, in the case of carrying vehicles, capacity, loading time, and, where applicable, comfort) in the usual way.

Players should not in any event have to get a calculator out to work out whether any given service will make a profit or not, as this sort of precision in prediction was never possible in real life. Part of the point of additional realistic complexities in Experimental is to force players to use realistic heuristic methods of estimating what the best solution is, rather than just calculating it mathematically as is possible (but much, much more tedious) in a simpler simulation. The balance is intended in most cases to be lenient enough to the player so that the player can make modest errors, choose moderately sub-optimal solutions, and still stay afloat, albeit be able to expand less quickly than a player making optimal decisions. Indeed, such a lenient balance is realistic in most cases, especially in the case of 19th and early 20th century railways, where many sub-optimal decisions were made by companies that remained profitable (but also in, for example, 20th century road transport, were sub-optimal decisions are easy to reverse quickly).
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.

Ves

#6
May is suggest that you add a description field to each vehicle. If you one could add descriptions for the player to read before buying a vehicle, the pakset author could write stuff like "this locomotive is good for hilly areas" or "this locomotive is very cheap but not suitable for shorter trips" etc.
Although the railways in the past did not have precise diagrams, some sort of prediction would they have, based on the experience.

Edit: to be clear, I meant that a nice way to tell the player what all the costs (three rates of maintenance, staff costs etc) would mean to your gameplay, a description field could conclude that nice!
Edit 2: Offtopic, such a description field could be usefull in many other ways as well: Conclusions of data, Historical comments, fun facts, descriptions of other details etc...

Vladki

I remember similar discussion in standard.  Something similar, yet much simpler (only power, weight and friction used for calculation), was proposed and dismissed as too complex to show to the player. Even en real life, when you buy a car you get fuel consumption in litres per 100km or miles per gallon. On the other hand, I would really like to see that a train coming downhill (or empty) has lower running cost than train going uphill (or full).

I really like the idea of showing a free comment to the player: e.g. this is a heavy freight engine (>8 waggons), this is a light passenger engine (<4 coaches), this EMU is usually run in a set of 2 powered and 3-4 unpowered coaches, etc.

To keep the user info as clear as possible, I would suggest using some average cost/kWh. This would tell the user the efficiency of the engine. Further decision would be based on top speed, power and traction force to decide which engine is more suitable. E.g. for an express train, the less efficient but fast and powerful engine is worth the money because it will be back in speed bonus, while for slow commuter train the efficiency will be the primary concern.

But anyway, I think it will be much easier to find cost/km than cost/kWh. I am not sure about the exact formula, as I don't really know what information is available. Dat file has: air_resistance, rolling_resistance, tractive_effort, power, gear, weight. What do we have in-game? current weight (including cargo), current speed, friction (uphill/downhill/curve), current power output? current tractive/braking force? acceleration?

zook2

1. Constant stop-and-go ruins fuel efficiency. But could a very quick & dirty solution perhaps involve using the monthly speed average which is already being calculated? For example, an engine rated as having a max. speed of 120 km/h (when pulling x tons, which is also already calculated) that gets an average speed of 80 km/h is probably being run quite efficiently, even though nothing is known about acceleration/deceleration cycles. The same engine getting only an av. of 20 km/h is either carrying iron ore across the Alps or constantly stopping somewhere.

2. I tried to find data on historical UK coal prices, but came up a little short. For what it's worth, here's some price data based on a real price index:
http://www.resilience.org/stories/2011-08-15/jevons-coal-question-why-uk-coal-peak-wasnt-bad-expected
That is probably important in this regard because relative costs of labour and coal changed a lot in 100 years of the steam train.

3. What's the thermal efficiency of a train's steam engine? I've read estimates of 5-10%, which means most of your coal's energy goes through the stack anyway - without contributing to the train's movement. In that case you'd need thermal efficiency ratings for a particular type, wouldn't you?

jamespetts

Thank you all for your suggestions. There are two distinct strands to this discussion: (1) the techincal question of how to calculate work done in order to calculate fuel consumption; and (2) a set of related gameplay discussions.

As to (1), I should be very interested in any further thoughts on this, as this has only been touched on briefly so far. I am wondering whether some calculation performed in step(), calculating current output, multiplying that by delta_t and storing it in a uint32 value in vehikel_t might be feasible? The three states idea above will probably not, on reflection, work well, as there is a difference between hauling a heavy load up a hill and accelerating a light load gently on the flat.

As to the other matters, a clear representation of the various costs might be to specify simply a minimum and maximum monthly fuel cost (based on idling and maximum work output respectively), and the player should be able to get the idea that, the harder that the vehicle has to work, the closer to the maximum that the cost is likely to be. A player who is not trying to calculate precisely in advance what it will cost to run a convoy (which should not generally be feasible in any event: see above on calculating) should need no more than this information heuristically to compare different vehicles for their suitability for any given task.

Average speed is not going to work because no account is taken in that calculation of time spent stationary; also, no account is taken of the load varying over the month (which is likely to be more important when convoy recombination is added as a feature).

Historical coal price data will be needed in due course to balance the costs of various coal burning vehicles, and to vary those costs with time when the inflation feature is added. The same is true of oil prices for diesel, petrol and jet engined vehicles, and electricity for electrically powered vehicles. Even the historical cost of horse feed will need to be investigated. The link is interesting, and is likely to be useful in the future.

The thermal efficiency of steam locomotives I have been investigating carefully of late in connexion with this very issue (and also to rebalance steam locomotive power in the pakset, which was not extrapolated correctly before). It varied considerably, but was never more than 8% or so in the UK at least (earlier locomotives being much less efficient than later locomotives; extrapolation suggests that early locomotives from the 1830s or so had efficiencies of less than 3%, and very small steam locomotives, such as narrow gauge or tram engines, had efficiencies of 1% or even less in some cases (assuming a constant rate of coal consumed per firegrate area, based on measured performance, the Ffestiniog Railway's Double Fairlie engine manages only 1.8% thermal efficiency compared to the near contemporary GNR Stirling 8ft Single, which manages 4.33% - this is in the early 1870s).

The idea of a description is an interesting one, and has been discussed before. It does, however, have a number of problems - not necessarily insurmountable ones, but ones that make me think twice before implementing it and question whether it is a worthwhile use of time compared to other projects. Firstly there is the problem of where the text would actually fit in the already overcrowded depot window. Secondly, there is the time that it would take to provide a useful description for each and every vehicle (and there are lots of them, and they are growing). Thirdly, there is the point that, given that these are all real vehicles, players can in most cases just perform a Google search to find out about the real life versions, which should give information as to how they were used, which, if the simulation is realistic enough, should suffice. Fourthly, working out what information to give is really not straightforward at all. Many vehicles of all types are capable of being used for multiple different duties in different circumstances. An express railway locomotive from the 1860s may be hauling secondary passenger trains by the 1880s, branch line trains in the 1900s and be a station pilot in the 1920s (as was the sole surviving example of the Midland Railway's 156 class). A railway locomotive designed mainly for freight might find use on suburban passenger services in some instances, or on secondary passenger services on steeply graded track. A road motor coach intended for long distance comfortable travel might equally be used to link a city centre with a nearby airport 15km away. A small jet aircraft might make short hops between an island and the mainland or long journeys on a minor route. Giving short descriptions is likely to mislead the player, and giving long descriptions is likely to confuse the player. The player may find a use for the vehicle that the pakset author had not anticipated.
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

Quote
Trying to average out the performance simply won't work because of the orders of magnitude difference between slow freight haulage and fast passenger haulage in fuel consumed per unit of distance.
Which is why you use the rolling work done. You then ignore acceleration completely, equivalently giving you free acceleration. However it is not free, as you factor in realistic work done while accelerating to an inefficiency applied to rolling work done. This means it is free for your trains to decelerate and accelerate all the time, but instead you are paying slightly more for the work done per km travelled. This avoids the need for highly complex features like speed limits.

Quote
Part of the point of additional realistic complexities in Experimental is to force players to use realistic heuristic methods of estimating what the best solution is, rather than just calculating it mathematically as is possible (but much, much more tedious) in a simpler simulation.
In real life tens of thousands of hours are spent planning railways. Every day dozens of people work on railway schedules. There are no "heuristic methods" of building railways. There never were as even the very early ones would have had thousands of hours spent planning.

People play because it is a game, not because it is several times harder to play than real life as you are one person. If Experimental was truly realistic, one person would struggle to even manage a single line.

One would have to cancel such complexities out with autonomous managers, planners, and other features. Which might end up making a line is as simple as specifying two points, seeing if long term projected profit is positive and pressing confirm.

jamespetts

Quote from: DrSuperGood on December 09, 2015, 11:17:06 PM
Which is why you use the rolling work done. You then ignore acceleration completely, equivalently giving you free acceleration. However it is not free, as you factor in realistic work done while accelerating to an inefficiency applied to rolling work done. This means it is free for your trains to decelerate and accelerate all the time, but instead you are paying slightly more for the work done per km travelled. This avoids the need for highly complex features like speed limits.

This looks like a promising idea. Have you any suggestions as to go about calculating this; would something in step() be the thing, do you think?

QuoteIn real life tens of thousands of hours are spent planning railways. Every day dozens of people work on railway schedules. There are no "heuristic methods" of building railways. There never were as even the very early ones would have had thousands of hours spent planning.

People play because it is a game, not because it is several times harder to play than real life as you are one person. If Experimental was truly realistic, one person would struggle to even manage a single line.

One would have to cancel such complexities out with autonomous managers, planners, and other features. Which might end up making a line is as simple as specifying two points, seeing if long term projected profit is positive and pressing confirm.

I do not think that it is quite as simple (or complex) as that. Railway schedules are particularly complex and do require great mathematical effort; but we have already found a balanced simplified way of dealing with those. Similarly, keeping ledgers in the Victorian times required a room full of clerks whereas now it can easily be done with a home computer and within Simutrans.

What at least Victorian railway engineers were not readily able to do was work out other than very approximately how much coal that a given train service that has yet to be introduced would actually end up using. The exact revenue and cost could not be predicted, but had to be estimated. Often, the estimates were wrong, and some lines were built that transpired to be only marginally profitable or even unprofitable. The same was true of canals. Players in Simutrans cannot expect to be able to count the tiles, look at the cost per tile per vehicle, work out a factory's production, look at the revenue per unit transported and get an exact figure as to profitability for a service that has not been built yet. Attempting to do so would make the game unremittingly tedious, and yet exactly this is possible (and confers a real advantage) when the simulation is simple.
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

There's a simulation tool for OpenRails that calculates tractive effort from loco specifications, if anybody should be so inclined...
http://openrails.org/files/OR_Steam%20Model_03_02_2014.pdf
and loco data:
http://orion.math.iastate.edu/jdhsmith/term/slindex.htm

Then there's some apparently real-life data on actual practices of running locomotives:
http://www.catskillarchive.com/rrextra/chapt25.Html
It seems that 33% higher coal use due to sloppy throttle-settings were not uncommon.

jamespetts

#13
Thank you for those - I am actually already aware of the locomotive data and tractive effort calculators (I use a different one, but they do the same thing): see here for more details. As to the energy in coal, one must be careful not to use American sources, as they seem to have much poorer coal there than existed in the UK during the steam age (about a third less energy per unit of weight than the best Welsh coal), but I have already undertaken some detailed calculations on the energy in coal and the thermal efficiency of locomotives relative to their power output. Those calculations will go in the steam physics calculations spreadsheet on Github when I have finished the rebalancing.

Edit: One query about Dr. Supergood's suggestion of measuring work done, incidentally: does anyone have any idea as to a reliable way of calibrating this? The base figures that I have are the firegrate areas of various steam locomotives, and a range of figures as to how much coal that typical steam locomotives burnt per square foot of firegrate per hour, as well as information as to the calorific value of certain types of coal (and varying amounts of information as to what locomotives used what types of coal). I can thus work out a per hour (and therefore per Simutrans month) rate of fuel usage assuming that the locomotive is working hard during the whole time. Likewise for aircraft, one can often find the fuel consumption by time figure, which I assume is for cruising. Is there a sensible and consistent way to convert these per unit of time measurements into per unit of work done measurements without having to make arbitrary stipulations about average speed that it is the intention of this proposed system (i.e., by not making it per unit of distance) to avoid?
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

My understanding of the physics of combustion engines is rather limited, but since there aren't any takers yet, I'll give it a try...

You start with measured real-life fuel use of a loco type, therefore you know how much energy was fed into the engine per hour. And you want to calculate from that how much mechanical work was done.

But fuel use is dependent upon:
- actual operating practices (sloppy throttle setting, as in the link I posted above). This factor is unknown, but if the above link is correct, it could be as much as a third. You do not know how much it changed over the decades, due to better understanding of the technology, driver training etc.
- the route on which these engines ran. A route with many gradients requires the engine to do more work, thereby using more fuel. I guess this factor is also unknown and assuming that the locomotive is working hard during the whole time is an arbitrary stipulation by itself.
- rolling resistance is dependent on weight. You'd need to know how much weight these engines actually pulled when the fuel use was measured. Also probably unknown.
- actual average speed when fuel use was measured, as well as start-and-stop cycles.
- even the weather can change the thermal efficiency of an engine because in cold weather the engine radiates off more loss heat.

In other words, I say you'd need to have measurements of fuel use under standardized settings to calculate the actual work done.

isidoro

Not to mention a simple factor like wind...

jamespetts

Thank you for your responses: looking into the proper definition of work, it does seem as though Dr. Supergood's suggestion is a good one: I just need to measure force multiplied by distance, which can be done once per tile traversed, and can take account of hills and other things affecting rolling resistance. The unit produced is a unit of change of energy, which can then be multiplied by the thermal energy in the fuel and again by the efficiency of the engine to get a figure for the cost of fuel used. I just need to find a way of extracting the force required to move the load at any given tile in order to make this work.
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

I have just made a pull request that changes the running and monthly costs of all vehicles. This post will highlight the changes made and server as a centre for discussion/complaint about any of the changes made. Hopefully these changes will make it into the next nightly build.

For anyone interested in seeing the logic behind the balancing, the spreadsheet that was used to generate the numbers for automatic merger is available below.
https://www.dropbox.com/s/3u8nvwb7gdklbz1/Pak128%20Britain%20In.xlsx?dl=0

Practically all trailers/coaches now have as good as 0 per km cost associated with them. The logic behind it is that trailers, coaches and other unpowered vehicles that are pulled/pushed around by powered verhicles will practically never wear out from doing so. In theory there is a cost as they will eventually wear out, however due to the low cost of trailers (no expensive engines) and their simplicity it is so small that it cannot be represented accuratly after rounding. Instead of rounding up (0.01) I rounded to nearest so in most cases this is in the players favour. For people on the server game this means that your trains will cost a lot less to run as a lot of the per KM cost is now expensive coaches.

All vehicles that have a cost now have a monthly cost associated with owning them. The extent of this cost is based on how well the vehicle ages when not used as well as the initial cost of the vehicle. This is only really significant for some vehicles such as planes, ships and such. Usually it will be a few simupounds per month for coaches and such.

Ships are very roughly balanced. One may find they have the wrong crew numbers or are impossible to run profitable over similar selections. This is because many of the ships have estimate weights and powers associated with them as well as strange water physics (not sure how realistic it is). Such ships can be balanced on an individual basis if required.

Some attempt was made to balance aircraft. How balanced they are I do not know.

Since the balance spreadsheet started out several weeks ago, some of the more recent manual changes made to the pakset might not be present in it. Over the next few weeks I will try to improve my automation framework or find some other way to merge in these changes as well as add additional columns for more balance information such as capacities, traction, retirement, etc.

The power to cost logic is almost certainly unrealistic. Until a power usage metering, fuel and consumable weight system is added to Simutrans Extended it will remain so. What such a system would allow one to do is meter the actual power used to move a vehicle and from that charge the player a more accurate fuel running cost. The fuel system would mean different types of fuel have different costs and these costs can change with respect to time to represent improvements in production technology to recessions and resource scarcities. The consumable weight system means that as a vehicle that consumes fuel travels it will lose weight proportional to the fuel being expended meaning that the vehicle becomes more economical to run per km a feature critical for steam engines (water and coal used up on the move) and aircraft (fuel used up on the move). Such a system does not mean that if a vehicle runs out of fuel it becomes stuck.

For accurate wearing out and maintainance values a vehicle durability system is needed, similar to what pathways now have. I believe this has already been proposed as the "overhaul" system and is an up comming feature some time in the distant future. All vehicles would have durability. As they move some amount of durability is expended. Every month they exist some amount of durability is expended. Some fraction of lost durability can be recovered cheaply by servicing the vehicle in a depot. Only way to fully restore durability is an expensive "overhaul", which in the case of some vehicles like large passenger aircraft or ships this might be a large cost of a new one. If a vehicles durability runs too low then its performance may be effected, including reduced maximum speed and power. The use of depots for this only makes sense with the up coming scheduling and recombination features as then depots become an integral and mandatory part of a lines operation.

Vladki

So, if the per km costs for trailers are (almost) zero, it means that a 1 wagon train has the same per km cost as 100 wagon train ?
I think that until we have power consumption based running cost, we should assign some running cost to trailers as well.
Or did you calculate the running costs for engines to include a fully loaded train of maximum length it can pull?

In practice there are also maintenance tasks that have to be done after certain amount of km running. These should be accounted for too.
And until we have overhauls, they should be too split into per km or per month costs.

An idea for future overhauls and services - vehicles with neglected service could not only have their top speed reduced, but also comfort (passengers) or capacity (cargo) reduced.
And for the fuel consumption system, don't forget that vehicles differ in efficiency. Even thou they consume the same fuel, they have different consumption/kW.

DrSuperGood

QuoteSo, if the per km costs for trailers are (almost) zero, it means that a 1 wagon train has the same per km cost as 100 wagon train ?
Yes. However that 100 wagon train is impossible due to engine/pakset limitations so I never considered it...
QuoteOr did you calculate the running costs for engines to include a fully loaded train of maximum length it can pull?
They assume the engine is having to provide maximum power. It is up to the player to optimize the power output with length. Something that occurs naturally at the moment.
QuoteIn practice there are also maintenance tasks that have to be done after certain amount of km running. These should be accounted for too.
Which they are currently in the form of a per km cost. However this is too small that rounding eliminates it.

jamespetts

Thank you for this - I have now incorporated this. A better way of doing balance (subject to test based updating of this if Dr. Supergood should be so inclined) will have to wait until the balance critical features (vehicle maintenance and inflation) are added. There may be a number of further matters to discuss in relation to preparing for balance in due course that can learn from Dr. Supergood's experience at this interim balancing exercise, some of which Dr. Supergood touches on above (such as the issue of power usage), and it would be helpful in due course to have a thread discussing and analysing in detail (mathematically and based on empirical evidence, preferably with examples and modelling) precisely what dynamics it is necessary to simulate in order to achieve a realistic cost/revenue balance before the work on the balance critical features is completed, but I am currently very busy with professional commitments and only just about have time to merge this.

In the meantime, if anyone else would like to start that discussion, it would be very worthwhile. This is the first time that we have had even an approximate cost balancing for Pak128.Britain (either Standard or Extended), and I am very grateful indeed to Dr. Supergood for the large amount of work that this must have entailed. Even though this may well be some way different from the final balance once the features are implemented in due course, this is still a significant achievement and advance for the pakset.
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

Quoteinflation
I am not too sure that inflation would bring much to the table. Sure it is something that occurs in real life, but all it really serves to do is devalue any liquid capital a company owns. On top of that it would require being applied to practically every aspect that has a cost associated with it and in the end the game itself might be internally using normalized costs then adjusted for inflation. I would not say inflation is critical for balance, especially when compared with a better staffing system as well as an fuel consumption system.
QuoteIn the meantime, if anyone else would like to start that discussion, it would be very worthwhile. This is the first time that we have had even an approximate cost balancing for Pak128.Britain (either Standard or Extended), and I am very grateful indeed to Dr. Supergood for the large amount of work that this must have entailed. Even though this may well be some way different from the final balance once the features are implemented in due course, this is still a significant achievement and advance for the pakset.
To give people ideas on the time spent, I recon at least 20 hours of work in total. About 4-8 getting everything set up and then the rest processing data.

The current balance numbers might be a bit too cheap for some vehicles. This is slightly intentional so that people can enjoy playing the pakset without finding it impossible to make money at certain stages. If particular vehicle combinations are too profitable one can adjust the values in future.

I was thinking of increasing the transport value of all freight by an order of magnitude. Currently freight generates so little money that on the server most players are not bothering with it and instead solely focusing on Passengers and Mail which are big money spinners. A large problem with freight at its current price is how little of it is available to transport.

jamespetts

It is probably better to err on the side of being too easy rather than too difficult in case of doubt.

In relation to inflation, this is important for two main reasons: (1) the planned way of simulating inflation allows the simulation of differential inflation, in which labour costs, fuel costs, ticket prices, materials costs and other things change over time independently of each other so that the changing relationships between these things can be simulated (which was important in reality, especially changes in labour costs); and (2) (less importantly but still significantly) general inflation will prevent players accumulating large cash stockpiles early in the game which retain their value until the later part of the game (allowing, e.g., an 18th century canal empire to fund a 21st century airline).

In any event, thank you again for all your work on this.
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

Quote(1) the planned way of simulating inflation allows the simulation of differential inflation, in which labour costs, fuel costs, ticket prices, materials costs and other things change over time independently of each other so that the changing relationships between these things can be simulated (which was important in reality, especially changes in labour costs);
This has nothing to do with inflation. If one separates the parts then each of those can be made to change with time. Similar to how speed bonus works in standard, but expanded for all kinds of things like fuels, labour, etc.

This also might result in deflation in particular areas at certain times, as occurred in real life. For example during the oil crisis oil based fuel costs would rise significantly, but after the crisis ends the fuel prices decrease.
Quote(2) (less importantly but still significantly) general inflation will prevent players accumulating large cash stockpiles early in the game which retain their value until the later part of the game (allowing, e.g., an 18th century canal empire to fund a 21st century airline).
Except this assumes a company keeps their capital liquid. Most companies, like rich people, invest most of their free money in assets which are more inflation proof. This is how many rich people are still living off the Rockefeller fortunes. As such their wealth retains similar value irrespective of inflation.

The only reason a cannel company would accumulate fortunes like my own company on the server is because the player who controls it lacks enough time to spend the money as fast as the company earns it. Something that is not realistic as years in real life are years as opposed to under a day.

Spenk009

Quote from: DrSuperGood on June 22, 2018, 08:30:53 PM
The only reason a cannel company would accumulate fortunes like my own company on the server is because the player who controls it lacks enough time to spend the money as fast as the company earns it.
If you were to leave your company untouched until the 21st century, I'm certain that obsolescence increases, lost business to faster rivals, reduction of toll income, etc. would all factor in to reduce income and slowly bankrupt the company. It could be very interesting to see this, although difficult to make happen.




Dr SuperGood How would you like your feedback to the changes? I'm certain people are happy to share their savegames, write out their experiences and thoughts and/or show screenshots.

(Savegame: 6400*1280, yr. 1922, 435 towns, 4.7m pop, img)
Passengers: I've found that my company earns a lot more money (around 3x), many bus lines are now less unprofitable if they have passengers. Smaller railway lines over shorter distances are now profitable, larger lines have less of a pronounced bump in income (imo very good). My turbine channel ferries, which are usually filled with passengers have had no impact on profitability, however I'm trading them for turbine coastal ships to make use of the passenger numbers (the hefty monthly increase is hopefully worth it).
Goods: The system I use for goods is mixed trains across the map, connecting industries that are convenient or have high I/O. The trains are doing better although I still have trouble making lines profitable. Road and Naval sections incur losses. The goods network is neither complete nor well designed, so I doubt it's a representative of goods focused playing.

DrSuperGood

QuoteDr SuperGood How would you like your feedback to the changes? I'm certain people are happy to share their savegames, write out their experiences and thoughts and/or show screenshots.
By feedback I generally mean weather the balance changes are working or not. Or if you encountered some vehicle that is abolutly broken gameplay wise either positivly or negativly.

I balanced almost everything (I think 3 vehicles were added during that time which were not included in the spreadsheet) in the pakset. However I have tested only what is currently available on the server. Hence I cannot guarantee that something is broken or not, especially with the many modern trains or hovercrafts.
QuoteGoods: The system I use for goods is mixed trains across the map, connecting industries that are convenient or have high I/O. The trains are doing better although I still have trouble making lines profitable. Road and Naval sections incur losses. The goods network is neither complete nor well designed, so I doubt it's a representative of goods focused playing.
I think goods need their prices doubled or even tripled. The quantities they are available in, especially early game, is so low that it is always better to focus entirely on passengers.

jamespetts

In relation to the prices of goods - these are all set relative to passengers using historical data, so it would not be right to double or triple the prices. Work does need to be done at some point to improve the balance between producer and consumer industries, 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

QuoteIn relation to the prices of goods - these are all set relative to passengers using historical data, so it would not be right to double or triple the prices. Work does need to be done at some point to improve the balance between producer and consumer industries, however.
The problem is that in real life you often had cargo ships and trains full to the brim with goods. Hence why they were so cheap to transport as there was so much of them. Passengers were logically more expensive to transport as you could not fill a bulk wagon or hold with them as they need space to breath and even accommodation and food on longer trips. Simply running 2-3 Australia to UK trips with a clipper carrying grain could pay for the clipper and then some!

Problem is in Simutrans Extended Pak128 Britain, good luck filling even a horse drawn cart with product! This is why it should be tripled or more. To make up for the fact that there is practically nothing to ship around. Where as with passengers you can load a ship to 1/4 capacity or even more, with goods you are lucky to load it to even 1/100 capacity early game (pre 1900 as on the servers currently). In the 1900s practically every town should have at least 1 coal distributers that takes large volumes (many tonnes) of coal. Coal mines should literally be filling train loads of coal every month.

What about deferring transport until there is a practical volume of good? Well the in transit limit does not allow for that! That is if one can even get a factory to work at all because a city has grown so large that it cannot get sufficient employment on either a plant or an end consumer.

jamespetts

This is a somewhat backwards way of looking at things, rather of the "we couldn't fix your brakes so we made the horn louder" school of engineering. The proper way of dealing with these difficulties with the industry is to fix the underlying problems, rather than interfere with the currently correct prices.
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.

Spenk009

Midland Class 2441 and Class 1632 are introduced at different times, but are available to the same date and have fairly similar properties. Previously they were the same running cost/maintenance, but now the latter is 1/3 of the price of the former. Is this an intended change?

DrSuperGood

Quotebut now the latter is 1/3 of the price of the former
That would likely be as the result of it being introduced later when coal is cheaper and possibly having more efficiency. You can check the spreadsheet for details of where the values came from.

jamespetts

You can find my calculation of the fuel efficiency of all steam engines in the Steam physics calc.ods document in the sources folder: thus might be helpful for calculating running costs (it is intended to be used for this purpose when the balancing features are introduced).
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

QuoteYou can find my calculation of the fuel efficiency of all steam engines in the Steam physics calc.ods document in the sources folder:
When I checked them the problem is that they assume the trains are running at their maximum speed. Hence with train speed increases the cost per km decreases, but in a realistic way. However if someone dumped a whole lot of heavy coaches on the train to force it to run well below its maximum speed the result is they get effectively cheap power from the engine.

As a result under such a model it is entirely pointless to use anything but the fastest locomotive as even pulling slow trains is done more efficiently by them than the dedicated slower locomotives. The only time a player might refrain from using such a fast locomotive is if the cost to buy it cannot be afforded, and even then they have to think in the long run due to it having a payback time.

This is why the model I used has the cost per km directly proportional to the power output. This is not realistic however it means that cheap small slow engines have a purpose for hauling appropriate stuff compared with the fastest always being the best.

As mentioned earlier for correct fuel costs a fuel system is needed. The game can then calculate the fuel costs based on actual work an engine does. This would mean that putting a lot of coaches on a fast train to make it slow or running a train with few coaches fast would use the same amount of fuel per unit time as both situations are using the full power of the train. However care must be taken with such a model and ships as a lot of the ship weights appear incorrect or guesses and I do not think ship physics is completely accurate.

jamespetts

That is a very useful analysis. Careful consideration to how to treat this issue will be necessary in due course, starting first, perhaps, with an analysis of whether adopting a realistic system would make a significant difference. We do need to address these issues before completing the balancing features and it is very useful that Dr. Supergood has had a go at interim balancing now so that we can see what features are necessary for balance.

In terms of ship physics, we may need to look into this in more detail. Does anyone have any data against which the ship physics can be tested? The main thing about ship physics that is different from the physics of other vehicles is the "rolling" resistance (i.e., resistance in the water).
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

QuoteIn terms of ship physics, we may need to look into this in more detail. Does anyone have any data against which the ship physics can be tested? The main thing about ship physics that is different from the physics of other vehicles is the "rolling" resistance (i.e., resistance in the water).
This also has to be done with Aircraft since again they use different physics than a train or road vehicle.

Another reason for a fuel system is that it allows fuel costs to vary with time. For example coal would start out quite expensive in the 1840s due low scale mining and usage but by 1880 it would be considerably more cheap per kj of coal due to the large scale mining and transport occurring. This is important because it means running a more powerful locomotive that uses more coal per unit time would be more affordable at the times it happed in real life. This also is important for modern transport simulation as a big factor with transport today is fuel economy, with year on year rising fuel and energy prices encouraging the use of more economical planes, ships and trucks.