Supposedly, it only runs what is within the ‘every’ but if it has to pass over it? Sounds like we need another experiment…
EDIT: Here is some more thinking out loud… What if the piston executed itself at the end of the every loop. It shouldn’t re-execute the every but should update the if date and time, right?
Both of you are much further ahead in skill level on this than I am, but my thinking out loud is what if we add a do nothing block after the every and before all the written/verbal notifications that triggers off the same {nextLaunch}. Would that then subsequently fix the math for the following notifications below?
That is the current predicament… Often, when a piston calls itself, there are double triggers.
This is essentially what I inserted yesterday.
(although I am tempted to change it to -720, or 12 hours)
Of course, we won’t know if it is successful unless China pulls a fast one again, LOL
Note to self:
My next version might use straight IFs instead of EVERY to remove the compartmentalization.
Or Vega postpones again at the last minute…
I went with (nextLaunch-$now)<=(1-minOffsetBeforeAlert) as my test [since minOffset is negative]. Just have to wait for another ‘opportunity’ 
I went in the opposite direction… By totally removing my math from that trigger.
This line updates hourly:
… and my trigger is now:
Perhaps overkill, but my logs should reveal more as time passes.
Note: {nle} stands for {nextLaunchEarly}
(I’m running out of space, LOL)
To be more clear, I actually left the trigger as it was. I now have this:
So I let the trigger run but then verify we are actually within time of the latest next launch before sending alerts.
Ahh yes… I see… Basically a stricter version of my IF {hrsTolaunch} is less than 1
Keep in mind though that if a rocket ever launches early, you will miss the alert unless that first line of math is recalculated ahead of time.
nextLaunch always contains the most recent downloaded data. If something launches and it is not in nextLaunch, I would miss it anyway.
EDIT: Oh, sorry. I understand what you are saying now. Yes, that is true.
So I ran across a couple new problems. This only showed up for me because I am displaying all launches within the next week. Turns out China has a new launch coming up but the date is only estimated. So, at first I was seeing this:
So it looked like the third launch had already happened. Took me a while to diagnose but it turned out the logic to identify an estimate was not working. I’m not sure why. I tried comparing to a null string and to the word “null” but neither seems to flag that there was no date in win_open. Finally I used length(win_open)>10 to identify a valid date and otherwise use the estimate. then I had to add logic to know that an estimate was being use because the time was still relatively close (<168 hours). Now I have this:
The other problem I am having is the piston stopped logging anything a day or two ago. Even when I set to full, nothing is being sent to the log. Will have to figure this one out.
OK, I see how you are… Let’s troubleshoot your piston on my page, so your page stays all nice and tidy… LOL
All jokes aside, I will read and respond to this in 12-15 hours.
I’m a bit tied up at the moment.
Quick answer:
All of my renditions (so far) is with the assumption that a real launch time will be displayed by the time the launch is in the last 7 days. (when the square tile switches to a round gauge)
I did no error correction for China’s last minute “update”…
My logic is simple. I’d bet my last dollar that their government has a time scheduled for the launch, but they are adamant about not revealing that until the last second.
(With the MATH involved selecting a launch window, I can promise you it is not a last minute decision)
Why should my piston be crippled due to their intentional secrecy?
(it’s not like they will air footage, or reveal scientific breakthru’s anyhow…)
I am seriously considering modifying my v2 to simply ignoring all launches from China.
(I mean, what’s the point?)
I did cheat a bit when I created this. I dumped in data that was really null… IE:
Set variable {null} = $response.result[x].est_date.quarter
which will usually be stored as
Then I removed that “Set variable” line of code, and simply referred back to the null variable with ‘nothing’ stored in it. (comparing to null can be tricky, but this technique works well for me)
Another way to say this:
In webCoRE’s eyes, neither a blank variable, nor typing “null”, is the same as a true null.
I often use this trick when I program, but this may be my first time sharing it publicly…
I was hoping it transferred when importing… but I should know better… Unset variables remain unset…
I guess the final version should force in an endpoint that is always null, to initialize that variable.
(although I hate leaving in code that only needs to run once per lifetime… and of course, how can I be sure that a certain endpoint will always be null?)
Hmmm…
Untested, but I wonder if creating a totally bogus endpoint would create an effective null.
IE:
$response.result[x].bananaSplits
will likely never exist in the real API…
Edit:
Nope, the test failed. It has to be a real endpoint with no data for null to be stored properly.
Edit 2:
Dang it… Now I am craving a Banana Split!
Very slick. In this case, I solved it using length since we know all the valid strings will be 17 characters. I did find it interesting that the ‘null’ values had a length of 4. I had actually tried a string “null” but that didn’t work either. Anyway, I am happy with the solution I have and it should be robust. I actually deleted the {null} variable since it didn’t seem to be working.
LOL. I got my piston working so wasn’t looking for help. Just pointing out a potential issue I saw where it never got to the estimated date.
One other FYI: the 5th item on the current list also had an estimated date but only the year was filled in (2020). Month and day were zero. Fortunately, none of this matters unless you change the value of {x} in your piston.
EDIT: I managed to fix my logging problem also. I had to delete and reload the piston and then it started working again. Also, I figured out a way to get rid of the every so I can press test to check it is working properly:
For some reason, I did not expect this. This tells me there is definitely something going on beneath the surface here.
It is definitely do-able… but in your last pic, I am curious how 23 + 1 will equal 0…
(I think you will get an error at the end of 11:03pm, when it tries to set the next schedule)
Actually, that was my first test since I created this in the 11 PM hour here and it did immediately schedule for 12:03 AM. Unfortunately, I was doing some editing right at midnight so when I saved again it jumped forward to 1:03 
. I will let it run for 24 hours and be sure but it seems to work.
EDIT: I just did a quick test. There must be some correction built in. I tried assigning 24:05, 25:05, and 26:05 to a time variable and the result was 12:05 AM, 1:05 AM, and 2:05 AM.
Perfect… because then, it will be 1+1 and 2+1…
… and kudos to @ady624 (or whomever) implemented that “roll-over” safety net!
Edit:
The geek in me wants to know if it works in reverse as well…
(IE: Does negative 1 return 11pm, and -2 return 10pm?)
For your inner geek 
I ran the same quick test with these results:
00:05 --> 12:05 AM
-1:05 --> 11:05 PM
-02:05 --> 10:05 PM
Confirmed! Roll-over correction works in both directions!
Pure brilliance! Thanks for testing…
I really hope that Adrian is given freedom to implement all of his creative ideas in to the new version of webCoRE.
Looks like Vega slipped out again. I think Space-X is more reliable. Hopefully we will get a launch on Tuesday. 
*whispers in a low voice*
Somehow, China’s precise launch time was revealed to the world at least 21 hours early…
