News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

rounder time per month values

Started by Mariculous, November 30, 2019, 11:32:20 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Mariculous

I had already posted this in the month Month length in hours: reference sheet a few weeks ago but that was at a time where the forum had huge trouble so I don't know if anyone could read it and I guess it's worth a discussion thread on its own so I moved it here.

First, I want to thank both of you, Carl and Matthew, for this reference sheet, it's nice work!

However, I had some thoughts about month lengts and distances. The current time per month doesn't really satisfy me, as I recognized users being confused of 1:04/32/16/8... minutely schedules and 6:24:00 hours long months when it comes to calculating schedules, thinking in "half hourly" services, where these are actually 32 minutely

What do we want?
Ideally we want
- round meters_per_tile values
- round time per month values
- round schedule times for as many "schedules per month" values as possible

Currently, we can not achieve this due to some odd ticks to second conversion.
The first point ist obviously fullified, if a round meters_pe_tile value is set in the config.
The second point depends on the definition of "round time per month". I would define it: ~"we have a round time per month, if a month length is a multiple of a full hour" This is obviously fullified, if the calculated seconds per month is a multiple of 3600, which is currenly only the case for meters_per_tile values that are multiples of 625. Multiples of 125 will at least have full minutes. Anything else will be odd.

The third is a bit vague as "as many as possible" is not pretty well defined.
However, we will get many round schedule times, if our month length in minutes has many divisors.
360 or a multiple of it is a good number for this, which would be a month length of 6:00:00 or a multiple of it.
btw. angles in degree use 360° for a full turn because it is a relatively small number with many divisors.
Now we know what we need.

How can we achieve it?
A possibility would be simply altering the ticks to seconds conversion function by multiplying currently returned value by 60/64, so what was 6:24:00 before will be 6:00:00 now. As this is just a visual effect, I don't expect that change to negatively affect schedules, as these are still exactly the same in ticks.
Currently that function is
get_settings().get_meters_per_tile() * ticks * 30L * 6L / (4096L * 1000L)
We could change it to something like
meters_per_tile * ticks * 27/(4096*160)
That way we will get a month length of 6:00:00 for 125 mpt, 22 bpm

If vehicle movement speeds matches to the time currently displayed time, that means a vehicle travelling at 100 km/h for one hour in a mpt 100 world, will travel 1000 tiles, and we consider that consistency to be important, we would also have to apply that 60/64 factor to simmulation speed, which could be a slightly larger job, I didn't look at this.

As there is a comment in the code mentioning that we should seperate the time scale from meters per tile, I don't expect it to be important. To seperate it, we could do something like this:
time_scale * ticks /2^18
That scales month length to be 00:00:01 for 18bpm, time_scale 1.

To get 6:00:00 months at bpm 22, we would set a time_scale of 60*60*6/2^(22-18)=60*60*6/16=1350

If no time_scale is given, we could use meters_per_tile*11.52, so we would get the same month lengths as before, or alternatively meters_per_tile*10.8, so we would get 6:00:00 instead of 6:24:00

Alternatively, we could also eliminate bits_per_month
seconds_per_month* ticks /2^bits_per_mont
That scales month lengths to be always 00:00:01 for time_scale 1, no matter the bits_per_month nor meters_per_tile.
As this is straight forward to use for pakset developers, I don't think we should do this, as players sometimes prefer more or less bits_per_month and changing bits_per_month should imho scale paksets default month length.

Mariculous

*dig*

I just made a quick and dirty implementation of this.
You can have a look at it in the time_per_month branch on my github.

I have introduced a seconds_per_month config parameter, which will be used for ticks to time conversion and is independant of meters_per_tile and bits_per_month.
It will not affect actual month length in real-world time, so vehicles will travel the same distance within a month as before. This ensures schedules to work just as before.

However, this obviously leaves a distance/time inconsistency.
A vehicle travelling constantly at e.g. 100 km/h for 1:04:00 before the the introduction of time_per_month will travel a distance of ~107km or ~853 tiles. When changing the month length to 6:00:00 the vehicle would travel the same distance at the same speed in 1:00:00.

To make this consistent again, I will need to adjust the simspeed to m/s and vice versa conversion.
This, however will break existing schedules, thus seconds_per_month needs to be stored in the save and needs to default to current mpt/bpm based calculation if not set.

Further considerations:
Affecting vehicles simuspeed whilst not affecting passenger/mail/cargo generation will leave another inconsistency. I.e. the same amount of passengers will be generated per month but vehicles will move more or less distance per month.
So I should also scale any passenger/mail/cargo generation depending on the time_per_month value.

Ranran(retired)

Currently, it seems that the physics calculation correctly performs the theoretical acceleration time. Does this have any effect?

Regardless, it's great to be able to use intervals of 6 hours, 15 minutes and 30 minutes and so on.  :)
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

Mariculous

Firstly sorry I forgot to push it, so here it is now :/
https://github.com/irgend42/simutrans-extended

Secondly


Quote from: Ranran on January 22, 2020, 12:45:26 PMCurrently, it seems that the physics calculation correctly performs the theoretical acceleration time. Does this have any effect?
As mentioned above, it has an effect. That's what half of the post above is about. I am considering to fix this by altering vehicles simuspeed properly in relation of meters_per_tile and seconds_per_month.
This however, as mentioned WILL break existing schedules, so it should not be set once a map was started.

jamespetts

My apologies for not having responded to this earlier: it is easy for things to get lost when there is a backlog.

There is a fundamental problem in altering the relationship between the long and the short time scale, in that all physics and vehicle movement is tied to the short time scale. Thus, without changing all the vehicle movement calculations to adapt to any modified time scale, the current very carefully calibrated realism in the relationship between timing and physics will be destroyed, which is contrary to one of the fundamental aims of Simutrans-Extended, viz., to maximise realism.

The reason for the current time scales being non-rounded is precisely that doing anything else would require a fundamental rewrite of all the vehicle movement code; the time scale is already implicit in the vehicle movement code once one sets a distance scale. Anything else would fundamentally break this relationship. The vehicle movement code in terms of its relationship between in-game distance and time is unchanged from Standard, although there is a new physics engine (but working to the same assumptions as to speeds).

If you are actually able to alter the physics engine and all other parts of the code scattered in various undocumented places that interact with vehicle movement so as to make all vehicle movement speeds fully customisable (and entirely consistent at any customised setting within the range allowed by the code), then that would be quite an achievement. All other things being equal, it is better to have rounded numbers than not; but this will be a huge amount of work, I suspect.
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.

Octavius

Quote from: Freahk on January 22, 2020, 11:27:59 AMI just made a quick and dirty implementation of this.
I once (privately) made a very quick and dirty fix to this problem too. Basically, I redefined the clock. Just a few changes to the function that converts times in seconds to a time string in h:mm:ss made minutes of 64 seconds each. It worked quite well, making it much easier to create schedules, but with the inconsistency you mention.

Mariculous

#6
I did not have a look at physics code recently but as far as I remember there is no simutime nor simudistance related code in there. It's all calculated generically more or less to the rules of physics, scaling simutime (ticks) to seconds, doing the physics stuff and later on scaling meters to simudistance (fractals of tile), thus it should not be too hard to tweak the simutime_to_seconds conversion.
The seconds_per_tick conversion factor is set in set_meters_per_tile, depending on some variables. I will have to figure out the exact relation of these to set this factor properly.

I will have a more detailled look at it later on, but now I should better learn on for my exam.

Mariculous

#7
*dig* this is not forgotten nor lost.
I was at the North Sea for a few days and waved to the west but didn't see James answering on the other side.

After some careful considerations, nearly rewriting simunits and moving all distance, time and unit conversions to simunits, where they belong, I got working code with consistent movement.
If there are fewer seconds per month, time will pass by slower, thus vehicles will also move slower to maintain time, distance, speed consistency.
Btw. if seconds_per_month is not set (set to 0), it will be calculated from bits_per_month and meters_per_tile to maintain the same time scale as before.

However, I guess I will further need to set the scale in karte_t::set_scale() differently.
Currently, it will scale everything by meters_per_tile.
I guess I need to keep this for distances but use another scale, calculated from time and distance scale to maintain the same number of e.g. passenger generation per hour.
Is this correct or did I get something wrong? If the current pasenger generation level and stuff like that is (or should be) based on the number of passengers generated per hour in the real world, this would make sense.

Changing seconds_per_month will for sure break schedules if the seconds_per_month/ticks_per_month ratio changes as schedules are not based on time but in fractions of a month.
However, this should not be an issue as currently changing bits_per_month will also break schedules.
Further, this cannot be changed if we want to stick with "run n times per month" schedules instead of "run every n minutes" schedules.

jamespetts

There is an awful lot that is scaled by meters per tile in the game - look for the set_scale() methods in various parts of the code. I am afraid that I cannot recall all of them now. Certainly, anything calibrated to time in any way is thus scaled, including the passenger generation.

Does this answer the question? I am afraid that it is very difficult to remember details about parts of the code on which I have not worked recently.
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.

Mariculous

Hmm, no it does not really help.

I had found that function and initialise time, distance and speed conversions from there, that's all not an issue.
The point I am not 100% sure of is if scaling time related stuff like passenger generation properly by the time scaling and scaling any distance related stuff by meters_per_tile only is what we want to do to keep the balancing constant when the time passes by at any other speed than the default speed.

Further, I am trying to make all these time, distance, speed stuff a little bit easyer, so I thought about the tenths of minutes unit. Why don't we simply use seconds?
Same goes for yards and steps. I understand that tiles might be a good option for the large scale but why do we need steps in between yards and tiles?

jamespetts

I believe that steps was a much earlier invention in the code than yards, going back to the early days of Simutrans; yards, I believe, were introduced in the 2010s, possibly specifically for Extended (albeit not by me). I imagine that all the systems that already used steps were simply not changed.

As to whether any other things would be affected, other than pointing out that building size is affected by area, which in turn is affected by linear distance, it is very, very, very difficult to give a definitive answer to the question: I simply do not keep in memory all of the vastly complex systems of the game at once, other than in general overview, so I have no better way of answering the question than you have. All that I can suggest is tracing all parts of the code that touch anything that touches anything that touches (etc.) meters_per_tile or bits_per_month of any of the constants assumed in the vehicle movement code to work out how the relationships currently work and what would be changed (including remote implications of apparently minor changes) if any changes to any of that code were made. I anticipate this being a huge undertaking.
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.

Vladki

Quote from: Freahk on March 04, 2020, 07:42:42 PMFurther, this cannot be changed if we want to stick with "run n times per month" schedules instead of "run every n minutes" schedules.

But even in real world scheduled services are scheduled n times per hour, or every x hours (or even n times per day, or per week).  You will probably not find a service that runs every 17 minutes

Mariculous

#12
Thanks James, I guess you kind of got me wrong but I think you agreed in "changing all distance stuff by distance only whilst properly using the time scale for anything that is also time affected, like passenger generation, speeds and so on" makes sense.
I have already moved a few related parts of code to set_scale that had not been there before, and will finally check if everything affected by mpt and bpm is properly scaled.

About the schedules per month/schedule every part:
Using the current n times per month scheduling, you can perfectly well set up a line that runs roughly every 17 minutes. Creating such odd schedules is not the point!

In the real world "run every x minutes" and "run n times per hour" are more or less exchangeable. It's up to the transport company to pick a frequency people can remember.
Depending on how you read a timetable like e.g. 00 10 20 30 40 50, you can read "the bus runs every 10 minutes" or "there are 6 busses running per hour".
The same goes for simutrans: It doesn't really matter if we setup a line to run every hour or to set up a line to run 6 times per month, assuming the month has 6 hours.

The problem kicks in when we do something we cannot do in the real world:
Assume a line scheduled for 1 schedule per month.
Now we tell Simutrans that an hour is now half as long (in ingame time, still the same in real-world-time) than it was before. I.e. the same period of time we called 1 hours before is now called half an hour.
Vehicles have a maximum speed defined in km/h. As km/h is obviously derived from our new hours, that train will move at effectively half of it's speed (passing less tiles in the same real-world time)
Thus, it won't get its monthly schedule. Maybe we could adjust the schedules per month in that case but what is 0.5 schedules per month, or even worse, assume we had scaled the time by 60/64 (or any other quite odd value)
In case of "schedule every n minutes" this would not be an issue. A vehicle that makes its schedule before the change will also make it after the change.

The only thing that will break schedules are changes in meters_per_tile. Assume changing meters_per_tile from 125 to 250, a train will effectively need roughly twice the amount of time to travel along a track as it's now twice the distance at the same speed.
We could fight this for more-or-less odd meters_per_tile by scaling schedule times by that factor but I don't think that makes much sense as meters_per_tile is a quite balancing critical parameter:
decreasing meters_per_tile will decrease distances, thus decrease travel times but also decrease the number of passengers generated per time, so decreasing meters_per_tile from e.g. 250 to 125 will result in doubled line capacities whilst generated passengers are halved. We can adjust trains travel speed again by also dividing seconds_per_month by 2 (which happens automatically if the value is not explicitly set), so vehicles move at their previous speed again, but there will still be only half the amount of passengers generated, so from a demand point of view it would be tough to also decrease schedule frequencies by that factor but from a travel time point of view, vehicles will be waiting half of the time in that case.

Phystam

Bits_per_month is the logarithm of time length. If it is allowed to use decimal, the discussion will become easier, right?

Vladki

Is it really necessary to care about changing the distance and time scales during the game?
The only thing I would care is that balancing is not broken. So just carefully choose what should be scaled with meters_per_tile and bits/seconds_per_month

Mariculous

#15
Quote from: Phystam on March 05, 2020, 12:32:08 AMIf it is allowed to use decimal, the discussion will become easier, right?
No, or at least not really. The discussion will remain nearly the same. Changing ticks_per_month will affect schedules in just the same way as changing bits_per_month does, we will just have a finer scale for real world time per ingame month (ticks_per_month:=2^bits_per_month is the real world time in milliseconds of an ingame month)

Quote from: Vladki on March 05, 2020, 12:37:23 AMIs it really necessary to care about changing the distance and time scales during the game?
No, not really but if we don't want to break schedules on changes of the time scale, we should set schedules based on ingame seconds instead of setting schedules in fractals of a month.

Quote from: Freahk on March 04, 2020, 07:42:42 PM
Changing seconds_per_month will for sure break schedules if the seconds_per_month/ticks_per_month ratio changes as schedules are not based on time but in fractions of a month.
However, this should not be an issue as currently changing bits_per_month will also break schedules.
Further, this cannot be changed if we want to stick with "run n times per month" schedules instead of "run every n minutes" schedules.