Youen

Version 0.2.2 is out. Some issues are fixed, and it allows setting an attack angle of 180° for backward reentries. It also occurred to me that you should keep correctly oriented, even if you don't have wings, FAR forces are not necessarily symmetrical, so keep the wings symbol of the nav ball aligned with the horizon just to be sure... For backward flight, it should be upside down (the orientation you'll have if you start prograde and make a half-looping)

OK, so it does look like either prediction was wrong, or it was accurate only for a very precise entry profile (see my previous post about chaos theory). Maybe it's just a plain huge bug, if you can send me material to reproduce that, such as your .craft file (preferably using stock pieces or at least not too many mods) I'll take a look.

Yeah, didn't see that coming, and also didn't thought the mod would have so much success when I created this thread. Well, I'm glad if it helps :-) And thanks everybody for the support and kind words. I don't think chutes are a priority indeed, because most of the time you can deploy them at the last moment, so they don't dramatically change your landing site. Also, don't imagine prediction is more accurate than it is, it's kind of subject to the butterfly effect (chaos theory), so depending on your craft, your piloting, and starting conditions, prediction can be quite far from where you'll actually land. Especially with wings, but that's observable even with a pod. Probably farther than the difference you'll get by deploying your chutes at 100m of the ground.

Wow, lot of posts since my last visit. I am indeed working on this backward reentry thing, and also on various other sources of inaccuracies (if someone tried a Jool aerobraking at 10km/s, he knows what kind of inaccuracies, if he didn't die in the resulting unplanned atmospheric capture). Actually, it's kind of working now (code pushed on github), but not much tested. I'll try to release that soon. And I confirm the red "cross" (with three branches) on the screenshots above does not come from this mod.

Yes, I intend to put it on KerbalStuff, but I wanted to wait for it to be stable enough. Actually, I didn't think about the notification system that is even more useful for players that are waiting for bugfixes... So I'll probably put it there soon, though I don't have the time right now.

Yes, but the entire prediction will use the same state. The prediction uses your vessel in its current state, so deploying the airbrakes while you're in orbit should update the trajectory. If the aerodynamic model doesn't update automatically, you can click the "update now" button in the map view. I haven't tested this specific case, so let me know if it doesn't work. I haven't tested it with chutes. The mod uses your vessel in its current state, so I think if the chutes are not deployed (even if you have triggered the corresponding stage), they won't have any effect. Once they semi-deploy, your trajectory will be updated (but that's probably too late to choose your landing site... there's room for improvement here). And same thing when they fully deploy (but then you'll probably land exactly below your current position so you don't need prediction at this stage) Prediction is not 100% accurate, because of inaccuracies in the simulation (for performance reasons, it takes several shortcuts), and also because it depends on what you do with the vessel during reentry (especially with wings, changing your angle will completely change your landing site, which is the reason for the guides on the nav ball, to help you follow the planned trajectory). Good idea.

SOI changes are not implemented yet either. That's the same issue than maneuver nodes : SOI changes before atmospheric encounter should not be a problem to implement, but for SOI changes after arerobrake I'll have to implement the detection algorithm from scratch.

As Mandelbrot said, not yet. The thing you want should not be a problem to implement (but not done yet) In my previous post, I was talking about setting a maneuver node on the trajectory after the aerobrake, for example if you aerobrake arround Jool and want to correct your post-aerobrake orbit to intercept Laythe right after that. This is the part I'm not sure how to do because KSP won't let me put the node on a trajectory that only exists within the mod.

Yes, and yes :-) To do it properly, I would have to implement a new maneuver node system though, because I don't see any way to place the nodes on a trajectory that is not the one computed by KSP. The first part will be to use the nodes that are placed before atmospheric entry, and this part should be straightforward to implement, but I don't know yet what I will do for nodes that are after.

Great mod :-) All the B9 parts unlocked in one click, you saved me at least 10min of a really frustrating activity. Thanks.

I just released v0.2.1 which now works with NEAR too :-) Also, it works with the stock aerodynamic model, excepted for wings. I haven't found any data about how KSP simulates wings, and I really don't feel like making tests to find out, so unless someone makes that work, it will probably never be implemented. Anyway, it's very likely that they will change the aerodynamic model at some time, so it's probably not worth spending time trying to guess what they are doing.

I've not investigated this issue yet, but added it on the bug tracker.

You said in a previous post it happened also when you are in orbit, do you mean the whole trajectory is above the atmosphere and you sitll have performance issues ? The mod should do nothing in this state. Another test you could do is download version 0.2.0, which disables prediction completely when you're not on the map view (unless you've set a target impact point). If you still have performance issues in this situation, I would tend to think it's not related to Trajectories. Also, it could help to know if your output_log.txt contains a lot of errors ; writing errors can slow down the game when it happens each frame. Anyway, I've added an optimization task, that would never hurt, but I don't know when I'll have time.

I could add an API for other mods to use (feature request added), but at this time the system is not designed to be used on multiple vessels at a time. Parachutes are not handled either. Also, it would work only for vessels that are fully simulated (not too far from the player), but the trajectory could be pre-computed at the moment a debris gets separated and kept in memory. I'm not sure the orientation would matter that much. It will change the landing zone a lot, but who cares as the debris won't be actually simulated by the game anyway ? Any trajectory computed by the mod will look realistic enough if someone looks at it from the map view. What I wonder is if it's possible to override KSP behavior of destroying debris entering atmosphere, and instead teleport the debris on the precomputed trajectory each frame to actually see them falling on the map ? At the end of the trajectory, they would need to be put on "landed" or "splashed" state so that they can be recovered later by the player (unless the impact is too strong and they get destroyed). I really don't know if KSP API would allow for this.

Yes, this issue has already been reported and is on the feature requests list. A work arround, and future updates about the feature implementation, can be found here : https://github.com/neuoy/KSPTrajectories/issues/10 Edit: didn't see Mandelbrot's answer before posting :-)

What white messages do you get ? Is it better if you turn-off auto-update ? It may be that your craft has an unstable aerodynamic profile. What I mean by this is that the aerodynamic behavior would change a lot when the ship is deformed due to accelerations or other factors. If you turn auto-update off, the aerodynamic profile won't be refreshed automatically, so you'll have to click the "update now" button after stage separation for example. But at least it won't update each frame as I suspect is happening to you.

It's integrated in the stock toolbar since v0.1.1 For those that still use the first published version, I suggest upgrading, some annoying issues have been fixed. Also, please indicate which version you use when posting bug reports :-)

Can you give more details please ? In particular, when the game is lagging, do you have the red atmospheric trajectory correctly rendered ? Do you see white messages on the right of the screen ? Do you use Ferram Aerospace Research ? Does it lag even when your orbit doesn't enter atmosphere at all ? The mod certainly adds some overhead to the game, but it shouldn't be a problem on most computers (if it is, the game probably was already lagging, the mod just makes it lag a bit more). That is unless you are experiencing some kind of bug, which I'd like to know to be able to fix it. Thanks.

Yes, unless you modify the descent profile (you can set your angle of attack or horizon angle for entry, high altitude, low altitude, and near the ground). These angles are used to predict the trajectory, and indicated on your nav ball along with another indicator telling you the direction to go to correct your trajectory in case you've drifted from the target. For the particular case of aerobraking (without reaching the ground), you don't have indicators on the nav ball, so the simplest is probably to follow the prograde vector (set AoA to 0° for all altitudes). This is something I should improve (for example, allow to target a precise post-aerobrake apoapsis and use the indicator for that)

I've released a new version. It should now work correctly with FAR and the stock model (auto-selected, you have nothing to do). Let me know if you still have issues such as the red trajectory not displaying, big performance issues, etc.

I don't know how recovery mods work. In fact I don't exactly know how KSP handles objects that reenter atmosphere but are far away (they are just destroyed ?) or crash on a body. The Trajectories mod could help pre-compute a trajectory, or offer an unified interface to compute aerodynamic forces whatever mods are installed (FAR, NEAR, etc.), but at this time it is really targeted at giving you a possible entry trajectory, not computing a free fall trajectory. It assumes you'll keep your wings horizontal and follow the planned descent profile. At no time does it compute torques, which would make debris rotate, which would change drag. Also, I use an aerodynamic force cache that is specific for one vessel. Even if it doesn't use too much memory, having a cache for each debris, assuming there are a lot of them, could become expensive. To sum up, there are certainly ideas that could be re-used, but it's not really adequate for a recovery mod in its current state.

Only on the map. I'm not fan of displaying stuff directly in the flight scene as it doesn't really fit with the rest of the game (admittedly, an external camera is already a bad thing for immersion, but drawing 3D lines is worst). About precision for setting the target point, I'm planning to add an option to specify an existing object (a flag, another vessel, etc.). And in the flight scene, you have two indicators on the nav ball that tell you if you're on the correct trajectory or not (look at the screenshots in the first post). They'll be embellished in a future release :-)

Do you use FAR ? If yes, do you know what version is installed ? Do you get a white message on the right of the screen when starting or resuming a flight ? Also, did you download the last version (i.e. Trajectories.zip, version 0.1.1) ? If you don't use FAR, the mod should use the stock aerodynamic model instead, but apparently this is broken in the current release. That will be fixed in the next release.

Good idea indeed, I'll consider that when the main functionalities are stable and usable (including NEAR etc.). Or tell me if you want to contribute that part of the mod (as you have already looked at the code) Thanks for the suggestion. I never heard of Principia until now, which seems an interesting mod, I'll follow the development. But as I understand it isn't usable yet. I can't tell if N-body simulation could make KSP more interesting, or if it would actually make it less fun. Depends on each one taste I guess.

I was working so much on the FAR part that I might have forgotten to re-test without FAR. It used to work but I might have broken that. I'll double check tomorrow.