I'm having a devil of a time getting crons to work right.
Their behavior seems to change without rhyme or reason.
Is there a annotated cron template somewhere?

I'm aware that if pre, duration, post are all 0, then the OnEnd will excecute twice. (Although I have found that this is not always the case for some reason.)

I'm trying to get around this buy setting a bit to run a different cron so I can use its OnStart field.

(pre, duration, post set at 0 for both crons)
Cron 1:
EnableOn: b1
OnStart: (an iterative function to do stuff)
OnEnd: !b1 b2

Cron 2:
EnableOn: b2
OnStart: !b2 g128
OnEnd:

I only want outfit 128 to get added once. So I can't put it in the iterative loop, and can't put it in the OnEnd of cron 1 since it gets executed twice. Setting a bit twice shouldn't matter, though.

Now what happens is that outfit 128 get added twice anyway! Even if I put 1 day into the post holdoff.
Even more strange, I have used the exact same functionality with different items and crons in another place, and it works perfectly.

What would cause this?
If it matters, the crons all run planetside. When the items getts added twice, the first happens planetside, the other happens upon taking off.
If cron 2 also disables itself by clearing it's own enabing bit, this shouldn't be happening right?

This post has been edited by Desprez : 09 November 2005 - 04:42 PM

s###, wait, are you sure about that getting executed twice bit? My whole life is dissolving before my eyes.

It just occurs to me that I might not have noticed this behavior only because I only have crons that set, clear, or remove all of item X. I already knew that postholdoff is more of a flag than a field, and if it is >0, it really just uses the preholdoff. This is why there are all those negative numbers in the pilot dumps where it deals with crons: for every cron with -1 preholdoff and a positive postholdoff, it sets the postholdoff to -1 and then counts down until it reaches zero (which it of course never does).

I think it would warrant more testing to make sure you are actually building a workaround to a real bug instead of just bloating a plug based upon superstition.

Ha! I think I just figured out where your problem probably lies. Are you sure only one day is passing? I would bet money that a leftover from another experiment is datepostincing it every day, or that you are flying a ship with a mass greater than (what is it? 200 tons?).

In any case, there exists no cron annotated template. Nobody truly understands their tumultuous behavior, but I would be glad to join you in figuring out exactly what is going on. Crons are the lifeblood of my plug, I hope there is some other explanation for this.

(incidentally, I have set crons to do things like start missions. I am 100 percent sure that the briefing dialogue pops only once. At worst, make the cron start an invisible autoaborting mission that has g128 in its onaccept field. The mission will only be started once. As you noted in your solution thread, nova handles outfits oddly. There is a small chance this is an outgrowth of that. But I am still not convinced this bug exists at all).

While you were writing that, I tried another test.
I though maybe if I dateposted, the EnableOn bits of the crons would have a chance to catch up to the current state of the bits. Or something. So I added s128 to the OnEnd field of cron 1, where that was an autoaborting mission that simply date posts 1.

When I did that, that damn thing added the item 15 times befoe it stopped.

But I'm somewhat confused about what difference it makes if I datepost.
If the cron turns off the flag that enables it, it should only be able to run once, right?

What difference does the mass of my ship make? Is this another bug?

Desprez, on Nov 9 2005, 05:07 PM, said:

While you were writing that, I tried another test.
I though maybe if I dateposted, the EnableOn bits of the crons would have a chance to catch up to the current state of the bits. Or something. So I added s128 to the OnEnd field of cron 1, where that was an autoaborting mission that simply date posts 1.

When I did that, that damn thing added the item 15 times befoe it stopped.

Nono, bad. If you datepost in a mission initiated by crons, then as the new day passes, it checks all of the crons again. In order, starting at the bottom and working up. The weird thing is that it stopped after 15...

Oh no, nevermind. I know why. You ran out of open mission slots. They didnt autoabort properly.

Quote

But I'm somewhat confused about what difference it makes if I datepost.
If the cron turns off the flag that enables it, it should only be able to run once, right?

Yes, you are right. But what if B1 accientally gets reset during that middle day.

Quote

What difference does the mass of my ship make? Is this another bug?
View Post

Hehe, no, not a bug. My guess was that the problem you were seeing hinged on the fact that every time you THOUGHT you were only passing one day, you were really passing two, thus the crons doubled up accordingly. The bit with the ship mass: If you were advancing the day by jumping, if you are in a bigger ship than you realise, it might take two days per jump just naturally.

Are you sure you dont accidentally have a cron hiding in the corner that is also adding 128 every day? I do that sort of thing all the time, check every single plugin file, and every single data file. Twice.

Especially the fact that it worked once before leads me to believe it is something specific and local. The weirdest problem i can possibly imagine is a fencepost error having to do with outfit 128, but that is terribly far out in left field. I have never seen the behavior you describe, but the behavior of crons is certainly odd enough to warrant deeper understanding. (Just like me and my reciprocal links bit. ZP writes for the masses, I write for the nerds).

Well, in all of my tests, there wasn't a single hyperjump.

It looks like, I'm going to have to recreate everything in isolation.

I did try changing the particular bit that enabled the cron, just incase I had used it elewhere, and it didn't make a difference.

I did make a test to show the OnEnd running twice bit. I didn't save it, and I just now tried to recreate it and I can't seem to do it.

SOOO.... it seems that the is some other mysterious behavior that is making this seem to be the case. (also, the novatools cron template mentions the OnEnd running twice behavior)

Anyway, I have some other engagements now, and I'll have to contiunue expirementing another time.

If you buy or sell outfits while on a planet then it will actually advance two days when you leave. If that helps...

Fascinating. I didn't know that, but it would seem to jive with some of these problems.

I think its time we took a moment to tell everyone what version we are using.

I will mostly be testing on Win1.0.9, but I also have mac 106 or something. I might take a moment to upgrade that, but it isnt pressing. I also have to go somewhere soon. All I can say is that recreating stuff in isolation is a good idea. You are using Absolute Minimum, right?

Mac 1.0.8

AbsoluteMinimum, yes.

I would like to point out that in your cron set up, you are basically executing the OnEnd twice, BUT, each time it executes, cron 2 triggers before the second execution of cron 1's OnEnd. To avoid this, I would recommend making use of the ^bXXX command to toggle a bit. If you toggle the bit twice in the OnEnd of cron 1, you will only execute cron 2 once (if you get rid of cron 2's OnStart bit clearing).

NebuchadnezzaR, on Nov 9 2005, 03:47 PM, said:

I already knew that postholdoff is more of a flag than a field, and if it is >0, it really just uses the preholdoff. This is why there are all those negative numbers in the pilot dumps where it deals with crons: for every cron with -1 preholdoff and a positive postholdoff, it sets the postholdoff to -1 and then counts down until it reaches zero (which it of course never does).

Sounds like a classic copy-paste error - specifically, Matt probably remembered to change the offset (or however he's doing it) for the > 0 check, but forgot to change it when it actually reads the value. It's a common programming slip-up.

Of course, I could be wrong.

Kanerix, on Nov 10 2005, 01:42 AM, said:

I would like to point out that in your cron set up, you are basically executing the OnEnd twice, BUT, each time it executes, cron 2 triggers before the second execution of cron 1's OnEnd. To avoid this, I would recommend making use of the ^bXXX command to toggle a bit. If you toggle the bit twice in the OnEnd of cron 1, you will only execute cron 2 once (if you get rid of cron 2's OnStart bit clearing).
View Post

Huh? I dont see how his cron set up should execute the OnEnd twice... Wait... unless Nova keeps looping through the crons until none are left to fire. Is that what it does?

That would mean it would go 2 1 2... but cron 2 would have to be lower ID, and this... no.

Ok, I just did some testing.
It seems that OnEnd does not normally excute twice with Pre-Dur-Post 0-0-0.

However, it is still true that OnStart will only execute every other day under 0-0-0.

So what I think happened is related to what Guy said. If I happend to be in the outfitter when getting the test ready, when I exited to space, TWO days have actually passed.

So, what ever was in OnStart would have only executed once out of those two days, where OnEnd would have executed both days.

Now, if I had thought that only one day had passed, it would look EXACTLY like OnEnd had executed twice.

-----

Ok, now as far as the order that crons execute, this is what my testing shows:
During a given day, Nova checks starting at the lowest numbered cron and evaluates as it goes, updating the value of bits. As opposed to putting the bits into memory at the begining, and evaluating the crons before updating the bits. So order is important.

However, it seems that missions called through Sxxx will interrupt the flow, and be evaluated before continuing to the next cron. Except the OnAbort won't evaluate untill AFTER all the crons have run. So, any bit updates that exist there won't have immediate effect.

So in this example:

Player sets b1
Cron 128 - EnableOn: b1 - OnEnd: !b1
Cron 129 - EnableOn: b1 - OnEnd: g500

Item 500 will not be granted.
Note, however, that if the crons are 0-0-0, and we happend to be using the OnStart instead of the OnEnd field, and b1 gets set every day, item 500 would be granted every other day, as cron 128 would only clear b1 every other time.

-----
Next example:

Player sets b1:
Cron 128 - EnableOn: b1 - OnEnd: s200
Cron 129 - EnableOn: b1 - OnEnd: g500
Mission 200 - OnAccept: !b1

Item 500 is not granted.

-----
Compare to:

Player sets b1:
Cron 128 - EnableOn: b1 - OnEnd: s200
Cron 129 - EnableOn: b1 - OnEnd: g500
Mission 200 - Auto-Aborting - OnAbort: !b1

Item 500 is granted.

-----
Next example:

Player sets b1:
Cron 128 - EnableOn: b1 - OnEnd: !b1 g500 s200
Mission 200 - Auto-Aborting - Date Post 1

This will not create a self repeating loop. Instead, the player ends up with two items of outfit 500.
Strange. I would have expected either an infinite loop, or just one item. But certianly not two.
I haven't completely parsed this behavior.

Does this concur with your own results?

You know, i just realised that -1/-1/-1 is the more normal "do everything at once" setting. Im going to duplicate your results before I test that.

Desprez, on Nov 10 2005, 10:27 PM, said:

Ok, I just did some testing.
It seems that OnEnd does not normally excute twice with Pre-Dur-Post 0-0-0.

However, it is still true that OnStart will only execute every other day under 0-0-0.

So what I think happened is related to what Guy said. If I happend to be in the outfitter when getting the test ready, when I exited to space, TWO days have actually passed.

So, what ever was in OnStart would have only executed once out of those two days, where OnEnd would have executed both days.

Now, if I had thought that only one day had passed, it would look EXACTLY like OnEnd had executed twice.
View Post

Aha, so I was right and NovaTools was wrong

Neb, you mention Postholdoff behaves more like a flag. Do you mean like it's either 0 or infinite? What happens if you have a positive pre and post holdoff?
Oh, are you saying that if post is positive then it will use whatever value is in pre as the post instead? So if pre was 10 and post was 3 then it would use 10 as both pre and post?

This post has been edited by Guy : 10 November 2005 - 03:46 PM

Ok, here is an ugly wrench to throw into the works.
Attached is a file that shows a cron triggering twice when it should only run once.

It's not quite the same as what I was talking about before, but, well... you'll see.

Outfit 128 "Box of Things" - OnPurchase: b1 s129
Mission 129 - Auto-Abort - Date Post 1
Cron 128 - OnActivate: b1 - OnEnd: !b1 s128 g129
Mission 128 - Does nothing but display a message.
Outfit 129 "Can of Stuff" - Does nothing.

Go and buy a box of things, and the process will start.
Now, Cron 128 should only run once, since it clears the bit that can activate it.
And it will appear to work properly. You buy a box of thing, and a message come up, then you are granted a can of stuff.
Now go and try to exit the planet, and the message is displayed again. Then check your player info and you will also have an extra can of stuff.

Edit: Note that either puting a 1 into post holdoff OR moving the expression to OnStart will solve the problem. However, this introduces a new problem in that buying the box of stuff multiple times will only cause the cron to run every other time.

Attached File(s)

• Cron_Test.zip (667bytes)
  Number of downloads: 22

This post has been edited by Desprez : 10 November 2005 - 05:44 PM

NebuchadnezzaR, on Nov 10 2005, 07:00 AM, said:

Huh? I dont see how his cron set up should execute the OnEnd twice...
View Post

Wait, wait, this seems to tie into the example I just posted.
There IS a execute twice bug after all, but it doesn't always seem to appear. Maybe it has something to do with either outfits, or date posting planetside.

Since my original post was a planetside example, I can now see how b2 would have been set again if the OnEnd portion executes once immediatly, and the next when exiting the planet.

It should be noted, that in the post where I made several example tests, all of the tests were in space. And OnEnd was not executing twice.

What a bizarre bug.

Strange. So the OnEnd really is activating twice, though on consecutive days (you can see in the logs that the cron only gets activated once but the OnEnd gets executed twice). If you make the datepostinc 2 or more then you'll see how it runs the OnEnd twice and only twice.

So 0-0-0 means that
a) OnStart only runs every other day
b) OnEnd runs twice, once the first day and once the next

Wait, this means the reason for a) is because the cron hasn't properly terminated yet so it can't activate again. For some reason a cron can't activate and terminate on the same day, it actually needs a second day to terminate and the side effect of this is the OnEnd runs on both days.
Yes, I've figured it out, it all makes sense now! As long as no one makes any more tests which go against this...

This post has been edited by Guy : 10 November 2005 - 07:11 PM

Sounds good to me. It would also explain the behavior of the last example that seemed to be a mystery.

Anyway, I think I know how to get the "check for fighters in orbit and clear bays" thing from the other thread working. Which I THOUGHT was working but then had problems.

It seems like the easiest thing will be to set post holdoff to 1 for every cron in the algorithm, and just make sure that 2 days always pass inbetween running it.

In fact, this doesn't seem to be a 0-0-0 bug after all. It will happen whenever duration and post holdoff are both 0. Strangely enough, it will also happen if pre holdoff is positive and duration is 0, even if post holdoff is also positive.

---

As for the post holdoff bug, here's what I've found:
- When pre holdoff is <=0, post holdoff will work normally.
- When pre holdoff is positive and post holdoff is <=0, post holdoff will be 0 (surprise :rolleyes:)
- But when pre holdoff is positive and post holdoff is positive, post holdoff will be the same as pre holdoff.
(all tests with a duration of 0)

This post has been edited by Guy : 10 November 2005 - 07:53 PM

Okay, here's another spanner for the works. I can make the OnEnd run three times in one duration of the cron.
I set it to 6-1-2 (so post will actually be 6, not 2, due to one of the bugs). The cron begins. Pilot log shows d=1, h=6. I wait 6 days for the holdoff to reach 0. The next day, the duration ticks over to 0, OnEnd runs, and the holdoff goes back up to 6. I wait another 6 days for the holdoff to reach 0 again. On this day (not the next) OnEnd runs again. The next, the duration ticks over to -1, OnEnd runs for the third time, and the holdoff goes back up to 6 again. I wait another 6 days and finally the cron deactivates. 18 days total.