Youen

I just released version 1.0.0 incremental trajectory update (the game won't slow down while trajectories are computed) more precise ground impact detection (for mountains etc.) left click on Blizzy's toolbar shows/hide trajectories, right click toggles the GUI window possibility to use stock toolbar instead of Blizzy's reorganized GUI with groups that can be shown/hidden debug display (performances and error count) I think it's now ready to deserve a "1.0" version number, but as usual, let me know if you find bugs.

If you can target another object that is at the correct location, you'll see the distance displayed in the main view. But maybe you don't have this possibility if there is nothing yet where you want to go. I'll let you know when I find some time to make tests with procedural fairings if I find something weird or not. About the error margin, the worst case I have in my tests is 6km, but I only have simple tests at this time (a pod entering forward and backward with few additionnal pieces), so I can't give numbers for more general cases (I did make more complicated tests of course, but did not measure error). As stated somewhere previously in this thread, 6km is highly precise as compared to the real world, but in a game we could expect much more precise of course, especially if we consider Kerbin is much smaller than earth. But there are approximations for performances, and maybe bugs in the way I reproduce the FAR behavior (predictions are more accurate with stock aerodynamics), or maybe the KSP behavior (gravity, update time steps, maybe there is some kind of dampening in the physics engine to avoid creating energy due to numerical errors, etc.). However, the less obvious the bug, the most difficult it is to find, and 10km of final error means the error at each simulation step is really small, so it's hard to find out which part is wrong (if there is one).

The spiral is normal behavior. When body-fixed mode is enabled, the trajectory is displayed in the rotating frame of the body. Since you are getting away almost linearly, and the body rotates, this makes a spiral. Unless I don't understand what you want to show here, I don't see anything wrong. Just turn off body-fixed mode when you don't need it. You'd need it mostly for two purposes: fine tuning a geostationary orbit (the trajectory would reduce to a dot as you wouldn't move relatively to the rotating frame), or when flying in atmosphere (it would show the actual trajectory relatively to the ground). But in most cases, it just doesn't make sense and should be turned off.

1/8 of orbit is not too long, that's what I usually do for my tests, or even 1/4. No problem with wings if you use FAR (well, at least no known issue ; it should work). How much short do you land ? With FAR, a few kilometers are to be expected I'm afraid (usually less than 10km in my tests). Don't know if the prediction can be made more precise or if it's just because of "noise" in the parameters (controls, entry conditions, even very small changes could make a "big" difference, but I have not measured that yet). Also, I haven't tested with procedural fairings. Maybe there is something special in this case. I guess you are aware of that, but just in case, do you use the prediction before or after detaching your lander ? The prediction for the complete vessel could be very different from the prediction for the lander alone (staging is not implemented at this time, you have to stage/undock first and see what prediction that gives after). Finally, the orientation used during prediction depends on the part used to control the vessel. For example if you use the "control from here" option on a different part (control module or docking port), it could change the prediction. I'm just telling this because the control module of your rovers is not visible on your screenshot, but if it's not aligned so that the "front" is the front of the fairing, it could cause issues. Same thing for the "top" when it comes to lift prediction.

That's already the case :-) In normal mode, the cross indicating impact takes body rotation in account. In "body-fixed" mode, the whole trajectory is relative to the body rotating frame.

Apparently, yes, Trajectories can be seen at the end on the map view. Good video by the way, now I want to install Kerbin Side :-)

Hard to tell if this is related to this mod. I don't modify conic patches, and I render trajectories using my own code (procedural meshes), so there is no obvious link, but I can't say for sure. The vessel was actually in "landed" state ? I once had issues with physics not stable enough for the ship to be considered landed (don't remember if it was on land or sea), but maybe that's unrelated to your issue (also, this was before I started working on this mod, so it wasn't related to the mod in my case).

Actually, the issue has already been reported. Not prioritary, though.

Same problem here, can't attach any procedural wing. When I click on the craft, the wing blinks but doesn't attach (it stays selected). Also, if I drop the wing (not attached to the craft), clicking again on it will instead select another part (which detaches it from the craft). I play with NEAR (and other mods that are probably not relevant to the issue). Nothing is logged when the wing doesn't attach.

At this time, you can't choose (either blizzy's toolbar is installed and the icon goes there, or it isn't installed and the icon goes in the stock toolbar). I've added the suggestion to be able to choose in the feature requests

No problem. Thanks for reporting the issue anyway. I'll test with a similar ship if I find some time, but at the moment I can't think of anything that could go wrong with it. I think I'll add a display of how much time is spent computing trajectories, and also add a visual indicator when an error occurs during computations (such as a counter), so that bug reports are more precise.

The altest version (0.4.1) should integrate with blizzy's toolbar instead of the stock one if blizzy's is installed. Let me know if it doesn't... The left/right click has already been suggested.

Indeed, stage separation is not implemented yet. This looks like normal behavior in relation with the current features.

No one reported such issues yet, and in fact I doubt it's actually related to Trajectories. The mod mostly doesn't interact with anything, except FAR. Also, I play with tweak scale all the time and didn't have issues. Anything relevant in your log file? Also, you said the problem disappeared after removing Trajectories, but maybe it was just because you restarted the game? Let me know if you can reproduce the issue, as that would be a huge bug to fix (though apparently a rare one).

This message is normal, it just means that since the atmospheric trajectory is too long (very shallow), the prediction stops in mid-air to avoid simulating forever. The lag you are experiencing would more probably be caused by a bug, because if KSP runs smooth without the mod, it should still run well with, even for the maximum trajectory length. Nothing relevant in output_log.txt ? Most times such a bug happens, the lag is actually caused by exceptions logged every frame, so the corresponding part of the log is easy to spot by scrolling (lot of identical errors in a row). Don't know if it's what's happening to you, though. I assume you've tested with the latest version ? (0.4.1) And what version of KSP ? (0.25, 32bits, windows ?) If you have the time, I would be interested by your .craft file (composed of stock parts preferably) and the log file.

I don't know 6.4x Kerbin, but it looks like it's a config for RSS, which has been reported not to work with Trajectories (haven't tested it myself) I haven't got any negative report concerning linux 64bits. It should work, but I haven't tested it either.

I thought about that some time ago, but the actual implementation is that you use the manuever nodes as usual, but you can't place any after the aerobraking. So you will see the trajectory after aerobraking, but you can't use it to plan further maneuvers. Also it won't compute SoI changes. Maybe some day I'll find a way to trick KSP by adding conics that it didn't compute itself, but the API does not look like it's made for that, so I don't know if that will be possible or not. Of course, you still see the stock trajectories after aerobraking, that do not take into account the atmosphere entry, and you can place maneuver nodes on them (that are ignored by the mod), but they are useless as you'll never get there. That's already a feature request, but at this time you can't.

OK, I've added a note about that in the first post, but I wonder if you wouldn't be better off playing the 32 bits version, or maybe installing a dual boot linux (I've heard the linux version runs very well performance wise, but haven't tried myself). So far, I've heard only bad things about KSP 64 on Windows.

Don't know if it's the right place to ask, but I noticed all imgur albums are cropped recently (the bottom of the image is not visible unless you display it fullscreen, which is impractical to view all images). It used to work as far as I remember (the image was zoomed out to fit entirely). Is this a problem on my computer, a modification of imgur, or a problem related to the KSP forum ?

Actually, it's pretty close from 1.0. All the features I planed for that first "stable" version are there, and I think all critical bugs are fixed. The simulation is stopped when you're not in map view, unless you have set a target (because the guidance markers on the navball need it). I think, however, that the simulation still runs if you're in map view even if display is disabled. I'll double check that because it doesn't make sense. On a reasonable computer, it doesn't make too much difference on performances anyway (reports about heavy lag were all because of bugs, but if your game is already lagging, it will surely make things a bit worst)

Cool :-) I'll close the feature request and add the info in the first post. EDIT: actually, the DRE feature request is about estimating survivability along the predicted trajectory, so I let it open.

Can you post your KSP_Data/output_log.txt file? Also, I suppose you have already tried uninstalling Trajectories to check it's actually related to that mod, but if not, that would be the first step. For your information, I haven't tested the mod with a 64 bits version (neither windows or linux or mac), so I don't even know if some kind of adjustement is usually required for mods to work on these versions of KSP.

@Plusk: glad you posted screenshots, looks like there is an easy fix for you : you need to move all 4 sliders to 180°, not just the first one. Each slider corresponds to a different altitude, so what you've actually configured was a backward entry, followed by a return at high altitude, and then going prograde until impact. If you set a target (button in the GUI) you'll see markers on your navball : the square indicates what is configured in the descent profile, so you'll see that with your setup it will move prograde at some point. Not sure it'll work perfectly even with the correct descent profile, though, I didn't know deadly reentry was adding ablative shield directly on the pod, but that may cause issues, I really don't know as I don't play with that mod and haven't tested yet.

New version released, 0.4.1 is compatible with FAR 0.14.3 (only a small adjustment was needed)

Matrix Aran, I just tested : it works with FAR 0.14.2, but not with 0.14.3. Thanks for the bug report, I'll take a look to find out what goes wrong.