News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Month length in hours: reference sheet

Started by Carl, August 28, 2011, 09:28:56 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carl

[NB. Updated Sept 22 to include new "meters_per_tile" values]

Given the new option in 10.0 to display month length in terms of "in-game hours", it's possible that players will start to ask "how can I make a month last X hours?"

As far as I can make out, month length is determined by two parameters in simuconf.tab: bits_per_month and meters_per_tile/distance_per_tile (depending on which is used). I've done some experimenting and have produced the following crib sheet for different combinations of these values. My goal was to find the combination which provides the roundest possible month length.

Do let me know if you find any mistakes below!

Note that 'mpt' stands for 'meters_per_tile', and 'dpt' stands for 'distance_per_tile'.

==========

bits_per_month = 18

                   Month length (hh:mm:ss)

mpt: 313  ...   01:00:05
mpt: 625  ...   02:00:00

dpt: 16   ...    0h 31m
dpt: 25   ...    0h 48m
dpt: 32   ...    1h 01m
dpt: 63   ...    2h 01m

==========

bits_per_month = 19

mpt: 157  ...   01:00:17
mpt: 313  ...   02:00:11
mpt: 625  ...   04:00:00

dpt: 16   ...    1h 01m
dpt: 25   ...    1h 36m
dpt: 32   ...    2h 02m
dpt: 47   ...    3h 00m
dpt: 63   ...    4h 02m

==========

bits_per_month = 20

mpt: 157  ...   02:00:34
mpt: 313  ...   04:00:22
mpt: 469  ...   06:00:11
mpt: 625  ...   08:00:00


dpt: 16   ...    2h 02m
dpt: 25   ...    3h 12m
dpt: 31   ...    3h 58m
dpt: 39   ...    4h 59m

==========

bits_per_month = 21

mpt: 157  ...  04:01:09
mpt: 235  ...  06:00:35
mpt: 313  ...  08:00:44
mpt: 469  ...  12:00:22
mpt: 625  ...  16:00:00

dpt: 12   ...    3h 04m
dpt: 16   ...    4h 05m
dpt: 24   ...    6h 08m
dpt: 39   ...    9h 59m
dpt: 47   ...   12h 02m
dpt: 94   ...   24h 04m

==========

bits_per_month = 22

mpt: 156  ...  07:59:23
mpt: 157  ...  08:02:18
mpt: 196  ...  10:02:06
mpt: 235  ...  12:01:55
mpt: 313  ...  16:01:32
mpt: 469  ...  24:00:44
mpt: 625  ...  32:00:00

dpt: 12   ...    6h 09m
dpt: 25   ...   12h 48m
dpt: 40   ...   20h 28m
dpt: 47   ...   24h 04m

==========

bits_per_month = 23

mpt: 118  ...  12:05:04
mpt: 157  ...  16:04:36
mpt: 196  ...  20:04:12
mpt: 235  ...  24:03:50
mpt: 313  ...  32:03:04
mpt: 469  ...  48:01:28
mpt: 625  ...  64:00:00

dpt: 12   ...   12h 17m
dpt: 24   ...   24h 34m
dpt: 40   ...   40h 56m

==========

jamespetts

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.

Carl

If distance_per_tile could be specified to a finer grain -- i.e. to increments of 1m rather than 10m -- then it would be possible to have "rounder" month lengths.

I've played around with some of the values in Einstellungen.cc -- specifically, making distance_per_tile = meters_per_tile rather than 10 times smaller -- and have managed to compile a version in which distance_per_tile is given in metres.

With this enabled, for example, we can make a month last 4:00:23 with values of bits_per_month=20 and distance_per_tile=313.

However, the version I've compiled breaks existing savegames which have distance_per_tile values below 100. What's needed is a clause like I've written below in pretend code.


If distance_per_tile =< 100, then meters_per_tile = (distance_per_tile * 10)

Otherwise, meters_per_tile = distance_per_tile


Writing this in real code is beyond my (very limited) capabilities. With this in place, an existing savegame with a distance_per_tile of 40 would receive a meters_per_tile value of 400 -- the same as it receives in the current version.

jamespetts

That's an interesting idea; the distance per tile value is already stored as "meters per tile" in einstellungen.cc, but it is saved as units of ten. The best way of implementing this would be: (1) to change the saved game value to single meters in Experimental versions >= 10, multiplying values read from versions <= 9 by 10, and (2) add an additional parameter to simuconf.tab, "meters_per_tile", which, when read, will set the "meters_per_tile" value directly, leaving the existing "distance_per_tile" value to have its existing effect (if both are specified, the "meters_per_tile" should have the priority). This will maintain compatibility with old saved games and old simuconf.tab files.
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.

inkelyad

With some work it is possible to change bits_per_month parameter to ticks_per_month. It will cost us some speed (not sure about this. Is shift operation faster then division on modern CPU?) and Standard compatibility.

Or we can really carefully adjust  VEHICLE_SPEED_FACTOR in simunits.h (carlbaker,  you can play with it. I think it will break things somewhere, but it will be interesting experience)


jamespetts

Inkelyad,

if you have a look, I have implemented what I suggested in the above post in the 10.x branch, which is probably the simplest and most compatible way of doing things.
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.

inkelyad

I don't know what is more strange: to have odd month length or to have some odd meters_per_tile. (Shrug)

jamespetts

I suspect that odd meters per tile would be the most difficult to accommodate.
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.

Carl

I have now updated the original post in this thread to show which "meters_per_tile" values should be given for greater precision in month length -- for those who desire it!

neroden

Quote from: inkelyad on August 28, 2011, 06:26:42 PM
With some work it is possible to change bits_per_month parameter to ticks_per_month. It will cost us some speed (not sure about this. Is shift operation faster then division on modern CPU?) and Standard compatibility.
Yes, shift is still faster than division.  Division is SLOOOOW (well, by microprocessor standards).  The question is whether the division is being done often enough for this to matter; the answer is "maybe not".

Quote
Or we can really carefully adjust  VEHICLE_SPEED_FACTOR in simunits.h (carlbaker,  you can play with it. I think it will break things somewhere, but it will be interesting experience)

If I ever finish my simunits.h work my hope would be that this would all be much easier to adjust.

Matthew

I have put Carl's helpful data about bits-per-month (bpm) and meters-per-tile (mpt) into a chart that players can use to help us select the best values for our games.

The chart is available as a PDF (editable file is page 3 of this ODT).

I have put question marks next to 'underpopulation' and 'overpopulation' as I am not sure whether the population of cities (i.e. city buildings) is adjusted for mpt. I have noticed that mpt is used in get_einwohner(), perhaps for this purpose, but I wasn't sure.

As this information is useful for players as well as developers, I wonder whether this thread should perhaps be moved to the Discussion subforum?

The file also contains what I know about the scale settings for that are used in pak128.Britain, as I have not found this information anywhere else. Does anyone know what the scale parameters are for the other paksets? It's useful information who anybody who wants to mod the paksets.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。