I agree. On giant monstrosities such as this, I often use one piston to do all the heavy lifting, and then send the final variables to another piston that can do all the fancy footwork.
NOTE:
If you guys vote for a two-piston combo for this, I will gladly step up to the plate.
Agreed on not wanting to spam that API! Dont need it taken away!
The way I saw that working in my head was that the line 134 notification had already been sent. At line 140-145 it re-pings the nextlaunch variable which if it changed would then only affect line 146-153 since its time is based off that return. Would that not be the case?
I am 100% ok with this. We could have the current one still work and display as a tile and such and a second piston could do the notifications. To me I would then have a bit more freedom to for example only do voice notifications for FL launches or something similar that would add more chunks.
I believe WCmore addressed this with the (in mine) line 67, “hrs to launch less than 0.01”. Combined with the every 20x min trigger it would have updated at that interval after the launch.
In your lines 140-145, it does the same math as before, using the same old data.
(IE: the block at line 140-145 does absolutely nothing to update anything)
If I split it, both tiles and alerts will be in the second piston.
(the base piston will only be the “data gathering” piston)
We can import any size piston, but cannot save a piston that is too large.
(so it can never run)
understood now. Thanks!
Still ok with that.
Gotcha, mine saved so I guess it would run! But good to know what to look out for if I ever get to that point.
This is normal…
If it helps, the Saturday launch is at 3:22pm EST (7:22 UTC) which should be X:22 for you
In other words, the LAUNCH data (7:22 UTC) is exactly as the API states (without edits)…
The (Sat @ X:22 PM) at the top is the local time converted for us mere humans…
Note, There is no code in my piston to tell me the Florida time, unless I live in Florida, LOL
Do you like the dual-piston idea, @Alwas?
If so, my base piston will have no tiles at all.
Yes, with this much changing data…
Hopefully I get a dual-piston combo out before the next launch, but I want to run it thru the proper testing this time around without rushing.
The data in {nfo} is 100% exactly what is listed on the API under “launch_description”.
(I did not edit this, or parse it at all)
I mainly just grabbed that data because it has a nice one sentence summary of the event.
If (for some reason) you want to know what time it is in Florida, you can do extra math to determine it.
I have another piston running that looks at any non-FL launches, it just updated with a New Zealand launch June 11 at 1243AM locally to me. So a future dual piston setup with the ability to additionally add conditions for notifications, ie location mode = is not Night, would be awesome! Imagine at 1AM having my speakers telling me what New Zealand is hurtling into the sky 
100%, I have been adding my own things in like separating the text and spoken notifications and stuff like that. Often though it adds more chunks hence why we talked about splitting it into 2x pistons. Was just pointing out yet another advantage for having separate pistons.
Good point. When I post publicly, I tend to avoid using restrictions, since everyone’s house will be different, and they are easy to add after import.
(that is, if the OP would stop updating the piston 
)
In my house, I tell webCoRE to only issue speak commands if I am awake. (I don’t mind so much if I am home or not, but that’s an option as well) Either of those conditions (among others) can be inserted in the Speak block to keep her alerts to a minimum.
Well it already lists the local time for you… but if you mean the local time as seen by the launch crew…
I have scoured the API, but unfortunately, there is no mention of local time, nor what timezone the launch pad is in (so we could do our own conversion). We need to know at what offset to calculate with.
The “easiest” workaround would be to store a list of launch pads with the right time offset for each, and then pull from that list and calculate the pad’s local time…
*whew*
So while it’s definitely possible to determine what time is on the astronaut’s wrist watch, I do not think the time and space requirements justify that project.
So my apologies… With the current API, I will not be adding this to my updates.
Oh, don’t get me wrong, it would be a fun little challenge…
It just would cripple this piston, or require an additional piston for all the extra “stuff”.
On a totally unrelated note…
I have only been monitoring this API for less than 10 days so far…
(so there are still events that we’ve never seen yet)
… but I just noticed one event that I was not happy with at first. Let me share it in story format:
I would imagine that a list of (worldwide) rocket launches would have launches added or removed fairly frequently. I would also imagine that the closer and closer it got to the launch window, that time would become more stable. (only changing due to weather or unsafe conditions)
What surprised me just now was to see that tomorrow’s launch (in 22 hours) just got bumped to the second slot [1], and now China’s CX-6-01 mission just jumped to the first slot [0].
Of course, with my daily web request in place, I would not have even noticed without looking at the actual API.
So again, my first thought was I was not happy with China’s move like this… but then I realized that there is no video feed, or practically any information on their website…
So maybe it is good that we don’t see little (insignificant) blips like that!!
I mean, they are going out of their way to keep their data internal as much as possible.
Note:
1h 28m after China’s launch, that outdated data is still sitting at [0]
5h 58m after China’s launch, that outdated data is gone…
Not sure when in between it updated…
There will be 5 empty seats on this launch…
(do you think they will notice a stowaway?)
T-17 hours, and counting…
