[WEB] KSP Transfer Illustrator

[theAstrogoth]

18 minutes ago, HebaruSan said:

I realize this is probably a big ask, but it would be amazing if those images you're sharing were interactive (drag to rotate the view) on the forum as they are on the real app, similar to how tweets can be embedded. Presumably that would require creating a plugin for the forum and getting the moderators/admins to enable it, so I won't hold my breath, but maybe they'd be up for it if they saw the potential.

That's a really cool idea, and I think it might be feasible! Plotly already can export the graphs as HTML files, so as a first step, I can try to add a button that downloads a plot. Then it could be shared as a file that could be opened in your browser.

As far as embedding in the forum, I know next to nothing about this kind of thing, but it shouldn't be too hard to display HTML code in a post, right?

[HebaruSan]

41 minutes ago, theAstrogoth said:

As far as embedding in the forum, I know next to nothing about this kind of thing, but it shouldn't be too hard to display HTML code in a post, right?

I tried to find something relevant in the forum documentation, and I think it might involve writing PHP code:

• https://invisioncommunity.com/developers/docs/development/plugins/complete-example-of-a-plugin-in-ips-community-suite-r50/

... but I was not able to find anything directly and simply answering the question of how to embed new kinds of rich content.

[theAstrogoth]

23 hours ago, HebaruSan said:

I tried to find something relevant in the forum documentation, and I think it might involve writing PHP code:

• https://invisioncommunity.com/developers/docs/development/plugins/complete-example-of-a-plugin-in-ips-community-suite-r50/

... but I was not able to find anything directly and simply answering the question of how to embed new kinds of rich content.

Thanks for looking into this! At this point it's all Greek to me, but I might spend some time trying to figure this out a bit more.

I was able to add buttons for downloading HTML versions of the plots, but without the toggles and sliders, so you'll have to pick the display options and slider time beforehand. Otherwise, all of the rotation/zoom/pan functionality is there, as well as the hovertext info.

 

Edit: Here's an example of one of the downloaded files.

Edit2: Figured out how to do direct download links from Google Drive.

Edited August 29, 2020 by theAstrogoth

[theAstrogoth]

A little bit of trying to figure out embedding plots in the forum...

Plotly documentation gives an example/generates code for embedding plots in HTML using an iframe. Their example looks like this:

<iframe id="igraph" scrolling="no" style="border:none;" seamless="seamless" src="https://plotly.com/~chris/1638.embed" height="525" width="100%"></iframe>

I think all that needs to be done is change the src URL to one that contains the HTML for the relevant plot, and maybe some other cosmetic changes.

 

In the Invision Community Forums, it seems like they talk about using iframes for admins to embed content (not in posts, but elsewhere). Unrestricted use of iframes in posts is a security issue, but it looks like specific URLs can be allowed. So if this is allowed, a plugin might not be totally necessary.

 

So for this to happen, maybe we would need some kind of secure place to store plots saved by users (where someone couldn't upload any dangerous content), and the we could allow posts with iframes with URLs where the plots are stored. I'm not really sure what next steps should be, but I think we would need Mod/Admin approval before moving forward. Is there anyone in particular I should reach out to?

Edited August 29, 2020 by theAstrogoth

[HebaruSan]

2 hours ago, theAstrogoth said:

I think we would need Mod/Admin approval before moving forward. Is there anyone in particular I should reach out to?

I think @Vanamonde would be a good contact with which to start. If he can't handle it himself, he'd know who can.

[Vanamonde]

I know who to ask, anyway.

[theAstrogoth]

On 8/29/2020 at 2:48 PM, Vanamonde said:

I know who to ask, anyway.

Thanks! Let me know what they have to say, or if there is anything I can do to help make this happen.

[theAstrogoth]

I spent some time cleaning up my messy code doing a little bit of in-game testing. A couple of things:

• Fixed "radial" burn component calculation (had the sign flipped) 
• Added display of UT in seconds for burn maneuver times
• Small cosmetic changes to plots

One issue I'm struggling with is that when I try to use the burn components and time to set a maneuver node in-game, it is consistently a few (1-5) seconds too late. An example with pictures:

I used HyperEdit to set one craft in a non-circular parking orbit around Kerbin and another craft on an ejection trajectory to Duna (with parameters from the app). The craft on the ejection trajectory has an insertion trajectory at Duna pretty close to the readout in the app. The two crafts will collide at a relative speed equal to the magnitude of the ejection burn.

Collision!

 

This is all great! The collision indicates that the app successfully matched the ejection trajectory with the mean anomaly/epoch of the starting orbit. The issue is that when I try to set the maneuver node using the departure time from the app, it looks like this:

The maneuver node is too late, so a burn there would result in an inaccurate transfer.

So I'm hunting for what's causing the problem. Until it's fixed, the app can still be used for getting encounters with the target body, but it won't be very good at hitting particular insertion trajectories without manually tweaking the departure burn time. 

 

EDIT: I warped ahead to year 20 to try for some similar tests, had much larger time offset between the intersection and the maneuver node. Interestingly the error was roughly proportional to the universal time; in all cases (years 1, 2, and 20), the maneuver node's UT was about 0.0002% higher than it should have been. Not entirely sure what this suggests about where there error is coming from. It seems like I'll have to be more careful about precision. 

Edited September 3, 2020 by theAstrogoth

[theAstrogoth]

I haven't had much free time to work on this lately, but I did manage to track down the biggest source of error: I was using an incorrect value for Kerbin's gravity parameter . 

Now I tend to get a maneuver node within a couple 1/100ths of a second of the proper time. Even this small error can result in VERY BIG errors in the insertion orbit, but it should only take a couple of small adjustments to the maneuver node's time to get it right. I'll try to work on getting this error even lower so that slight movements of the maneuver node aren't necessary.

[theAstrogoth]

On a hunch, I changed the precision of the value of π I use to calculate orbital period and mean anomaly by trimming off the last decimal place. Things seem to work better! Either KSP uses a lower-precision value of π than the Python math library, or my change is compensating for error coming from a different part of my code.

Whatever the case, maneuver node times given by the app match very well with where they should occur in-game. Shown below is insertion into a polar orbit over Moho, achieved by placing maneuver nodes with burn components and times from the app. The target altitude was 100,000, but I'm happy with this level of accuracy.

 

 

In my attempts to troubleshoot this problem, I wrote code to propagate an orbit across SOI changes. I never implemented it in the app, but if there is interest, I might add a way to generate plots of propagated orbits based on an initial orbit. I could even add a way to include maneuver nodes, and then you could export interactive 3D plots of a mission plan. This could be especially cool if we can figure out how to embed plots in the forum or set up some other way to share them. 

[theAstrogoth]

I've put together a slapdash (even more so than usual) prototype for an orbit propagator app. It's separate from the transfer-calculating app for now, and might stay that way to prevent things from getting too cluttered. 

https://ksp-trajectory-illustrator.herokuapp.com/

You can enter a custom starting orbit, and then a series of maneuver nodes (each with prograde, normal, and radial burn components, as well as a universal time). The app will propagate the orbit across SoI changes, apply maneuvers at the specified times, and display the orbits in each SoI. There's a sample maneuver node already set up when the app is loaded.

I haven't really done any accuracy testing for it yet, and I still need to add in things like the download buttons and sliders that are in the other app, but it should be functional at least. It's rather "dumb," since it won't tell you anything you couldn't figure out by placing maneuver nodes in-game, but my hope is that it could eventually be used for generating plots for use in tutorials or for sharing cool mission plans. It would be interesting to see how it works with a crazy multi-gravity-assist type mission.

Feel free to offer any suggestions!

[Gordon Dry]

Suggestion:

Implement Resize (planet radius) and Rescale (system orbit sizes) values as to be used in SigmaDimensions.
In most cases configs for SigmaDimensions use the same value for both parameters, only in a few edge cases they do not.

[theAstrogoth]

3 hours ago, Gordon Dry said:

Suggestion:

Implement Resize (planet radius) and Rescale (system orbit sizes) values as to be used in SigmaDimensions.
In most cases configs for SigmaDimensions use the same value for both parameters, only in a few edge cases they do not.

Sure! I added resizing and rescaling of the entire system, but haven't yet implemented any way to resize/scale individual bodies. I *think* the changes are consistent with what would be done by SigmaDimensions, but may need to take a closer look at how SoIs are recalculated.

[Gordon Dry]

@theAstrogoth nice.

I just checked it, actually the scaling only allows integers. One decimal place (and so 0.1 steps on the up/down arrows) would be needed.

[theAstrogoth]

Just now, Gordon Dry said:

@theAstrogoth nice.

I just checked it, actually the scaling only allows integers. One decimal place (and so 0.1 steps on the up/down arrows) would be needed.

I think decimals should work, you just have type the number in rather than using the little arrows in the input box.

[Gordon Dry]

1 minute ago, theAstrogoth said:

you just have type the number

That's what I did after the first click on an arrow.

Edit:

oh, you use comma - I'm german so I'm used to it but I assumed it needs a dot.

Something else - the day length (for Kerbin) needs to be recalculated when resizing of the planets occur.

Edited September 28, 2020 by Gordon Dry

[theAstrogoth]

2 minutes ago, Gordon Dry said:

oh, you use comma 

Strange! It's a dot for me. Very odd

[Gordon Dry]

1 minute ago, theAstrogoth said:

Strange! It's a dot for me. Very odd

Perhaps it's defined by browser language setting, so it's a nice feature - which confuses when assuming the "english" way is used.

Edited September 28, 2020 by Gordon Dry

[theAstrogoth]

15 minutes ago, Gordon Dry said:

Something else - the day length (for Kerbin) needs to be recalculated when resizing of the planets occur.

It looks like SigmaDimensions uses a separate day length multiplier. Does this usually have the same value as the resizing multiplier? 

Edited September 28, 2020 by theAstrogoth

[Gordon Dry]

2 minutes ago, theAstrogoth said:

It looks like SigmaDimensions uses a separate day length multiplier

Yes, you're right. It's not "fully" calculated, there is a value to be set in the rescale patch.
For the 2.5x it's set to 1.666666666666667 on Kerbin.
Well, this means that value also needs to be entered manually.

[theAstrogoth]

22 minutes ago, Gordon Dry said:

Well, this means that value also needs to be entered manually.

I've added the extra input, and with the 2.5x resize/scale and the day length multiplier of 1.666666666666667, we get 10 hour days and 404 day years on Kerbin. Does that seem right?

[Gordon Dry]

24 minutes ago, theAstrogoth said:

we get 10 hour days and 404 day years on Kerbin. Does that seem right?

yes

[theAstrogoth]

I've fleshed out the "trajectory illustrator" app a bit more. You can plot the trajectories of multiple "vessels," each with their own set of maneuver nodes and custom colors. I've set the default inputs in the app to show two transfers: example ballistic and plane-change transfers from Kerbin to Duna with their target orbit around Duna shown in green. I also added buttons for downloading plots, as well as toggles for burn arrows. Sliders for time are next!

At this stage, I'm more motivated to work on the persistence file reading. It would be neat to be able to upload a save file to see plots of all of your vessels with maneuver nodes. It looks like someone has already made a savefile parser in Python, so I just need to figure out where to access orbits, maneuver nodes, etc. 

 

Here are screenshots of plots made from the default inputs. A ballistic transfer is shown in red, plane-change in blue, and target orbit in green. Burn arrow scaling is a bit funky at the moment.

Edited October 12, 2020 by theAstrogoth

[Gilph]

Hi, just found this tool. You've done a really excellent job. Thanks for making it.

[theAstrogoth]

1 hour ago, Gilph said:

Hi, just found this tool. You've done a really excellent job. Thanks for making it.

Thanks, I'm glad you like it!

Please let me know if you encounter any problems, if there is anything you dislike, or if you have a suggestion for a new feature so that I can make improvements .