I have noticed the following behavior in the latest nightly builds of Simutrans (2022) + Pak128 (134), but I guess it is a general topic concerning ST.
Having a map with a timeline and being around 2050, I see that there are no profitable trams (even if they are always full, they are barely break-even), but the busses are profitable (i.e., a full modern bus earns a decent profit). At the same time, the running cost of those trams (cost per km) are very low. Since the profit of a vehicle depends on its relative speed compared to other vehicles of the same category, my guess is that busses and their speeds are compared to other road vehicles (which are all slow, max speed being 130 km/h, for example) whereas trams are compared to rail vehicles (which are very fast with max speed of 400 km/h).
Because trams are otherwise separated - they have their own depots, menu, line management - I think the speed-related price per transported unit should be computed relative to other trams only and not relative to all rail vehicles. Alternatively, they can be considered a road vehicle.
Thank you for considering my request.
If you talk about the speed bonus, I think from simutrans v100.0 it's loaded from a file (inside pak128/config), and tram has its own scale, so isn't compared with buses neither trains... you may try to lower its last value (80kmh) to a lower value (actually it won't run more than 50kmh, it's the city-road limit!).
Just as zeno said: speed bonus is no longer calculated by comparison of all vehicles, but taken from a file - and tram has a separate entry there. If that's not working correctly, it might be a bug.
But pak128 need to be newly balanced any way, so it might be that as well.
Quote from: Zeno on September 18, 2008, 10:36:28 AMyou may try to lower its last value (80kmh) to a lower value (actually it won't run more than 50kmh, it's the city-road limit!).
That's not entirely correct: since trams do not drive on the road itself but on tracks, they don't care for the road's speed limit. And since there's a tram track for 80 km/h available, that speed
can be reached.
Quote from: DirrrtyDirk on September 18, 2008, 11:19:56 AM
And since there's a tram track for 80 km/h available, that speed can be reached.
Uh... yeah, you're right; but it's too expensive, and if stops are too close, you never get it paid back... :P
That's a matter of balancing - but it is still possible. ;)
I agree with the note on speed-bonus being in the config file (I have not realized this is the case). But please explain me this:
If I start a map in 1980 (no changes in speed bonus for trams) with one line and one tram connecting two stops and going always 100% full, then the proceeds from this one tram go down from $250/year in 1980s to less than $200/year in 2000 and to less than $100/year in 2020 (the tram is then not profitable any more, because it does not cover its running cost). Why does this happen - cost per km are constant, the number of travelers is growing, there is no depreciation of the tram...? This does not occur for busses, however. [Upgrading to a new model of a tram just postpones this process slightly.]
If I miss something (???), let me know but I cannot see why this is happening - just for trams - so I though this might be bug somewhere.
It may very well be a bug - we'll have to figure that out.
You might try this first: (the last entry in the line for tram reads "1975,80" right?) add something like ,2050,80 to the end of that line and see what happens.
It has to be cargo revenue then... Dirk already beat me to it.
Quote from: DirrrtyDirk on September 18, 2008, 11:55:11 AM
You might try this first: (the last entry in the line for tram reads "1975,80" right?) add something like ,2050,80 to the end of that line and see what happens.
I have tried this, but there is no change in behavior (i.e., trams are still unprofitable from ~2020 on). This could have been expected however - I played recently a game till 2100, so if there is a problem with a speed bonus after the last entry, busses would have been affected too (which was not the case).
But speed bonus is the only thing that changes with time - all other things are fixed. ???
To say truth, it is a mystery to me ???
I did this: start a game in 2050, set up one tram line with two stops in pak 64-99 and in pak 128-134 (or whatever the current nightly number is), the simutrans executable is 2022 in both cases. I also used in both cases trams with similar cost/passenger/km (pak64 1.20/225p. ... pak128 0.86/175p.). Nevertheless, the half full-full tram is profitable in pak64 and not profitable in pak128 (precisely, the 100% full tram in pak128 is break-even).
EDIT: I have also tried replacing "config" directory of pak128 by that of "pak64" (just to see what happens) - with no change :-[
Hmmmm, the speedbonus does not make too much sense when looking into inner city traffic (on the roads), as this is not likely to change up to higher levels in the future. Nonetheless it is useful when using subways ...
So in summary it might be an extention request to split the speedbonus systems for trams and trucks whilst they are within city limits?!?
regards - Jörg
Even though that might be an option, it is probably unnecessary:
- the speed limits are not too harsh (e.g., 80 km/h for road vehicles)
- slow bussed, for example, compensate by a large capacity
More importantly, it is at the moment not clear at all where the problem with unprofitable trams arises - as far as I can say based on my tests, it concerns only trams (not busses), only in pak128 (not pak64), and it arises only many (40-50) years after the last speed-threshold is introduced.
Last test - I have tried (just for the sake of doing it) to take pak128, replace its config files with those of pak64 and imported one tram from pak64 to pak128: the results are still the same = as with the trams from pak128.
The question therefore is: what/where is the difference between pak64 and pak128 causing this change? It is not in the config files (I used the ones from pak64) and it is not in the object itself (I used tram from pak64 in pak128). Any ideas?
The cargo's price maybe? ???
Edit: I mean the values from the table appears when you press Shift+G...
In pak64, prices are generally larger (for one passenger it is 70% of the next smallest price).
In pak128, prices are generally smaller (for one passenger it is one half of the other small prices).
Nevertheless, the cargo prices and speed bonuses should not change in later stages (e.g., from 1980 for trams). Thus, if a tram is profitable in year 1980, it should stay so at any later time.
Quote from: jatypc on September 18, 2008, 03:45:09 PM
Thus, if a tram is profitable in year 1980, it should stay so at any later time.
If same cargo, same speed, same bonus... It should :o
Ok next idea:
Backup your good.passagiere.pak and use the one from pak64 in pak128, too - see if it still happens.
Eureka, a solution seems to be close ;) - thank for all tips (for example, using good.passagiere from pak64 makes trams profitable because it increases 3x the profit per passanger, but does not change the fact that the revenues were decreasing the the time).
When I was observing the proceeds from one tram line with one tram going always 100% full, I have noticed that they decrease quite a bit between years 2000-2028/29, but the trend is reversed later on by the city growth. This means that the negative influence stops acting in year 2028, which coincides with the last increase in the speed for speed-bonus for trains.
Hence, I made a small test - I set the speed for trains in speedbonus file of pak128 to the maximum 130 km/h. And look - trams are suddenly nicely profitable throughout the whole 21th century. Conversely, i can decrease the profitability of trams in pak64 by setting the train-speed in speed-bonus file to something very high. :-[
Thus, it seems there is a bug: for some reason, the calculation of profits for trams is based on the speed-bonuses for trains (or average for trams and trains?). It is not visible by default in pak64 since the trams in pak64 and pak128 have similar costs, but the price per passanger is three times higher in pak64.
EDIT: This makes it look like a bug rather than an extension request.
Ha. I suspected something similar, but good to have it actually tested and backed.
FYI trams started as 1:1 copy of trains (hence single tracks and signals), only filtering by waytype made it possible to build tram tracks over streets and sort the vehicles into respective depots. You can still connect tram and train tracks and the vehicles won't distinguish between them.
True. That was one of my earlier guesses as well, I even checked to see if pak64 and pak128 used a different waytype in their tram vehicles' .dat files - but they don't. And since you said the effect did happen in pak128 but not in pak64, I didn't really follow that path any further.
Has anyone tried to replace "schiene_tram" by "tram_track" in the vehicles' .dat yet? Does it work at all - and does it maybe even solve this problem?
Hm. I tried it, and it certainly works. So - commit, and let's see what people report for that nightly!
Thanks - I will certainly test it, but probably only on Sunday evening or Monday morning.
Take your time. But if that should solve that problem, I think it should be easy to fix in the source code, so that "schiene_tram" get recognized as "tram_track" as well.
This seems to be a .dat encoding problem in Pak128, so I move this to bug reports for Pak128.
If there is still a real bug in the program itself, this can be moved to bug reports (development).
This is rather a fundamental problem of the source: The tram waytype was never used for revenue calculations.
I have run various tests regarding the profit calculations for trams using the executable r2031 (the one containing "FIX: trams were not using the max speed according to the trams speed table" in the history file) and paks 64-99, 64-100, 128-135, and 128-140. The good news is: the problem is solved and gone - trams generate profit as they are supposed to (given # of passagers, cost, and speed bonus). Thank you all.