[1.3] Trajectories - Prediction of atmospheric trajectories

[Youen]

I never test it in near, I have far..

But I had understand that the only difference that nears has with far is all the UI that show your flying data.. but if in nears works fine, then I am mistake.

It's a bit more complicated than that. NEAR doesn't break parts due to aerodynamic failures, doesn't change aerodynamic behavior depending on mach number, and apparently is proportional to air density while FAR isn't. So NEAR really uses a simpler model (which still looks convincing to me, huge improvement over stock).

I'll try to make a pre-release of the FAR fix today (seems to work already, but I haven't made a lot of tests)

[Youen]

I found the bug that was causing NaN with FAR when exiting/entering the atmosphere : it's the new rho calculation depending on altitude that was sending rho=0 to FAR. Easy to fix as in this case there is no air, so no aerodynamic force. I think it's now ready for the pre-release, I'll post the DLL here for anyone that want to test, and send a pull-request to Kobymaru for the actual release.

EDIT:

here is the pre-release : https://github.com/neuoy/KSPTrajectories/releases/tag/v1.1.3-rc1

@Kobymaru I sent you a pull request, let me know if you want to publish the release or if I do it (it's fine by me either way, really a matter of who is more available at the time)

Edited January 24, 2015 by Youen

[sralica]

As per the first page of this thread: It is a known issue that FAR/NEAR landing predictions are inaccurate due to the methods used by Trajectories to calculate with the new drag model. Methods to improve accuracy without drastically reducing performance are being developed.

...

Keep at it Kobymaru!

It would be perfectly acceptable so the calculation would not be live. I don't need recalculation 10 times per second. There could be a button "Recalculate" Which would compute trajectory for current path and planed maneuver node. it can take up as much as 30s, I have all the time in the world.

And it should use this sound:

Have a nice day

edit:

I almost always enter atmosphere in reverse/retrograde. Can you set the default AoA in the descent profile to -180° for all sliders. Or make a button for retrograde, a button for prograde, and use the sliders for something in between.

Edited January 24, 2015 by sralica
new idea

[hoylemd]

I have a boring UI bug.

I have blizzy's toolbar installed, and I checked off the Trajectories box, but it doesn't appear. I want to turn on (or off?) body-fixed mode so that my landing predictions are accurate.

In case I misunderstand the issue, here's a detailed decription of the problem symptoms:

When I go to plan re-entry, I make a maneuver node so that the impact X is where I want ti (usually the KSC). I usually plan this about a quarter to a half orbit before the actual burn so I have lots of time to tweak it. After I actually execute the burn my blue orbit matches up with the trajectory, until it hits the atmosphere, as expected. Once I'm actyually in the atmosphere though, both my blue orbit and the red line go down, and I end up landing way short of the target. I figure this is either because Trajectories is not accounding for the rotation of the planet, or because i'm using NEAR, and that's somehow messing up the calculations.

[Youen]

I have a boring UI bug.

I have blizzy's toolbar installed, and I checked off the Trajectories box, but it doesn't appear. I want to turn on (or off?) body-fixed mode so that my landing predictions are accurate.

In case I misunderstand the issue, here's a detailed decription of the problem symptoms:

When I go to plan re-entry, I make a maneuver node so that the impact X is where I want ti (usually the KSC). I usually plan this about a quarter to a half orbit before the actual burn so I have lots of time to tweak it. After I actually execute the burn my blue orbit matches up with the trajectory, until it hits the atmosphere, as expected. Once I'm actyually in the atmosphere though, both my blue orbit and the red line go down, and I end up landing way short of the target. I figure this is either because Trajectories is not accounding for the rotation of the planet, or because i'm using NEAR, and that's somehow messing up the calculations.

The mod should work with NEAR and take planet rotation in account. The red X always shows the landing location on the planet (it rotates with the planet). Landing short of the target is a common symptom of planning a prograde entry but performing a retrograde, can you check you have set the four sliders to 180° in the descent profile (assuming you are entering retrograde)? Also, version 1.1.3-rc1 may help with prediction accuracy.

[hoylemd]

I'm, not sure what you mean by 'four sliders' - There's no UI for trajectories that I can see, just the lines in map mode?

[Youen]

You should have a button in the toolbar in map view, that opens the UI window (unless there is a bug, let me know if that's the case)

[Kobymaru]

I thought I would not fall again, but apparently I couldn't resist trying KSP 0.90 and have been playing again for some days (and nights).

...

Hi! Sorry I have been hiding, I had an important exam. Now I should be more active.

Thanks for your great work! I tested it and prediction is spot on. Costs quite a bit CPU, though (~40% on my box).

I saw that you already uploaded it to KerbalStuff. Is there any other place where you want to release it as well?

Edited February 1, 2015 by Kobymaru

[Youen]

Hi,

No problem, we all have our lives :-) I hope your exam worked out fine.

You could release on your github page (since it's linked on the release thread) and update the release thread title, and I think that's it :-)

Also, I've deleted on my github repo the automated test projects, as well as the API (I think no one uses it at this time, so I wanted to trim down the code to ease maintainance, but might have been a bad timing since someone just posted about it in the release thread). I didn't include that in the pull request but if it's fine by you we could merge to have the same code base and avoid future merge headaches?

[Kobymaru]

You could release on your github page (since it's linked on the release thread) and update the release thread title, and I think that's it :-)

Done!

Also, I've deleted on my github repo the automated test projects, as well as the API (I think no one uses it at this time, so I wanted to trim down the code to ease maintainance, but might have been a bad timing since someone just posted about it in the release thread).

Maybe we should wait until either the question is clear or we haven't heard from the guy in like, 1-2 weeks?

I didn't include that in the pull request but if it's fine by you we could merge to have the same code base and avoid future merge headaches?

Yes, that would be very nice. I tried to merge your branch, but there was a conflict. I think it is because Trajectory.cs was basically rewritten in this commit: 7043119. Is there a reason why the file seems completely new? Is that a Line Ending issue or something?

[Youen]

Sorry, didn't see your post. I don't know why the whole file appears modified, maybe line endings as you said, or indentation or something. I didn't change much actual code (if I remember correctly, I just merged some test code I hadn't commited before).

[Enceos]

Many people have problems with FAR predictions accuracy. I suggest making an input box in the advanced menu of Trajectories called "Drag Factor" with a number by changing which we can tweak the drag predictions.

For example "1" will be default drag model.

Those who are coming short of the target location will input a number higher than 1 to correct the inaccuracy.

Those who are coming far ahead of the target location will input a number less than 1.

For example I will increase the drag factor to 1.15 for most of my pods. Some crafts will need a drag factor of 1.20, some of 0.95. Trajectories mod can't model the drag in FAR very accurately, and people will have an option to find the right drag factor for each of their craft to get an exact atmospheric trajectory prediction.

[erendrake]

I am actually quite interested in Trajectory's API, I have a question about it. The API only lets you query for the active craft. How hard would it be to extend the API to let someone specify one of the loaded craft?

[DundraL]

Hi, just showing up with an item for the wishlist: a checkbox to calculate with airbrakes deployed.

Considering they make a major impact of trajectory, I think being able to include them would be a pretty big change for the better.

Anyway, thanks for the awesome mod, cant live without it!

[Kobymaru]

And finally, we can do things like these:

I hope this really helps with numeric debugging.

[PiezPiedPy]

Just a heads up on a New Gui I'm cobbling together.

If anyone wants to follow progress of the code you can view it on GitHub here NewGui-Test

I'll be posting screenshots of how the GUI progresses and any input from you guys can only help with a GUI that covers most users needs.

I'm also adding Localization so any help with translations when the time arises will be greatly appreciated.

[PiezPiedPy]

Quick screenshot of the the new Gui so far

Edited July 27, 2017 by PiezPiedPy

[Kobymaru]

Wow, that looks amazing!

I'm really looking forward to it

Just as a side note though: you shouldn't recreate the old UI one to one, instead we should try to find a more "natural" user experience. That's why I asked to put early versions in this thread: I'm sure you could recreate the old UI without problems, but I wanted to use the opportunity to clean it up and make it clearer.

For example: the craft position in lat/lon is not really necessary at this place, is it? It doesn't necessarily help with landing, and if I *did* need it, I would take the readout from MechJeb2 and Kerbal Engineer.

[PiezPiedPy]

@Kobymaru Thanks!

Its early days, so we can change things on the fly.

Regarding the craft position I have no idea why it was displayed in the old gui. I'll give it the boot. Or maybe we should add the Impact lat and lng values in its place.

I'm also toying with the idea of a tiny popout info window that shows only the Impact G-Force and Impact Velocity values.

 

 

[APlayer]

So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. 

And, while we are at things like that, if I may make a feature request...

So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.

[Kobymaru]

2 hours ago, PiezPiedPy said:

I'm also toying with the idea of a tiny popout info window that shows only the Impact G-Force and Impact Velocity values.

What is the "impact g-force" and how do we calculate it? Depending on the how the craft "crumbles", impact g-force can be infinite

I'm not sure if putting numeric readouts into popup windows is a good idea, because that will make them hard to find for novices and annoying to read out for those who need them.

On the other hand, I understand the desire to "put them away" since I don't recall ever having used them in day-to-day life.

2 hours ago, PiezPiedPy said:

Regarding the craft position I have no idea why it was displayed in the old gui. I'll give it the boot. Or maybe we should add the Impact lat and lng values in its place.

I had a thought: what if we add some sort of "Info" section (or popout window?) that looks similar to a Kerbal Engineer Redux window with all kinds of numerical readouts? This doesn't have to be configurable (for now), we'll just stuff it full with all that we have now.

That reminds me... we should really polish up the API so that maybe we can even plug Trajectories into Kerbal Engineer.

1 hour ago, APlayer said:

So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. 

Well if it takes less than five minutes, you could do it real quick and show us the result, and we go from there

 

1 hour ago, APlayer said:

And, while we are at things like that, if I may make a feature request...

So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.

I am very much in favor of that and have been missing this feature forever. I don't know yet when to find time to implement that, though...

By the way, as it so happens, I am currently working on a section about feature requests in the contributors documentation. It's not completed yet, but you should check it out!

[APlayer]

1 hour ago, Kobymaru said:

[...] you could do it real quick and show us the result [...]

Here we go: 

[Kobymaru]

On 9.7.2017 at 9:12 PM, APlayer said:

Here we go: 

Ok, thanks, I think I get the picture now.

The problem that I see is two-fold: First of all, simply a different color is not a great indicator of what is going on. Seems very unrelated to the Body-Fixed setting. Sure, it could be mentioned in the README - but no one reads that anyway. Button naming / icons should work without a README and be obvious without ever having touched a manual.

Secondly, I just don't think that the state of "body-fixed" is important enough to change the icon color. Currently it's in the main window anyway, and the checkbox itself is plenty visible. Why would we need to make this so prominent?

If anything, a color change would be warrented when the trajectory is calculated vs when it's not.

Edited July 11, 2017 by Kobymaru

[PiezPiedPy]

On ‎09‎/‎07‎/‎2017 at 7:04 PM, Kobymaru said:

I had a thought: what if we add some sort of "Info" section (or popout window?) that looks similar to a Kerbal Engineer Redux window with all kinds of numerical readouts? This doesn't have to be configurable (for now), we'll just stuff it full with all that we have now.

Sounds good too me.

 

4 hours ago, Kobymaru said:

If anything, a color change would be warrented when the trajectory is calculated vs when it's not.

I have to agree with this but rather the colour should be green. (Edit: I have just implemented this in the new Gui)

We could also use the yellow icon when the trajectory is calculated and auto fixed body is on but it only shows when fixed body mode is active. Also since fixed body when in auto mode is only active when in the atmosphere it will be like an indicator showing when the craft is currently in the atmosphere which I like a lot

 

On ‎09‎/‎07‎/‎2017 at 8:12 PM, APlayer said:

Here we go: 

Can you change the blizzy icon too please, also can the background be semi-transparent on the new icons and if you can, would you be willing to create icons for the buttons in the Gui ?

Edited July 11, 2017 by PiezPiedPy

[PiezPiedPy]

On ‎09‎/‎07‎/‎2017 at 7:04 PM, Kobymaru said:

What is the "impact g-force" and how do we calculate it? Depending on the how the craft "crumbles", impact g-force can be infinite

private static string Get_ImpactGforce()
{
    return string.Format("Impact G-force:  {0,6:0.00}", Settings.fetch.DisplayTrajectories ? Trajectory.fetch.MaxAccel / 9.81 : 0);
}

The code above is what I've used in the new Gui and was based on the old Gui math.