[old thread] Trajectories : atmospheric predictions

[Superfluous J]

On 3/6/2016 at 8:25 AM, Kobymaru said:

Hi! What happens very often to me is that the marker is underground. That's either when showing the current impact point or when setting the Target.

 

7 hours ago, Youen said:

If I remember correctly, I did attempt to set the cross on the ground, not on sea level ; but it doesn't work correctly indeed. Maybe I'll end up adding a fixed offset...

An option that already works is to use Body Fixed mode. It won't put the marker there, but you can be (more) confident that the line going down to the surface will intersect where you're actually going to land.

[Kobymaru]

5 hours ago, 5thHorseman said:

 

An option that already works is to use Body Fixed mode. It won't put the marker there, but you can be (more) confident that the line going down to the surface will intersect where you're actually going to land.

Thanks, I use that for landing at known sites. Sometimes I need to land at specific coordinates though, and I don't know where they are. It *would* work on a spherical body: enter target coordinates and get creen cross, align red cross and land there. But now the green cross is invisible, and there's no readout for current impact coordinates.

I installed MechJeb to work around this limitation, there I can enter target coordinates and get a marker, then I lign up the Trajectories marker with it and it's fine.

It's still a shame that I need MechJeb for this

13 hours ago, Youen said:

If I remember correctly, I did attempt to set the cross on the ground, not on sea level ; but it doesn't work correctly indeed. Maybe I'll end up adding a fixed offset...

I think it doesn't work correctly, because you set the altitude at the *impact point* and the lines of the cross are on the same altitude. If there are mountains in the regions, they simply cover the lines. Or maybe not. But it definitely needs some work.

13 hours ago, Youen said:

About the coordinates readout, a first step would be to fill the box with the target coordinates when using the "set current impact as target" button, which would also show the syntax that can be used.

OK, that's already pretty good!

[Enceos]

20 minutes ago, Kobymaru said:

I installed MechJeb to work around this limitation, there I can enter target coordinates and get a marker, then I lign up the Trajectories marker with it and it's fine.

It's still a shame that I need MechJeb for this

You can use the SCANSat marker for this purpose or the custom Waypoint Marker from the Waypoint Manager.

[TaggedYa]

In Plugin/Trajectory.cs on line 683 there is a call to:

FARAeroUtil.GetCurrentDensity(body, altitudeAboveSea)

In "Ferram-Aerospace-Research-0.15.5.5_Hugoniot" this method was changed to:

public static double GetCurrentDensity(Vessel v)

In Plugin/VesselAerodynamicModel.cs on line 153 is:

FARAeroUtil_GetCurrentDensity = loadedAssembly.assembly.GetType(namespaceName + ".FARAeroUtil").GetMethodEx("GetCurrentDensity", new Type[] { typeof(CelestialBody), typeof(double), typeof(bool) });

I am not familiar with C# but this looks like a typecast to an even older version.

Then on line 245 we have:

rho = useNEAR ? stockRho : (double)FARAeroUtil_GetCurrentDensity.Invoke(null, new object[] { body_, currentAltitude, false });

Then again in 343, and 541.

I would fix this and test the result but I have neither a C# compiler (I could get one I guess) nor Unity which is a bigger problem.

If someone would be kind enough to make the appropriate changes and post the recompile I will test it and see if I can find the more subtle problems.

 

Tag

[Andem]

All right, I'm lost here, FAR updated and broke compatibility with this? When will compatibility issues be sorted out? Should I use FAR with this after the bugs ate fixed?

[Youen]

22 hours ago, TaggedYa said:

I would fix this and test the result but I have neither a C# compiler (I could get one I guess) nor Unity which is a bigger problem.

If someone would be kind enough to make the appropriate changes and post the recompile I will test it and see if I can find the more subtle problems.

If you'd like, or anyone else, start modding KSP, it's quite easy actually.

You could download visual studio here. The "community" edition is free, and enough for KSP modding or almost anything actually. An alternative is mono-develop, which is also free (and multi-platform). You could also compile with mono command line. For Trajectories, the easiest is visual studio, since the project is already configured.

Then you open the Trajectories.sln file (double click), this will open the project in visual studio. Then you press ctrl + B and it will recompile the mod. If you select "Release" on top of the window before building, it will also remove debugging code, and package a zip file (that's the one I distribute after testing).

You don't need Unity for that. You will need however to update references to KSP DLLs : in visual studio, expand "References" in the project tree, you'll probably see a few dlls with an exclamation mark. This means visual studio can't find them, because the path does not point to your KSP installation (it points to mine...). Delete them, then right click on References, select "Add reference...", then click on "Browse..." and pick the files in your KSP/KSP_Data/Managed directory. You need Assembly-CSharp, Assembly-CSharp-firstpass and UnityEngine.

17 hours ago, Andem said:

All right, I'm lost here, FAR updated and broke compatibility with this? When will compatibility issues be sorted out? Should I use FAR with this after the bugs ate fixed?

Yes, players have reported the latest FAR version is not compatible with Trajectories. You can use the latest tested version (Hoerner), or the stock aerodynamics, or uninstall Trajectories, or wait for a fix.

[Baleine]

On 18/3/2016 at 11:14 AM, TaggedYa said:

In Plugin/Trajectory.cs on line 683 there is a call to:

FARAeroUtil.GetCurrentDensity(body, altitudeAboveSea)

In "Ferram-Aerospace-Research-0.15.5.5_Hugoniot" this method was changed to:

public static double GetCurrentDensity(Vessel v)

In Plugin/VesselAerodynamicModel.cs on line 153 is:

FARAeroUtil_GetCurrentDensity = loadedAssembly.assembly.GetType(namespaceName + ".FARAeroUtil").GetMethodEx("GetCurrentDensity", new Type[] { typeof(CelestialBody), typeof(double), typeof(bool) });

I am not familiar with C# but this looks like a typecast to an even older version.

Then on line 245 we have:

rho = useNEAR ? stockRho : (double)FARAeroUtil_GetCurrentDensity.Invoke(null, new object[] { body_, currentAltitude, false });

Then again in 343, and 541.

I would fix this and test the result but I have neither a C# compiler (I could get one I guess) nor Unity which is a bigger problem.

If someone would be kind enough to make the appropriate changes and post the recompile I will test it and see if I can find the more subtle problems.

 

Tag

I did made these changes, although there is no more exception, the trajectories displayed in atmosphere are still wrong and matches the stock trajectories (understand that trajectories does not takes into account the atmosphere.

I think I know why. The previous GetCurrentDensity() was requiring the vessel's altitude (the second parameter), but now it takes the vessel's altitude from the Vessel object.

 

That said, maybe we could fix that by changing the altitude directly on the vessel object (if it is possible, I'm not quite used to the KSP API). I will check if it is possible.

[Baleine]

OK. Quick update to inform you, and maybe you guys would be able to help me thinking how it should be done.

I did try to change the vessel's altitude and feed that vessel to FARAeroUtil_GetCurrentDensity method, but as I was expecting, it does not work.

Then I copied over the old FAR method and called that copy instead. Now I have a prediction, but it's not precise at all (and I mean not precise like kicking in a ball and shooting the referee in the nuts instead).

 

I digged a bit the original FAR method which is only used to show airspeed in the interface. That may explain why the results I have are so far from the real trajectory, I'm not sure.

At this point, I don't have any idea about what I should do to have a better result, maybe you guys have an idea ?

[Youen]

I've published a new release on github and spacedock. It should be compatible with the latest version of FAR (tested with v0.15.5.7 "Johnson").

Thanks to Baleine who did most of the work on this one.

[Supraluminal]

Hey @Youen, thanks for all your work on this, it's still one of my favorite mods.

However, the latest version isn't working for me.  The window isn't opening properly in map view.  It just comes up as a weird thin rectangle.  It kind of looks like the window is zero width and negative height with just the border visible:

I have the mod installed via CKAN.  It did this after initial upgrade, then again after I removed it and reinstalled it.

Hope there's an easy fix for this one!  I'm looking forward to getting it up and running again after the latest FAR upgrade downtime.

[Baleine]

It happened to me while I was debugging. Did you tried to delete the file "config.xml" in Plugindata\trajectories ?

[Tallinu]

When updating from 1.4.5, AVC "changelog" button currently displays a big scrollable window full of raw HTML that doesn't seem to contain any actual changelog, but it's hard to tell (I think it expects plain text and is getting something else -- I've seen it do this for at least one other mod too).

[Youen]

15 hours ago, Tallinu said:

When updating from 1.4.5, AVC "changelog" button currently displays a big scrollable window full of raw HTML that doesn't seem to contain any actual changelog, but it's hard to tell (I think it expects plain text and is getting something else -- I've seen it do this for at least one other mod too).

OK, I thought the URL was just sent to a browser, I don't use AVC myself so I never tested that. It should contain the changelog though, it's the github release page, but of course without an HTML parser it's not easy to read (you'd have to scroll down to line 500 or so). I'll see what I can do, but I don't want to have to copy/paste the changelog again (already have to on github + space dock) each time I publish a new release...

[Supraluminal]

On 3/28/2016 at 6:31 PM, Baleine said:

It happened to me while I was debugging. Did you tried to delete the file "config.xml" in Plugindata\trajectories ?

Thanks, this worked.  If it's possible, it might be nice to include something in the next release to handle this automatically for those who use CKAN.

[KvaNTy]

On 19.03.2016 at 7:24 PM, Baleine said:

OK. Quick update to inform you, and maybe you guys would be able to help me thinking how it should be done.

I did try to change the vessel's altitude and feed that vessel to FARAeroUtil_GetCurrentDensity method, but as I was expecting, it does not work.

Then I copied over the old FAR method and called that copy instead. Now I have a prediction, but it's not precise at all (and I mean not precise like kicking in a ball and shooting the referee in the nuts instead).

Tried precisely the same in the beginning of month, but got lost digging current FAR's mechanic.

On 28.03.2016 at 3:57 PM, Youen said:

I've published a new release on github and spacedock. It should be compatible with the latest version of FAR (tested with v0.15.5.7 "Johnson").

Thanks to Baleine who did most of the work on this one.

Finally, thank you!
Let's all hope that FAR wont mess with public API any more.

[Youen]

8 hours ago, Supraluminal said:

Thanks, this worked.  If it's possible, it might be nice to include something in the next release to handle this automatically for those who use CKAN.

Indeed, that's a bug I'll try to solve. The weird thing is that I updated from 1.4.5 to 1.4.6 on another install of the game, with CKAN, and didn't get the bug... So something happened on your install but I don't know why. Did you keep the problematic xml file by any chance ?

[BadOaks]

On 3/30/2016 at 0:07 AM, Youen said:

Indeed, that's a bug I'll try to solve. The weird thing is that I updated from 1.4.5 to 1.4.6 on another install of the game, with CKAN, and didn't get the bug... So something happened on your install but I don't know why. Did you keep the problematic xml file by any chance ?

I had the same issue and was also able to fix it by removing the config.xml file (many thanks!). Here's the file contents:

<?xml version="1.0" encoding="utf-8"?>
<config>
    <bool name="DisplayTargetGUI">1</bool>
    <bool name="DisplayDescentProfileGUI">0</bool>
    <bool name="DisplaySettingsGUI">1</bool>
    <bool name="UseBlizzyToolbar">1</bool>
    <bool name="DisplayTrajectories">0</bool>
    <bool name="DisplayCompleteTrajectory">0</bool>
    <bool name="BodyFixedMode">0</bool>
    <bool name="AutoUpdateAerodynamicModel">1</bool>
    <rect name="MapGUIWindowPos">
        <xmin>28</xmin>
        <xmax>29</xmax>
        <ymin>338</ymin>
        <ymax>-7311</ymax>
    </rect>
    <bool name="GUIEnabled">0</bool>
    <int name="MaxPatchCount">4</int>
    <int name="MaxFramesPerPatch">15</int>
    <bool name="AutoPilotAvailable">0</bool>
    <bool name="UseCache">1</bool>
</config>

 

[Youen]

3 hours ago, BadOaks said:

I had the same issue and was also able to fix it by removing the config.xml file (many thanks!). Here's the file contents:

<?xml version="1.0" encoding="utf-8"?>
<config>
    <bool name="DisplayTargetGUI">1</bool>
    <bool name="DisplayDescentProfileGUI">0</bool>
    <bool name="DisplaySettingsGUI">1</bool>
    <bool name="UseBlizzyToolbar">1</bool>
    <bool name="DisplayTrajectories">0</bool>
    <bool name="DisplayCompleteTrajectory">0</bool>
    <bool name="BodyFixedMode">0</bool>
    <bool name="AutoUpdateAerodynamicModel">1</bool>
    <rect name="MapGUIWindowPos">
        <xmin>28</xmin>
        <xmax>29</xmax>
        <ymin>338</ymin>
        <ymax>-7311</ymax>
    </rect>
    <bool name="GUIEnabled">0</bool>
    <int name="MaxPatchCount">4</int>
    <int name="MaxFramesPerPatch">15</int>
    <bool name="AutoPilotAvailable">0</bool>
    <bool name="UseCache">1</bool>
</config>

 

Interesting. Obviously the issue is that big negative ymax. I'll take a look but so far I don't know how this could happen. Thanks for the report.

[Exaxis]

I'm having a problem with this mod, and maybe somebody can tell me what I'm doing wrong:

I built a standard Space Shuttle, and when I try to de-orbit it, the trajectory shown by this mod is way off - by like a hemisphere.

My shuttle is a carbon-copy of the one featured in this video, and I'm flying it the same way. I have a probe core in the rear rotated about 15 degrees, so when I hold prograde while coming in, the nose is up slightly.

In that video, the mod shows him his entire glide profile. When I do it, it only shows me as having a simple ballistic drop. I have a set of images here that demonstrate the difference. As I come into the atmosphere the mod keeps pushing back the projected landing point. This keeps me from being able to reliably hit where I want.

I'm on stock aero, just like he is, with no other mods that I imagine would interfere. I have tried fiddling with the setting provided by the mod - setting my angle of attack, specifying a prograde entry, etc., but none of them rectify my issue. 

I figure I'm doing something dumb - anyone have a clue what that might be? Thanks in advance!

[Kobymaru]

4 hours ago, Exaxis said:

I'm having a problem with this mod, and maybe somebody can tell me what I'm doing wrong:

I built a standard Space Shuttle, and when I try to de-orbit it, the trajectory shown by this mod is way off - by like a hemisphere.

My shuttle is a carbon-copy of the one featured in this video, and I'm flying it the same way. I have a probe core in the rear rotated about 15 degrees, so when I hold prograde while coming in, the nose is up slightly.

In that video, the mod shows him his entire glide profile. When I do it, it only shows me as having a simple ballistic drop. I have a set of images here that demonstrate the difference. As I come into the atmosphere the mod keeps pushing back the projected landing point. This keeps me from being able to reliably hit where I want.

I'm on stock aero, just like he is, with no other mods that I imagine would interfere. I have tried fiddling with the setting provided by the mod - setting my angle of attack, specifying a prograde entry, etc., but none of them rectify my issue. 

I figure I'm doing something dumb - anyone have a clue what that might be? Thanks in advance!

If you "hold prograde and the nose is up slightly", then you are effectively gliding. That's completely different from a ballistic drop., which is assumed by default.

You have to set the AoA Sliders on the various altitudes (Mouseover to know what high, Medium, low means) to your desired AoA. 

 

Btw: gliding, "gentle" reentry is by far not the best. It's in fact pretty heavy on the heat. A better way is to reenter at 90 °, as long as you can hold your nose up (using SAS, RCS and everything). It sounds brutal but is a lot softer than the seemingly gentle reentry.

[Exaxis]

3 hours ago, Kobymaru said:

If you "hold prograde and the nose is up slightly", then you are effectively gliding. That's completely different from a ballistic drop., which is assumed by default.

You have to set the AoA Sliders on the various altitudes (Mouseover to know what high, Medium, low means) to your desired AoA. 

 

Btw: gliding, "gentle" reentry is by far not the best. It's in fact pretty heavy on the heat. A better way is to reenter at 90 °, as long as you can hold your nose up (using SAS, RCS and everything). It sounds brutal but is a lot softer than the seemingly gentle reentry.

Hey, thanks for the reply.

As I mentioned, I set the angle of attack settings, but the corrections it makes are still nowhere near accurate. And, if you look at the video I posted, that guy doesn't do it either: he specifically mentions that he just leaves the settings alone, and controls from his rotated probe core. The mod seems to understand what effect that will have, and models his glide profile accurately.

When doing the same thing, I'm getting an entirely different result, and that's what's confusing me. Even adjusting all the settings I can find only gives me an inaccurate ballistic drop, instead of the glide profile he's seeing.

And thanks for the tip! I'll give that a shot next time I get the shuttle into orbit again.

[Minalmist]

Just to add another data point on the config.xml issue. I had the same problem this morning. I don't believe it's directly related to install. I deleted the old config (it too had a negative ymax value). I uninstalled trajectories and reloaded and it. Than I looked at several craft and on the third or fourth one it switched into "Line mode". This config file did not have a negative Y value though. I deleted the config file and went back into KSP and to the best of my abilities tried to do the same things but can't reproduce the problem. This is the 2nd bad config file. There are two differences between this file and the first bad config. I'll continue to see if I can reproduce the problem again.

1. xmin/max values & ymin/max values (values from first file listed after ...)

2. the last two lines <bool name="AutoPilotAvailable">0</bool>
    <bool name="UseCache">1</bool> are transposed.

 

<?xml version="1.0" encoding="utf-8"?>
<config>
    <bool name="DisplayTargetGUI">1</bool>
    <bool name="DisplayDescentProfileGUI">1</bool>
    <bool name="DisplaySettingsGUI">1</bool>
    <bool name="UseBlizzyToolbar">1</bool>
    <bool name="DisplayTrajectories">0</bool>
    <bool name="DisplayCompleteTrajectory">1</bool>
    <bool name="BodyFixedMode">0</bool>
    <bool name="AutoUpdateAerodynamicModel">1</bool>
    <rect name="MapGUIWindowPos">
        <xmin>1402</xmin>    ....<xmin>1384</xmin>
        <xmax>1654</xmax>  ,,,<xmax>1385</xmax>
        <ymin>143</ymin>      ...<ymin>193</ymin>
        <ymax>77</ymax>     ....<ymax>-129</ymax>
    </rect>
    <bool name="GUIEnabled">0</bool>
    <int name="MaxPatchCount">4</int>
    <int name="MaxFramesPerPatch">15</int>
    <bool name="UseCache">1</bool>
    <bool name="AutoPilotAvailable">0</bool>
</config>

[Youen]

8 hours ago, Exaxis said:

Hey, thanks for the reply.

As I mentioned, I set the angle of attack settings, but the corrections it makes are still nowhere near accurate. And, if you look at the video I posted, that guy doesn't do it either: he specifically mentions that he just leaves the settings alone, and controls from his rotated probe core. The mod seems to understand what effect that will have, and models his glide profile accurately.

When doing the same thing, I'm getting an entirely different result, and that's what's confusing me. Even adjusting all the settings I can find only gives me an inaccurate ballistic drop, instead of the glide profile he's seeing.

And thanks for the tip! I'll give that a shot next time I get the shuttle into orbit again.

If you reenter after setting "control from here" on the probe core, and you keep the navball centered on your prograde vector (the yellow mark), it should be fine. Be sure to click the "prograde" button in the Trajectories window as well, or you may be actually predicting a retrograde entry. And also make sure the probe core is oriented along prograde, not retrograde (i.e. that it was not back facing when you placed it on the shuttle). If it still doesn't work, you can try the "update now" button, and disabling the cache, and see if it changes the predicted trajectory (it's not supposed to, this is just to check the problem does not come from there). Also, you might be having a problem with control surfaces : even if you keep oriented on the prograde vector, if the control surfaces are not centered (because the shuttle is not completely equilibrated), you'll have more drag than predicted.

It seems a bit weird however to have "a whole hemisphere" of difference, what is the length of your entry? In stock KSP I usually enter with only a quarter of the globe or sometimes a little more. The longest your entry, the less precise the prediction, but anyway with a space splane you should be able to adjust as you go. Make sure also the "prediction stopped too many iterations" message doesn't appear (that would mean your atmospheric trip is too long and the prediction system gave up at some point, for performance reasons)

2 hours ago, Minalmist said:

Just to add another data point on the config.xml issue. I had the same problem this morning. I don't believe it's directly related to install. I deleted the old config (it too had a negative ymax value). I uninstalled trajectories and reloaded and it. Than I looked at several craft and on the third or fourth one it switched into "Line mode". This config file did not have a negative Y value though. I deleted the config file and went back into KSP and to the best of my abilities tried to do the same things but can't reproduce the problem. This is the 2nd bad config file. There are two differences between this file and the first bad config. I'll continue to see if I can reproduce the problem again.

1. xmin/max values & ymin/max values (values from first file listed after ...)

2. the last two lines <bool name="AutoPilotAvailable">0</bool>
    <bool name="UseCache">1</bool> are transposed.

Thanks for these details. Without a procedure to reproduce the issue (I've never seen it myself yet), I might just end up adding paliative code to fix the issue automatically after it happens. I don't think you did, but just in case, did you change the game resolution at some point?

[David104]

Any chance for an update to 1.1 soon?

no pressure...ok, maybe a little..:D

[Vanamonde]

@David104, mod makers get so bombarded by request and demand for updates that we've had to make a forum rule about it (2.3.f). Please keep that in mind.