The International Simutrans Forum

Hello,
I simply love the "not so easy" game mechanics.
Therefore the beginnings are quite hard.
(5th attempt and bankrupt again).

It will help if one could plan a bit the costs before running a convoy.
Here I would need your help. Search the forum and wiki gave me 3 informations :

• 100 km per hour is equivalent to 1024 tiles per mounth (wiki ? ingame help?)
• pak 128 brit : 2.75 mounth = 1 day; 16h per day => scale is 76:1 (source (http://forum.simutrans.com/index.php?topic=14134.msg141075#msg141075))
• vehicules have a running cost per km

Let's start with two industries located in (107,339) and (162,308). Coordinates should give the number of tiles between two points (direct flying route). After calculation : 63 tiles. First run with a 1912Benz : -228 euros. Cost per km : 2.72. So 228/2.72 = 83 km.

First problem : ok the truck hit the road, not a direct route, but the detour was not big. So 63 tiles (direct) = 83 ? tiles (road)= 83 km (route). 1 tile = 1 km ?? (does not look like it)

(http://tof.canardpc.com/preview2/3b1e2ea6-a1d1-4fbd-9aca-60e96c5c9ae2.jpg) (http://tof.canardpc.com/view/3b1e2ea6-a1d1-4fbd-9aca-60e96c5c9ae2.jpg)

I tryed then to go with timing the convoy. The 1912Benz runs at 30 km/h. Start at (107,339) : 9 mai 2h, arrival at (162,308) : 15 mai 17h. In game time travel : 159 h (6.6 days).
Real time travel : 83 km at 30 km/h : 2.8 h
Scale : 159 h/2.8h => 56:1

It seems close to the 76:1 mentioned here (http://forum.simutrans.com/index.php?topic=14134.msg141075#msg141075). It was for another pak, and I run with the pak128.
Can I get a approximation of the equavalence tile/km with this scale for time?

Last method : in game indication of time travelled. One run is indeed 83 km (a trip of 166 km, back and forth). During a month : 387 km. That's 387/83 = 4.6 run a month. 30 days/4.6 = 6.5 days a run. Close to the 6.6 days above.

Too long to read?
Is 1 tile approx. 1 "real" km?
Is 60h in game approx. 1 "real" hour?

As far as I'm aware, time is not an issue when calculating running costs and income. It might be for maintenance cost, but I've never played with maintenance cost on the vehicles.

In a tile based game like Simutrans, the (taxicab/Manhattan) distance between (107,339) and (162,308) is |107-162| + |339-308| = |-55| + |31| = 86. But you say this is the distance between industries. Income is based on distance between the stations. (Moving goods between industries and stations is not your responsability.) How much you get paid for each unit of distance depends on the speed of the vehicle, defined as the sum of the maximum speed divided by distance driven (as far as I can see). You can then adjust the speed bonus in the goods list until it matches this speed, and read of the amount you get paid for each unit of cargo transported one tile. There is an option that controls how the game interprets "transported one tile", but the default is simply the distance I gave in the start of this paragraph.

Running cost is however based on how many tiles a vehicle passes across to get from A to B. Should be simple multiplication.

Thanks for the reply and the explaination.
I did made a simplication, the coordinates are not for the industrial site, but indeed the cargo bay.
You mention that "How much you get paid for each unit of distance depends on the speed of the vehicle, defined as the sum of the maximum speed divided by distance driven",
so, if my truck runs at its max all the way (30 km/h) for these 86 km, I would be paid :
sum of the max speed = 30 km/h
divided by distance = 86 km
result 30/86 = 0.34 (euros ?)(per hour ?)
(when looking at revenue table shift-G, ore is listed at 0.67 (unit is not visible due to fr translation)

(http://tof.canardpc.com/preview/30cfac1e-244b-4306-94ae-3a8939e1ff46.jpg) (http://tof.canardpc.com/view/30cfac1e-244b-4306-94ae-3a8939e1ff46.jpg)
That would be "real" hour, so 56 x 0.34 = 19 euros per "game" hour.
hence 19 x 24 x 30 = 14 065 per month.
In fact, what I got was 2500 euros max.

You must turn the speed bonus level down until it shows 30 km/h for the type of vehicle in question. It is currently showing what you would get paid if the road vehicle has a speed of 76 km/h (rail 76, boat 36, aircraft 189, etc.). Then just multiply it with distance and amount. In this case, though your arrow is in the way, it looks like the speed bonus rate is 0%, so it doesn't actually matter what the speed is.

And stop with the hours! It's distance x amount of cargo in vehicle x price including proper speed bonus from table. If you're using the vehicle in the screenshot from the first post, that will be 86 x 15 x 0.67 = 864.3. (Beginner mode will multiply this with some factor I can't remember.)

EDIT: Just remembered, there is another strange unexplained factor. So I think it's actually distance x amount of cargo in vehicle x price including proper speed bonus from table x 3. That makes 86 x 15 x 0.67 x 3 = 2592.9.

EDIT2: Nevermind EDIT. The mysterious factor is included in the goods list. It's only when looking at the source code for the paks that this factor must be applied manually.

If playing with timeline enabled in Simutrans Standard the following happens to compute goods values during an arrival. They are not in programming order but should produce the same results.

• Compute the speed bonus speed for the transport type being used. This is based on the convoy and not the way (a tram running on a train track will still have tram speed bonus and not train speed bonus). The actual computation is done from a table of transport type, year and speed value with linear interpolation for times between entries.
• The convoy average maximum speed is fetched. This is not average speed, it is completely time invariant and can be computed based on the convoy's maximum speed with the cargo it is hauling and the maximum speed of the ways the convoy takes to make a journey. The convoy maximum speed will be used unless the way is slower (bottlenecks speed). It is important to note that the actual average speed of the convoy is almost always a lot slower and might be nowhere near this value, possibly due to bad traffic or other transport network problems.
• The Manhattan distance the goods were effectively moved is computed for the effective transport distance. The actual distance varies on algorithm used however it is usually distance between last stop on the schedule. Others include distance moved towards destination and distance moved from point of boarding. Manhattan distance is based on the sum of x and y deltas so shipping at a diagonal makes the same profit value as shipping at right angles. With certain payment modes it is possible for different goods to have different distance values depending on where they departed from or are going to even though they have a transfer stop.
• A price per tile per unit per good type that is unloaded is computed. This is done with the formula {{good per tile value} * {1 + {{average maximum speed} / {speed bonus speed} - 1} * {good speed bonus multiplier (% / 100)} * 10}}. Some internal rounding will occur due to the precision of fixed point mathematics used but the result will seldom be more than 0.01 currency units out.
• The value of unloaded goods is computed. This is done by summing the value of all goods unloaded. The value of an unloaded good is its effective transport distance multiplied by the price per tile per unit for that good type multiplied by the total number of that good unloaded. Although this is usually positive it can be negative with some payment methods (destructive shipping loses money).

As is obvious from the effective transport distance stage, destructive shipping is bad as you do not get paid for it. Worse is that for every destructive tile shipped you will need to pay for another constructive tile to undo it so costs can quickly add up. The actual importance however is based on pakset balance.

pak64 -> high per tile costs to per tile income make destructive shipping very bad, even a few tiles can make a line run in the red
pak128 -> low per tile costs to per tile income make destructive shipping less of a concern, lines can have significant detours as long as they are utilized enough to cover maintenance

Depending on the payment mode used you can convert destructive shipping into constructive shipping. For "distance between last stop" payment you can add fake stops (sidings, or just middle of track stops) just to change the direction counted as constructive shipping. This can make a very bad detour (eg around a mountain, lake, city etc), which would heavily reduce profit, into equivalently no detour (no destructive distance). Some people view this as an exploit of sorts however I am not too sure they have thought their argument through.

In a real economic model you pay for the work done, even if the work done is pointless. If a train has to make a huge detour around a mountain range it will cost you more to use that line than if it could cut straight through the mountain. As such there should be no concept of "destructive shipping" in a transport simulator. Instead what limits profit is entirely what the customers can afford to pay for a journey. An inefficient, expensive line would not get many customers as few can afford to use it even if it is the only way to move something between two points. This is the complete opposite of Simutrans currently where profit is determined by transport efficiency and customers will come even if a journey makes no financial sense (*cough* cargo bouncing exploit *cough*).

Thanks again for the very detailled replies. It seems my intuition was wrong about the economics and calculation at play. I'll have to digest your explanations, and then eventually ask a few more questions. And let go with hours, time and such :)

@Ters : I did not aim or look at the bonus speed, not even thought about changing it. I assumed it was balanced for the era. For what I gather, pak128s are a bit more.. experimental, so it make sence to fiddle and adjust these settings. And right as you are, the speed bonus for coal is 0%.

Quote from: Argelle on May 18, 2015, 08:57:02 AM
I assumed it was balanced for the era.

The goods list should be, in the sense that it will show different prices as the years pass in the game. Your vehicle however, was not up to date with the current trend in speed for road vehicles. But it didn't have to be either, since there is no speed bonus for that particular cargo. (The trendy speeds are typically for passenger and mail. And they might not always be perfectly set by the pak set author.)