bits_per_month and simunits

[Mariculous]

Not quite sure where to place general questions about the code, I guess it fits best here.

1. Is there any good reason why month lengths in ticks are defined as 2^bits_per_month, instead of setting the month length in ticks directly or is this simply a historical thing?
2. Why don't we have access to world or settings from simunits?

[prissi]

1) Several calculations involving month length exist. Those use shifts instead of divisions, which is easier to handle also precision losses due to bits falling off left or right. However, in principle, the performance penalty is probably neglibile nowadays if one changes to normal numbers. I would just affect a lot of places in the code.

2) Not sure what you mean here. Ticks per month cannot be sensibly changed during a game without breaking costs and statistics. The same it true for a lot of other settings, which is why the setting dialog is hidden in most pak sets.

[Matthew]

2. Why don't we have access to world or settings from simunits?

2) Not sure what you mean here. Ticks per month cannot be sensibly changed during a game without breaking costs and statistics. The same it true for a lot of other settings, which is why the setting dialog is hidden in most pak sets.

Maybe he is asking why simunits.h, and in Extended, simunits.cc, do not #include simworld.h?? I am not a coder, so I am just guessing.

[Mariculous]

Thanks Prissi, so consistently changing this might be an option to relate ingame time to real world time more preciesely.
There is a lot of shifting stuff in the code anyway, where modern compilers would simply optimise to shifts anyway. I guess that's simply for hostorical reasons, I won't change that.

2. Mathew is right.
At least in extended code there are some extern declarations and setting values passed in the conversion function, where that could simply be read from settings directly if we had access to the settings.
So I was wondering if there is a good reason why one might not want to access settings from simunits.cc and the inlined functions in simunits.h

Btw. maybe that's an extended thing but I am 100% sure I had increased bits_per_month in my last game by 2 somwhere in the 1990s so It takes longer to get to the future.