Youen

I finally have a few hours to spend in upgrading the mod for 1.0.2. The bad news is that apparently, FAR code as changed so much that I can just throw away all the interface code that I wrote for it. The good news is that a new function has been introduced : FARAPI.CalculateVesselAeroForces that seems to do exactly everything I need. The rest of the mod has already been adapted by atomicfury, so maybe I can get things to work with FAR again quickly. Stock aerodynamic model is another matter, I haven't tried to look at it yet.

OK, I've merged it in my repo, it compiles, haven't tested it yet but I will soon. Thanks for the fixes Also, I think I had a few modifications that fat-lobyte didn't merge yet, you might want to get them from my repo (it had to do with predictions precision, so of course it won't be useful right now...)

I haven't made much progress on this yet. So far I've installed KSP 1.0, and that's pretty much it. As soon as I find some time, I should be able to quickly make a new version with vaccum (rotating body) functionality. And then investigate what can be done (or not) for stock aerodynamics. Meantime, keep in mind the mod is open source, if anyone has knowledge, motivation and time to take a look, contributions are welcome.

D'oh! I should check the forum more often. I wasn't aware version 1.0 was out , didn't play for some time... I'll take a look. - - - Updated - - - I think what actually happened is that in some cases the mod doesn't see the trajectory will leave the SOI, and so even if it's highly elliptical, it would come back (if the ship wasn't entering the sun SOI) and that second passage would be an aerocapture. At least I'm pretty sure I saw that once. Didn't have time to fix it yet. - - - Updated - - - The problem I've already got with stock is that it's not open source, so I don't know what they do and can't predict it. This is why stock wings are not predicted for example. - - - Updated - - - Oh oh, this might be a problem... From KSP 1.0 release notes : Looks like they do exactly the kind of things FAR does... Excepted if I don't have access to the source code I won't be able to predict any of it. So if it's as complicated as it sounds, Trajectories won't be compatible with stock aerodynamics anymore.

Did you set the entry profile accordingly to what you actually do? By default, the mod assumes you'll enter prograde, but if you enter retrograde (for example with a pod), you'll have to tell so to the mod in the UI window (button "retro"). Then you'll have to actually point the ship as planned during the whole atmospheric trip (relatively to surface, not orbit). Also, the mod does not account for weight loss due to DRE ablative shields, so if it's a big part of your ship mass, results will be inaccurate.

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).

I don't know, it's another player that reported it doesn't work, but if I remember correctly he didn't give more details. Best way to know is to try.

Latest version uses specific 0.90 API, so it won't work on 0.25. You can see compatibility on Kerbal Stuff in the changelog. v1.0.0 is the last for 0.25.

On some bodies, there is a bug that hides the red cross below the ground. You can turn on "body-fixed mode" that will display the whole trajectory relatively to the rotation frame of the body, which means where the trajectory intersects the body really shows where you'll hit the ground. Be sure to disable it when you don't need it, it would give weird results if you are in higher orbits. With this option enabled, you can place maneuver nodes, and adjust for a vertical descent exactly above the point you want to go (I find this is the easiest way to precisely reach a point on a rotating body, but maybe not the most fuel efficient I don't know). You'll notice the node is not exactly placed on the trajectory, because of the rotation offset, but you can still adjust it and see the results.

OK, don't know why, but now it works fine. When I add the fairing the blue marker goes down a lot. I really don't know what changed because I think I'm doing exactly the same thing.

Great mod! I have a question though : does the fairing prevent lift and drag on shilded parts? I tried to enclose a small plane in a fairing on top of a rocket, to prevent aerodynamic forces to make it flip upside down (rarely a good thing for a rocket), because of small wings placed too high, but it doesn't seem to change anything. I use NEAR. Also, the center of lift doesn't change in the editor. Am I missing something?

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?

The whole mod is under MIT license (see the first post at the bottom there is a link), so you can use it freely, you just have to include a copy of the license if you redistribute source code. This applies to the mod code and the API as well. I guess it's just a formulation issue, but I don't see what you want to do (calculate drag *above* the atmosphere?).

Body-fixed mode is great for landing where you want on bodies without atmosphere (you see the trajectory you'll have after each maneuver node relatively to the rotating body, so it's easy to set a vertical descent exactly above your target). It has other uses, such as adjusting a geostationnary orbit, flying above or under contract waypoints (works great with and without atmosphere), etc. But for general orbits, and especially excentric orbits, it just doesn't make sense, so as Exitalterego said, you can just turn it off to display trajectories in the inertial frame of the body (as KSP does for all its orbits). When you see something similar to your screenshot, it's often an under-sampled spiral (if your vessel is far away from the rotating body, it almost doesn't move while the body is rotating, so its trajectory relatively to the body is a spiral, but as only a few points are sampled on that spiral and straight lines are drawn between points, you end up with a big mess). - - - Updated - - - That's weird, I never heard of such a behavior before. What version of FAR did you install (and can you confirm FAR is actually loaded and working as intended in the game?) The KSP log could help troubleshoot the issue (KSP_Data/output_log.txt )

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)

Apparently, there is a bug with the auto-pilot, if you enabled it in the settings (don't know if anyone has found that yet anyway), the game lags when you use your vessel controls (keyboard, etc.), even if the auto-pilot is not actually turned on. If this happens, you can just disable it back in the settings. I don't know yet what the problem is.

Version 1.1.3 released on Kerbal Stuff, see the changelog there. Most important ones : fixes for FAR, various accuracy fixes for all models, added prograde/retrograde preset buttons, possibility to set target using latitude/longitude (and preset for KSC), added experimental auto-pilot.

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.

180 and -180 should give the same output (especially with version 1.1.3-rc1 which solved a small bug about that). Make sure you set ALL sliders to 180 for retrograde entry though (each slider influences a different altitude). Next version will include more easily accessible "prograde" and "retrograde" preset buttons for convenience and to avoid confusions. Of course, make sure you actually follow what you've planned (keep pointed perfectly retrograde if that's what you've planned). Also, some bug fixes in version 1.1.3-rc1 may help prediction accuracy (mostly for FAR, but some fixes may improve NEAR predictions as well).

I've made a pre-release that should fix the accuracy issues when using FAR. It shouldn't change anything for NEAR or the stock model (which were already working fine, right?) It's available for testing here : https://github.com/neuoy/KSPTrajectories/releases/tag/v1.1.3-rc1 Seems stable to me, but I've really not tested in-depth.

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)

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)

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). I used the latest Trajectories release, which works great with stock and NEAR, but, as has been reported, the cache system is really wrong with FAR. I just made some measurements : I get forces about two times too low when the cache is enabled. Without the cache, there's only about 0.1% difference with the actual forces applied by FAR on the vessel at any time. I'm currently investigating, apparently it isn't related to the mach number, which appears to have a very low influence on the final result. - - - Updated - - - OK, found the problem. First, there was a bug with mach number estimation. I wanted to get the mach number at an average altitude, but body.maxAtmosphereAltitude is above-sea altitude, and I thought it was relative to the body center, so I incorrectly subtracted body.Radius. That wasn't really making a difference though (maybe FAR clamps the altitude anyway). The real problem however is that FAR forces are no longer proportional to rho (air density). So we'll have to add a third dimension to the cache system (altitude), and compute rho for each altitude (as a bonus, we can also compute the real mach number). My guess is that a very low resolution on that axis will do though. I'll make some more tests to find a good tradeoff for accuracy/memory/CPU usage on the cache resolution. Bottom line is, we really need a debugger for KSP modding :-( Several hours spent displaying stuff on the screen until I could pinpoint the culprit... Should have been solved in a matter of minutes with a debugger. - - - Updated - - - And there was also a bug in the cache interpolation code (it was inverting the interpolation coefficients for some axes, which had little impact due to the quite high resolution of the cache, but was wrong nonetheless). With this fix, I'll probably be able to reduce the cache resolution and still be more accurate than before. This bug might also explain why setting +180° in the descent profile was different from -180° (because it was sampling the wrong side of the cache cell on both ends). - - - Updated - - - I'm getting lots of errors "FAR Error: Aerodynamic force = NaN Aerodynamic moment = 0 CoD Local = 0 CoD Global = NaN" when reaching the edge of the interface, is that a known issue? (FAR 0.14.6)

Also, make sure you set all sliders to +180 (or all to -180), not just the first one (maybe you already did, just in case)

That was already noted here but I don't know if Kobymaru is using this old github bug tracker.