When & where is the next rocket launch worldwide?

WCmore · 2020-06-29 16:26:46 UTC

Very cool to hear about the additional roll-over options…

Wouldn’t this be going in the wrong direction? I mean, if we assume for a moment that the launch does not change, there is a 100% chance that your converted time will always be after the real launch… Meaning you are guaranteed to miss the launch.

For reference, when I did something similar to the events with no day, I always shifted it forward (closer to us), so if anything, it fired a few hours early. (better than late, IMO)

But how could we do anything useful if we are given only a month or year??
(to be honest, I do not want to see data that vague on my Dashboard)

guxdude · 2020-06-29 16:32:14 UTC

This is why I decided to push it out. Until we get better information (at least all three values), I don’t want to pay much attention to it. Before putting in this correction, the June 2020 went to June 0->May 31 so it was showing that this launch in the future had already happened.

WCmore · 2020-06-29 16:35:47 UTC

Ahh ok… Pushing it back to keep the clutter down sounds wise.
(although I think we only need two dataPoints (month & day) to draw a decent gauge)

I am toying with the idea of adding the option to have unknown launches hidden from the gauges entirely. (and I may even let users add keywords to filter out locations that they are not interested in)

fieldsjm · 2020-06-29 16:49:05 UTC

I had considered setting an arbitrary date (initial thought was the end of the month to avoid the appearance that the launch had occurred on a gauge/tile)…
But as both you and @guxdude point out, there are pros and cons with setting early vs late.

My current thought is to add boolean in addition to the arbitrary setting whenever the data is incomplete. The arbitrary setting would prevent errors downstream in the coding and the boolean would determine how the data is visually presented.

Any incomplete data would only be included on a tile with a text string rather than a countdown. For example: TBD - Est June 2020

WCmore · 2020-06-29 17:04:02 UTC

I started working on parsing the estimates yesterday, but I am not quite finished yet. The tricky part is, it could be written in one of (at least) four ways:

Jul 2020 (estimated)
Jul 08 (estimated)
(L-1 days, 03:16:48)
Tue Jun 30, 2020 19:56:00 UTC

My goal is to parse it down to simple terms, and have a one line hover text at the bottom of my single gauge.

IE

New Zealand - Electron - Jul 03 (est)
China - Kuaizhou 11 - Jul 08 (est)
China - Long March 3B - Jul 10 (est)
Ixtlan - Lucid Dreams - Aug 2020 (est)

Note:

The API address currently only works for any number 5 or less.

fieldsjm · 2020-06-29 17:12:29 UTC

Have you thought about just using: $response.result[x].date_str

The Vega example above would return→ Jun 2020 . No additional formatting needed.

Edit: That is my plan for the tile string mentioned above.

WCmore · 2020-06-29 17:15:24 UTC

I do like that idea, but we have to be careful because even launches with full data will also have “date_str” in use.

I think the reason I was playing with “quickText” is because I really like the L- countdown there, and was trying to do something with that on known launch times.

fieldsjm · 2020-06-29 17:17:31 UTC

That is true, for example, the Florida launch scheduled tomorrow would return Jun 30

Excellent point

Using my boolean method, I would only be inserting the string whenever the data is estimated so anything with winOpen would be unaffected though the value would still exist.

WCmore · 2020-06-29 17:22:31 UTC

I know I promised everyone a double piston version of this piston, but with all of our discoveries, (estimates and last minute changes), I am really leaning towards only having a single gauge on my Dashboard.

I hope I am not letting anyone down with this decision… I still plan on improving this piston, but I think it would be ideal to have only one gauge, with basic info on hover for the next couple of launches…

guxdude · 2020-06-29 18:10:52 UTC

This is true. I actually don’t ever expect year to be 0 if there is an estimated date.

Most of the time the extra gauges do not add a lot but I do like the multiple gauges showing what is coming up in the next week. Putting it in the hover text most of the time is probably just as useful since so many future launches are estimated.

I don’t think you could let anyone down. You have pushed so many things in great directions. Really appreciate all you do for the community.

WCmore · 2020-06-29 18:22:45 UTC

LOL, yes… I meant that the time is ok to be estimated for a little while, as long as we know the day and month.

Thank you for this. I am a bit of a rebel, by nature, and like pushing the current boundaries into new realms… (IE: show me the “impossible”, and I’ll show you something that I have not tackled yet, LOL)

WCmore · 2020-06-29 22:22:44 UTC

I just updated my local piston… (taking @fieldsjm’s suggestion to the next level)
… but before I update this thread, how do you guys like the last 4 lines?

Note:
There’s no conversion on these later launches, so an early launch on the 10th, might actually be evening on the 9th (for your location). The proper time conversion kicks in once the data shifts to the first slot[0].

Note 2:
I dropped the (est) at the end of the string, because those extra characters forced a new line, and the results looked sloppy. I will just assume that all dates down there are estimates, and will only pay attention to the real times once the launch shifts to the top slot[0].

fieldsjm · 2020-06-30 03:13:28 UTC

I like this much better than what I was just playing with. I was experimenting with adding additional nfo lines. The issue is there are so many characters that the visual limit is really the next two launches. Yours is much more streamlined. Succinct yet complete.

My Current Tiles

WCmore · 2020-06-30 03:28:46 UTC

Thanks for the feedback… I have updated the original post with the latest improvements.

I guess a quick reminder for those updating:
I would change “6 past the hour” to another number, and consider adding a restriction to the voice alert…

guxdude · 2020-06-30 19:30:35 UTC

T-25 minutes to next launch!

EDIT: No voice over yet but countdown jumped back up to 30 minutes a little while ago…

guxdude · 2020-06-30 20:05:21 UTC

Almost complete with fuel load…

EDIT: Winds confirmed good for launch T-3

guxdude · 2020-06-30 20:23:13 UTC

So incredible what these people do! The first stage steered itself autonomously to a landing in the middle of the Atlantic and hit the target.

SergL · 2020-06-30 20:36:21 UTC

So the delay screwed up my notifications and made me look at this again. Made some changes that I think might help. Can someone let me know any glaring issues?

For me the issue was that we had been past the initial notification window and that the delay had been changed after my last api pull/time calculation as well as before the next one. The trigger for “every hour at X minutes past” wouldn’t trigger again after the launch for me due to my X minutes past the hour setting.

This made me think back about when we first started this piston and an idea I had applied to an earlier version of the piston running every 20x minutes. The concept was that it appears every delay is at least 30x minutes into the future. So first of all I changed my interval to every 20x minutes. Secondly I didn’t want to spam the API though so I lowered the {hrsTolaunch} condition from 4 to 1.5. This should give me the time for the piston/time calcs to update in the event of another delay.

Initially I had moved the “Always” block with the time calcs in with the first IF and API pull, but after making the change up top to the interval I placed it back where it was initially.

Lastly the other change I made is that my offset is less than the 20x minutes refresh so that it wouldn’t notify before a next change.

**Also, very awesome launch!! Was glad to be able to have caught that one!! **

WCmore · 2020-06-30 20:41:21 UTC

With my piston above, this would only catch events happening within the next 30 minutes, or less… (90-60)

If you are hammering this every 20 minutes, it will catch events happening within the next 70 minutes, or less… (90-20)

(personally, I think moving to every 20 min is a bad move… Mine limits each day to 2-6 API pulls… Yours will pull triple that, and you will still miss last minute changes)

Remember, even NASA does not predict the weather, and the API owners need time to update the API. With both of these in mind, you can bet your last dollar that last minute changes will NOT be accurate here in webCoRE… (unfortunately, it’s the nature of the beast)

SergL · 2020-06-30 20:55:23 UTC

You lost me there. Forgive me. With the piston set to “every hour at XX minutes past” it would not pull at the API and do the time calculation until that very trigger time as I understand it. So as the case was today the initial launch time of 3:55 EDT was updated to 4:25 EDT. My piston was set to run at 22 after the hour. So it was after the 3PM hour which still had the correct info but wouldnt have made it to the 4PM cycle since the rocket was already gone by then.

The way that I envisioned my changes to work is at the every 20x minute mark it runs the piston but only pulls at the API once a day and when {hrsTolaunch} is now a smaller window. Hence not hammering it as much if it was set to 4 and the 20x minute interval also.

If {hrsTolaunch} calculates to hours and compares to a value of 1.5 would it not only pull at the API once it crosses within that 1.5 hour window? So using an interval 20x minutes over 1.5 hours giving us 4x times at the most?

I could be way off hence why I defer to your expertise!

~~Edit. I figured out the “or less” part of your comment. I noticed that the {hrsTolaunch} is now a negative number. So for now I changed that condition to be {hrsTolaunch “is inside of range 1.5 and 0”.

And I am ok with that, at this point its more out of curiosity to learn for me!