Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
PostHoldoff is FUBAR
Many of you may have noticed that three cröns in the default Nova scenario behave rather strangely. They are the news cröns 184, 185, and 192. Their pilotlog "duration counter" values appear to be in a never ending negative number countdown. This has always made me wonder and indeed there have been some topics related to this weirdness. Azratax2's thread touched on it and Beamup's thread also asked about it. Those old threads never generated an answer about this behavior.
The Nova Bible of 19Mar04 states:
PostHoldoff The number of days to hold the event in a waiting state after it ends and before it is deactivated. This is used to keep a repeating event from being activated immediately after it has just happened. Set this to zero to have the event be deactivated immediately after it ends.
Just not true. After a series of tests I've found that the definition of the actual behavior exhibited is as follows:
PostHoldoff: Even though this parameter is defined as a DWRD integer in the crön TMPL, it is actually treated as a flag. When PostHoldoff is set to any positive number it causes the crön event to be held in a waiting state after the OnEnd(set) statement is executed. The length of the waiting state is determined by the number of days specified in the PreHoldoff parameter. Additionally, if the Duration parameter is greater than zero, then the waiting state is doubled. Set PostHoldoff to zero to have the crön event be deactivated immediately after the OnEnd(set) statement is executed. WARNING- If PreHoldoff is zero when PostHoldoff is any positive number,then the waiting state will have a value of 32767.
In order to achieve PostHoldoff as defined in the Nova Bible, one would have to use a second crön in conjunction with an additional NCB as follows: 1st crön has the developer's desired functionality plus EnableOn(test) includes !b<n>, OnEnd(set) includes b<n>, and PostHoldoff := 0. 2nd crön EnableOn(test) := b<n>, Duration := desired pseudo-PostHoldoff number of days, and OnEnd(set) := !b<n>, PreHoldoff :=0, and PostHoldoff := 0.
(note: FUBAR = Fouled Up Beyond All Recognition)
I've reported this to the beta list.
Nice find, but ive never had a reason to use postholdoff. preholdoff and duration are plenty.