Belugas wrote:

I'm sorry, but i do not understand a thing about that request.
What do yo mean by "planned" production callbacks ???
And Day Lenght??? In OpenTTD??

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4894

George wrote:

Standard day length is 74 ticks. This means a month length is from 2072 to 2294 ticks. Industry production callback happens every 256 ticks. And this means it happens 8 or 9 times a month.
For OTTD there is a "daylength patch". The patch changes how many ticks there are per game day (e.g. daylength factor 2 means 148 ticks per day instead of 74 and thus, a month also has twice the number of ticks). This means a daylength factor 2 will change month length up to from 4144 to 4588 ticks. And, because production callback happens every 256 ticks, this means production callback happens 16, 17 or 18 times a month. I would like to get this value (number of production callbacks that happen this month for this industry)

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4895

frosch wrote:

Sorry, you are in the wrong place here. We do not support inofficial experimental patches here.
When you need a new variable for daylength you have to contact the patch maintainer and ask him, whether he/she wants to add such a variable, and how to detect its existance.
There is nothing wrong with patches implementing their own variables. Just like TTDP has its own experimental features (e.g. slope restrictions for station tiles) or OTTD has its own experimental features (e.g. 32bpp). Neither of those are supported in the other, as they are considered experimental, likely to change and generally not widely used.
If you do not get support from the patch maintainer, you should consider making you grfs independant from tick<->day relations. E.g. count the number of 256-ticks callbacks yourself in some persistent storage variable, which gets resetted in the monthly callback, or by using the already existing variables for monthly statistics. E.g.
var 94/95 (word) = Production cargo 1 this month so far until today
var 96/97 (word) = Production cargo 2 this month so far until today
var 98/99 (word) = Transported cargo 1 this month so far until today
var 9A/9B (word) = Transported cargo 2 this month so far until today
var 9C (byte) = Fraction of cargo 1 transported last month (0 = none, FF = all)
var 9D (byte) = Fraction of cargo 2 transported last month (0 = none, FF = all)
var 9E/9F (word) = Production cargo 1 last month
var A0/A1 (word) = Production cargo 2 last month
var A2/A3 (word) = Transported cargo 1 last month
var A4/A5 (word) = Transported cargo 2 last month

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4898

George wrote:

All these vars are not useful during callback 29/35, because they do not store the plan for the current (just started) month. Currently I used an assumption, that every month has 8 production cycles. Not correct, but does not provide a big mistake. A knowledge about exact number of production callbacks would allow more correct calculation (still a wish, not a must). I supposed that implementing such a var would allow GRFs to be compatible with new day length as soon as a patch will go into trunk. Also, putting a var into NEWGRF spec may prevent collisions in the future. IMHO.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4901

George wrote:

I mean such a var could be useful even in with the current trunk for me even providing only 2 possible results (8 and 9).

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4902

Belugas wrote:

What exactly would it be usefull for you to know if we're dealing with a 8 or 9 changes month?
Eludes me totally.
And as frosch mentionned, you can rest peascefully, daylengh patch will not hit trunk, not for a while.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4914

George wrote:

In the beginning on the month every secondary industry selects its' production level. The highest possible level is defined as maximum cargo, that can be produced from the current amount of material waiting. The industry knows amount of cargo already stored and divides it into the number of production cycles. Now I assume that there would be 9 cycles to guarantee material for every cycle (because it can happen that no material would be delivered this month). Knowing number of cycles would allow more correct calculation (in case of 8 cycles this month, industry has a bit wrong calculation - it plans unnecessary material for 9-th cycle).
As I wrote, such better calculation is a wish, not a must. It would not change the behaviour dramatically. As variant of the implementation, it could be a 6x var, with parameters 0 - current month, +n - n months after (up to 127), -n - n months before (up to -128).

P.S. I think such a patch should go into trunk someday.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363#comment4915

andythenorth closed the ticket.

Reason for closing: Won't implement

Daylength is not a current goal for OpenTTD. I believe there are patchpacks implementing daylength.

This comment was imported from FlySpray: https://bugs.openttd.org/task/2363