Skip to main content ↑ ↓
Topic: Would a ticks_per_tag->ticks_per_world_month change be accepted? (Read 3096 times) previous topic - next topic

Would a ticks_per_tag->ticks_per_world_month change be accepted?

OK.  So here's a practical example where I'd actually like to translate some of the code.  ticks_per_tag and ticks_bits_per_tag (etc.) are actually referring to ticks per *month*.  The German isn't even *correct* anymore.  (I ****ume a month used to be a day....)

My proposal is to change the names as follows:

ticks_per_tag -> ticks_per_world_month
ticks_bits_per_tag -> ticks_per_world_month_exponent
set_ticks_bits_per_tag -> set_ticks_per_world_month_exponent

Rationale:

* The addition of the word "world" is as an attempt to systematically differentiate between the two timescales: world months/world years/world days/world hours vs. vehicle hours/vehicle minutes.  Since both timescales do get used in many different places (in particular, both timescales get used in simvehikel.cc), it seems desirable.  A different adjective could be used if you have a better idea.
* Replacing "bits" with "exponent" is an attempt to make it read better in English, making it clearer what's going on with the bitshifts.  It could be left as "bits" if this is thought to be too long.
* Moving "bits"/"exponent" to the end makes it easier to do text searches of the code (a search for ticks_per_world_month would now find everything), and makes it read better in English.

What do the maintainers think... would some version of this be acceptable?  Any suggested changes before I prepare a patch?

I'm hoping to tidy up the time/distance/speed conversion code (without sacrificing efficiency), and this is a logical first step.  I like to do programming in digestible bite-sized chunks, hence my proposal for a small and largely cosmetic change to start with.  I specialize in code cleanup which doesn't change functionality.  :-)

Incidentally, the factories seem to have their own entire system of units.  Would a set of patches separating out the unit conversions for the factories into their own (static inline const) subroutines be interesting?  And/or should the factory code be reworked to stop using these units as much as possible?  (I think some of them are saved in config files, pak files, and saved games?)

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #1 –
Actually, a month is a day in default setting (show_month=0). In the old version it was three days, thus the name.

Furthermore, there are no different time scales. The vehicle code does not use any timing. Or it seems that I do not get your idea.

Exponent is also not correct; then rather use bit shift or something.

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #2 –
Prissi,

the vehicles do have a different timescale: the number of tiles that they traverse per unit of time at any given speed. On the ****umption that 1 tile = 1km (or any other value), this can be extrapolated into a specific time scale.

This is made more express in Simutrans-Experimental where journey times and waiting times are precisely calculated, but it is implicit in Simutrans-Standard in any event.
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.

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #3 –
Without going technical: There is the speed of vehicles, but simutrns never ever had a formula for conversion (and it changed slightly also twice during the last four years).

But back on topic:
I thing
world_ms_per_month
world_ms_pre_month_shift

would be also ok, if really needed.

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #4 –
Quote from: prissi – on
Without going technical: There is the speed of vehicles, but simutrns never ever had a formula for conversion (and it changed slightly also twice during the last four years).
Yes, exactly.  There is an implied timescale based on the "speed" of vehicles, which is totally different from the world timescale.  (But knowing the timescale matters a lot if you're trying to fully supply a factory's demand for service.)  I know simutrans never had an explicit conversion formula.   I hope to, in future, put in a subroutine which *will* do an explicit conversion so that the conversion ratio can be displayed in-game.  (Without impeding the ability to change it later.)  Sorting out the various time-related code is part of that.  As long as there are two timescales, I think it's worthwhile for the player to be able to easily figure out what the conversions are -- I have to figure out the conversion *routinely*, in every game I play.

The alternative to keeping the two timescales is to specify all vehicle speeds in terms of the world calendar ("5 km/month" :-) ), but this seems likely to confuse players even more....

Quote
world_ms_per_month
world_ms_pre_month_shift

would be also ok, if really needed.
Sounds fine, but
- do you think that ticks will *always* be milliseconds?  "ticks" may be a better choice if they might change sometime, to 100 nanoseconds or something.
- "world" really is an adjective applied to the time unit, months.  As such it should be next to it.  "world milliseconds" is wrong, the milliseconds are not part of the world timescale, they're part of, well, the third timescale, the computer timescale.  :-)

"shift" sounds like a good choice.

ticks_per_world_month
ticks_per_world_month_shift

?

Thanks for the feedback....

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #5 –
ticks would be fine too, since the variables are now called ticks_xyz anyway (see you first post)
Parsley, sage, rosemary, and maggikraut.

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #6 –
Quote from: neroden – on
Yes, exactly.  There is an implied timescale based on the "speed" of vehicles, which is totally different from the world timescale.  (But knowing the timescale matters a lot if you're trying to fully supply a factory's demand for service.)  I know simutrans never had an explicit conversion formula.   I hope to, in future, put in a subroutine which *will* do an explicit conversion so that the conversion ratio can be displayed in-game.  (Without impeding the ability to change it later.)  Sorting out the various time-related code is part of that.  As long as there are two timescales, I think it's worthwhile for the player to be able to easily figure out what the conversions are -- I have to figure out the conversion *routinely*, in every game I play.

Have a look at the formulae in Simutrans-Experimental that do that...
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.

Re: Would a ticks_per_tag->ticks_per_world_month change be accepted?

Reply #7 –
As promised, patch attached.  Renaming patches tend to be big, but this one isn't that bad.