Author Topic: Month length in hours: reference sheet  (Read 10827 times)

0 Members and 1 Guest are viewing this topic.

Offline Carl

Month length in hours: reference sheet
« on: August 28, 2011, 09:28:56 AM »
[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

==========
« Last Edit: January 20, 2014, 11:02:44 AM by jamespetts »

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16086
  • Total likes: 438
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Month length in hours: reference sheet
« Reply #1 on: August 28, 2011, 10:13:08 AM »
Very useful - thank you! Stickied.
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.

Offline Carl

Re: Month length in hours: reference sheet
« Reply #2 on: August 28, 2011, 12:48:20 PM »
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.

Code: [Select]
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.

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16086
  • Total likes: 438
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Month length in hours: reference sheet
« Reply #3 on: August 28, 2011, 12:57:05 PM »
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.

Offline inkelyad

  • Devotees (Inactive)
  • *
  • Posts: 482
  • Total likes: 1
  • Helpful: 2
  • Languages: EN, RU
Re: Month length in hours: reference sheet
« Reply #4 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.

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)


Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16086
  • Total likes: 438
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Month length in hours: reference sheet
« Reply #5 on: August 28, 2011, 06:40:23 PM »
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.

Offline inkelyad

  • Devotees (Inactive)
  • *
  • Posts: 482
  • Total likes: 1
  • Helpful: 2
  • Languages: EN, RU
Re: Month length in hours: reference sheet
« Reply #6 on: August 28, 2011, 06:48:57 PM »
I don't know what is more strange: to have odd month length or to have some odd meters_per_tile. (Shrug)

Offline jamespetts

  • Simitrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 16086
  • Total likes: 438
  • Helpful: 177
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Month length in hours: reference sheet
« Reply #7 on: August 28, 2011, 06:52:08 PM »
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.

Offline Carl

Re: Month length in hours: reference sheet
« Reply #8 on: September 22, 2011, 04:01:21 PM »
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!

Offline neroden

  • Devotees (Inactive)
  • *
  • Posts: 831
  • Total likes: 0
  • Helpful: 28
  • Nathanael Nerode
Re: Month length in hours: reference sheet
« Reply #9 on: December 05, 2011, 09:18:57 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.