Exp9.11: Still too high revenues

[AvG]

Hi James,
Exp9.11 seems a lot better now.
The revenues however are still way to high.
Another problem is not being able to change meters per tile on the fly.
Have you solved the problem here?
I run a large scenario. The Netherlands, 250 m/tile it should be (acc. config), but the mapscale says
1 km per tile. This is probably caused by the problems of the previous releases.
As you know I have to start allover again, (which is with a hightmap-based scenario quite a job) to get a mapscale of 250m/tile.
If the mapscalechange feature will be on in the next release I better wait for that.
I am curious what the number of passengers will do when my rail-network is ready.
With only a small part ready Amsterdam (1830) with only 6900 inh has already over 10000 arrivals/month
AvG

[jamespetts]

AvG,

I have tested the revenue quite extensively following the problems with the previous release - can you elaborate somewhat on why you think that the revenues are too high (and perhaps upload a saved game)? If you upload a saved game, I might be able to reset the distance manually to what it was; it is possible, I suppose, that using a previous version of the game to change the distance scale caused your revenue issues, as it is not possible to change the distance scale properly on the fly (which is why it is disabled in 9.11). If I reset the distance scale on your scenario to the distance scale used when it was created, it should work properly. Alternatively, you could just load it with 9.10, change the distance scale back, re-save it, then load it with 9.11.

To clarify, however, the ability to change the distance scale on the fly was removed on purpose, and will not likely be reintroduced, as it is not practicable to make it work properly because many of the scaled values are set once and for all at the beginning of the game, and are then lumped together in a way that makes it exceedingly difficult to unpick on the fly.

[AvG]

James,
I kept it simple; just started a new scenario.
Holland, 1830, 250m/tile, 24_bits_month, pass.fact=16, start cap 50.000 Cr.
Scenario is now running 6 weeks.

Some quick observations:
- 1 Towncoach with 2 horses: Investm. 494 Cr Profit/month 664 Cr >> Payback time ~3 weeks.
- Locomotion with 5 cars: Investment <6000 Cr Profit/month >11000 Cr >> Payback time ~2 weeks.

These odd figures are the result of a combination of some influences.
- 24-bits setting results in incredible amounts of maintenance. In fact that much that realism is gone. Busstop newprice 20 Cr with maint. 16 Cr/m
- Pass. fact=16 gives a very high efficiency on your vehicles. The whole town is on the move. If the density is increasing I am in troubles, because the next 70 years I will not have a real improvement in city-transport. I do have already trams in town. I need however more time to come to a conclusion if 16 is to high.
- Pass/Mail revenue: 0,21/0,24 Cr/km. A Locomotion with some cars cost ~1,50 Cr/km. So a load of 4 pass and 4 mail is already a little bit profitable.

PRELIM Conclusion:
- Let's get rid of bits_per_month. Use normal km/h, 24h/day+night, 7 days/week, etc. If you think the game-speed will be to slow you have keys for speeding up.
  It will be possible to implement time-tables, use day and night, so realism will be better.
- I will do more testing via my scenario. I still have to add 150-200 towns. At the moment there is no industry. What will town-growth do?
AvG

[fbfree]

AvG, I think I had the same problem that you currently have when trying Experimental 9.8.  I fixed it by upgrading Simutrans to 110, Pak-Brit-Exp to 0.8 from 0.7, and making sure all my configuration files were up to date.  I'm not sure which step fixed it for me, and it might be nice to figure out which one it was.  I kept pak-brit-exp-0.7 on my machine and it seems to work okay now with both Experimental 9.8 and 9.11, although I've also since replaced my ~/simutrans/default.sve and ~/simutrans/settings-experimental-debug.xml files.

First, move your default.sve and settings-experimental-debug.xml into backup files, and remove them.  Then try running.
Second, try making sure both the pak configs and the simutrans configs are up to date.
If either of the above steps fix the problem, post a diff of the new and old configuration files.  Otherwise, try the remaining upgrades.

[inkelyad]

- Let's get rid of bits_per_month. Use normal km/h, 24h/day+night, 7 days/week, etc. If you think the game-speed will be to slow you have keys for speeding up.

And then I set show_month to 1. (try this)

Sorry. Month length is main time-related parameter in simutrans. More, I think show_month=1
is least confusing settings. All speed/time calculations in code make a lot more sense when you use it. All others date/time options are eye-candy.

- 24-bits setting results in incredible amounts of maintenance. In fact that much that realism is gone. Busstop newprice 20 Cr with maint. 16 Cr/m

With this setting your bus will make a lot more loops in one month. So maintenance is adjusted. I think idea was: "profit must be same for 1h of real-time for any bits_per_month".
EDIT: You can read long commentary about it here.

[Carl]

Am interested to see this topic -- I've found revenues in 9.11 to be oddly *low* in some cases! Examples include hundreds of passengers leaving a long-distance convoy and the resulting revenue being 0.02c (on a line with zero refunds).

[jamespetts]

Carl,

can you provide a reproducible scenario (preferably including a saved game)?

[EnternalD]

I find revenues in early times high, but if you start in 1930-40s they are low, so these values should be changed only after testing.

[Carl]

Carl,

can you provide a reproducible scenario (preferably including a saved game)?

I'm not able to upload anything right now (am between internet service providers) but I'll check and see whether this issue arises with the last save I uploaded.

[jamespetts]

We need to distinguish between, on the one hand, bugs in the game engine, and, on the other hand, balancing issues. The former are urgent matters that need to be resolved before new features are added; conversely, the balancing can only be done when a number of planned balancing-relevant features are added, without which a proper balance cannot effectively be achieved. See this thread for details on the latter.

Carl - thank you: let me know when you can upload.

[AvG]

James, Inkelyad,

-Would it be possible for the next release to add in the settings an extra button to switch on/off the relation between maintenance and bits_per_month?

-Is it possible/difficult to leave the bits_per_month approach and switch to km/h? (lots of new possibilities to increase realism)

I will open a new thread for the balancing-stuff.

AvG

[jamespetts]

AvG,

it would not easily be possible to do this, as the bits per month system is quite fundamental to how much of Simutrans works; why do you think that the bits per month scaling is a problem? I also do not understand what you mean by a switch between bits per month and kilometres per hour - they are not the same thing. Bits per month is the measure of how much real time has to pass for any given amount of calendar time in the game to pass. It is not the same as the amount of actual game time to pass, which can be set with the < and > buttons. Kilometres per hour, conversely, measures the speed of actual vehicles. I do not really understand how one can substitute for the other.

[inkelyad]

AvG, why are you using 24 bits per month?

[AvG]

James,Inkelyad,
I use 24-bits in order long time-periods for monthes, years, etc.
Working this way means:
- You have more time to check what's going on, without necessity to pause often.
- After some experience you know what vehicles are to be expected.
   Because the long periods you cannot permit yourself NOT to use the next imperfect vehicle.
- Vehicles on the map are closest to their scale-speed. 25-bits would even be better.

Leaving the bits_per_month system and using the already existing clock gives a lot of interesting possibilities.
-Using night and day with eventually restrictions
-Simulating rush-hours. Starting/closing time industries.
-Introducing real time-schedules for vehicles.

AvG
-

[Carl]

Carl - thank you: let me know when you can upload.

Just to say that I wasn't able to reproduce this error after all, so no need to worry about it I think.