When & where is the next rocket launch worldwide?

[SergL]

@WCmore or anyone else, what are your thoughts on the modifications below? Few points outlined for consideration;

• This has a large number of chunks then we would like (21) but worth a shot?
• I made the interval every 20x minutes since it appears leading up to launch, weather windows are every 30x minutes. Figured at this interval might be able to catch a scrub sooner?
• I have separated the text versus spoken notification into different times using additional offset variables. Figured that with the text I could get ready and grab the necessary snacks and beverages and then stand at the moment the voice comes on.
• In between the notifications I have added a -4 offset to re-ping the launch date, as a last resort catch to a scrub. At this point in time I would have already gotten the written notification but at least the voice will not come on. Not overly concerned about the piston having the new data right away so figured at least the launchdate variable would suffice to stop the last portion of the piston based on a scrub.

There might be some errors I made or things I missed to consider so if anyone cares to review that would be awesome

[guxdude]

I made the interval every 20x minutes since it appears leading up to launch, weather windows are every 30x minutes. Figured at this interval might be able to catch a scrub sooner?

I had thought about this. Seems better to make the every a variable. Start at 3-4 hours and then shorten the interval as it gets closer to launch. Will always be one cycle delay in changing interval but easily compensated for.

To reduce the number of chunks thought maybe the messaging could be put in a separate piston if you store nextLaunch and the message you want to send into global variables. Just brainstorming here.

In the end, @wcmore always comes up with something better than we think of.

[SergL]

To reduce the number of chunks thought maybe the messaging could be put in a separate piston if you store nextLaunch and the message you want to send into global variables. Just brainstorming here

I thought about this as well but haven’t played around with it yet. It would allow additional granular control if you for example wanted to limit messaging/notification based on more parameters.

[WCmore]

Not one to normally brag, but I did declare take off was cancelled at 4.14pm, as visible from the timestamp of my previous message, 2 minutes before NASA did.

My 4:16 estimate was because it was (officially) scrubbed at about T-17 minutes on a :33 launch.

Although like you, we saw clues leading up to that.

[WCmore]

what are your thoughts on the modifications below?

• This has a large number of chunks then we would like (21) but worth a shot?

Unfortunately, I will be unable to test this due to it’s size

---

I made the interval every 20x min

With the block in place to prevent spamming the API, this is OK.
(although personally, I still want a normal alert if there is a scrub)

---

I have separated the text versus spoken notification into different times

I like this, and was planning to add at least one bonus alert.

---

In between the notifications I have added a -4 offset

If you are referring to lines 140-145, I don’t think that bit will work. It is not grabbing new data on those last three timed triggers. (meaning it can only update based on line 61)

[WCmore]

To reduce the number of chunks thought maybe the messaging could be put in a separate piston

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.

[SergL]

With the block in place to prevent spamming the API, this is OK.
(although personally, I still want a normal alert if there is a scrub

Agreed on not wanting to spam that API! Dont need it taken away!

If you are referring to lines 140-145, I don’t think that bit will work. It is not grabbing new data on those last three timed triggers . (meaning it can only update based on line 61)

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?

If you guys vote for a two-piston combo for this, I will gladly step up to the plate.

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.

Maybe a call to the API half an hour after the expected lift off also, because the info didn’t get updated for me for 9 hours. I had the same stale info only updating by “in -6 hours” “in -7 hours” until “in -9 hours” when new info was posted.

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.

[SergL]

Unfortunately, I will be unable to test this due to it’s size

Out of curiosity, what happens on your side if you try to test/run a piston of this size?

[WCmore]

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?

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)

---

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

If I split it, both tiles and alerts will be in the second piston.
(the base piston will only be the “data gathering” piston)

[WCmore]

Out of curiosity, what happens on your side if you try to test/run a piston of this size?

We can import any size piston, but cannot save a piston that is too large.
(so it can never run)

[SergL]

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)

understood now. Thanks!

If I split it, both tiles and alerts will be in the second piston.
(the base piston will only be the “data gathering” piston)

Still ok with that.

We can import any size piston, but cannot save a piston that is too large.
(so it can never run)

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.

[WCmore]

And I’m getting 2 separate times in the piston state, the new one in the brackets is

• Florida in X hrs +
• (Sat @ X:22 PM)

Then the one in launch info is an hour before.
May 30, 2020 at IX:22 PM

The top one in brackets should be local time to me, and the launch info should be local time to the rocket, there’s more than an hours difference for me.

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

[WCmore]

Is anyone doing a version without tiles? If not I’ll try to strip it down myself.

Do you like the dual-piston idea, @Alwas?

If so, my base piston will have no tiles at all.

[guxdude]

If you guys vote for a two-piston combo for this

That’s my vote. I assume both will still need to be in the same WC instance?

[WCmore]

I assume both will still need to be in the same WC instance?

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.

[WCmore]

the top time you added, local, is pertinent to me, but I’m not sure who the UTC time will help or do, I’d prefer the actual local time in Florida displayed there

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.

[WCmore]

Hopefully someone who’s good at math could add the local time of the launch, it’s important information I think. The only live launch I ever saw was at high school in Florida in eighty six, I’ll never forget what time of day it was then unfortunately.

Florida in 86… Ouch… Thankfully, you did not let it jade your view on astronomy…

[SergL]

If I split it, both tiles and alerts will be in the second piston.
(the base piston will only be the “data gathering” piston)

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

[SergL]

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.

[WCmore]

Imagine at 1AM having my speakers telling me…

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.

---

Hopefully someone who’s good at math could add the local time of the launch

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.