Youen

Indeed, and also you'll have to interpolate in three dimensions (maybe not a big deal though). Typically, I think the CPU load related to forces computations would double (because you need two values to interpolate instead of one), but not more because you don't need to compute values that are not on your trajectory (I guess values that get computed would form a (curved) line of 2x2x2 blocks in the 3D grid, and if the trajectory changes significantly this line will slowly sweep new values). If the trajectory is stable, only the first computation would be slower (0 cache miss multiplied by two still gives 0). Are you 100% sure? I thought I had precision issues even without the cache (but also I fixed some bugs and made improvements all the time, so maybe it's better now and the cache is the biggest remaining contributor to inacuracy)

If I remember correctly, I took out the mach number as a constant, because it reduced the number of dimensions of the cache array. Currently the cache is two-dimensional : angle of attack and velocity. If you add the mach number, you multiply the cache size by as much different mach values you want to use. It might work, and might actually not use too much more memory if other dimensions resolution are reduced. Also, be carefull to make the system work for all bodies, Jool has a very different mach number range for example. The idea to use a lower altitude mach number as a constant could improve landing precision, but maybe deteriorate aerobraking precision? Also, something I didn't have time to try, is to add a simple scale factor to all forces, because they are always too low (or too high? don't remember). Whatever the cause is, it could workaround the accuracy issues (maybe).

I think it should be possible to extract any stage during flight, by looking at the staging actions, and cutting parts of the vessel graph where things are going to decouple. I think Kronal Vessel Viewer does exactly this. The user could then be proposed a field to type the stage number than will reenter (by default the last stage?). But that would not help for manual things you are planning to do (such as decoupling docking ports before reentry, etc.) Once this is done, the mod could simulate only the remaining parts. This could be slightly wrong for FAR that makes more complicated things (parts interact with each other, wing cross winds, etc.), but I don't know how inaccurate (or not) it would be. In my opinion, such an automatic system would be better than adding more user interactions towith the mod. Otherwise, each time you change your ship design, you would have to click the "Save aerodynamic profile" again, which means you'd have to remove the staged parts first, click the button, and re-attach the parts. Also, if you forget to do it, you may get inaccurate results, not be able to fix it while in flight, and don't know if you have to blame the mod or yourself for forgetting an update. The developpers who get bug reports wouldn't know either ;-) - - - Updated - - - I agree they could (should?) do that for stock aerodynamics. The problem is that it wouldn't work for mods such as FAR. But they could probably give an API that would allow modders to plug their system in.

The procedure for that is : - connect to http://ksp-avc.cybutek.net - login with the password I gave you on PM - update info in "My versions" (I see you already have done it) - either download the updated .version file, or simply edit the one that ships in Trajectories.zip to match the version number - edit the version of the DLL (in visual studio, in properties of the Trajectories project, in the Application tab, click "Assembly information...") - build in release which should also package the new zip This is not really a smooth process, feel free to improve if you can :-) I'm not sure the DLL version really has to mach, but I think it's cleaner.

Great :-) Thanks for your work (and other's), I would have hated to see it disapear almost as much as I didn't have the courage to keep it updated without actually playing the game ^^

If I remember correctly, I already had to set a private member variable of FAR (through reflection) because indeed rho wasn't passed where it should be. But the code probably changed since then. The correct way is probably to tell ferram about it (as you already have if I follow correctly) instead of trying to hack even more than I already did ;-)

About the g-loading bug, if I remember correctly, it happens since incremental trajectory comptation is implemented, because the current value is displayed (from the partial computation that is still in progress), instead of caching the value from the previous completed computation. I think I already fixed it after 1.0 release, but I didn't make a release with the fix. Not sure to remember correctly though, that was some time ago.

That's going to be the other way around :-) There's nothing wrong with FAR (as far as I know), it's Trajectories that is not compatible with it (yet).

Thread moved, please go here instead:

I'm not playing KSP anymore (for now), but that doesn't mean I'm dead ;-) I can certainly update the first post (to update info or redirect to another thread), and already gave access to Kerbal Stuff and AVC to Kobymaru. I'll also take a look at how to give access to github. The "only" problem is that the new version is not stable yet (or is it ? I've not read all posts but the bug doesn't always happen) Just let me know when you want to "officialy" release the 0.90 version.

Glad you found the root cause :-) I don't think the CPU load is an issue, because it doesn't degrade the worst case (which is when trajectories are actually displayed).

You might actually get him back in the end ;-)

I'm not sure to understand what you mean here. Body-fixed mode only changes how the trajectory is displayed (relative to the rotating frame of the body, instead of the inertial frame), but doesn't change the impact position (indicated by the red cross which is at the same place in both cases). Maybe would be worth waiting for it to work with FAR before releasing on AVC and Kerbal Stuff ? (people can still download version 1.1 on github in the meantime). Not yet, feel free to create one :-) No idea yet... Didn't have these issues with previous versions of FAR. The mod should not try to call FAR functions with out-of-atmosphere parameters, but maybe something changed and now it fails with almost 0 or 0 air density ?

Sure, sounds good :-) Let me know if you have issues getting the code, building it, etc. I don't have any clue as to what goes wrong with 0.90 though. Also, I'm afraid debugging KSP mods is really a pain, because there is no debugger that works (as far as I know). So you have to write stuff in the log file, or on the screen.

I wasn't even aware a new version of KSP was out :-/ I've stopped playing KSP for some time now. I'll take a look if I find some time and motivation, but honestly, if someone wants to take over the development of this mod, let me know :-) Some info if anyone is interested: - there are a few modifications that are already on gihub but not released as a binary yet - I'd suggest to drop the automated testing part, it's already broken and requires too much work to upgrade to new KSP versions - Compiling the code should be simple in visual studio : clone the repository, set the references to kerbal DLLs depending on where you installed the game, and build. - To speed up the development cycle, you can set the path of your game in the .csproj file, then pressing ctrl+f5 in visual studio (while in debug mode) will compile, place the mod in the game, start the game, and automatically load the default save game and fly the first ship in the list - the version of the assembly must be incremented before each release, updated on http://ksp-avc.cybutek.net, and the Trajectories.version file must be overwriten by the new one - when building in release mode (visual studio), a zip is automatically created, next to the sln file, that can be uploaded as a new release on github and kerbal stuff

You have the choice in the mod window to draw the whole trajectory, or only the trajectory that diverge from the stock one (i.e. starting from the first atmospheric entry) Excepted in body-fixed mode, in this case the whole trajectory is always drawn.

This feature has already been proposed. The difficulty is more about estimating the accuracy than displaying it.

This module is just used to save (ie persist when changing vessel and saving/loading) per-vessel settings (descent profile, target, etc.), so most functionalities work without it.

If it did, that was a bug. Also, implementation changed on how trajectories are rendered in map view, so I doubt they can be displayed in flight view anymore. The feature could be implemented, but that'd require a bit more work, and that's not something I'd want personnaly (drawing virtual stuff in flight view). If someone wants to do it though, it's easy to merge code on github and contributions are welcome.

At this time, with FAR and NEAR, I call functions on each part (actually on the FAR modules installed on those parts) to get the force depending of the velocity and air density. I can skip some parts (because they will be detached by staging), but then I'm not sure I'll get correct results because FAR uses nearby parts for its computations as far as I know. So it may be needed to dive more deeply in FAR code to find out how to simulate a different vessel. Also, maybe it's possible to instantiate a new vessel (that will be a copy of what we'll get after staging) and use it for computations. But I'm not sure if this can work without putting this "dummy" vessel in the physics simulation etc.

I mean that I'm not sure my code is correct (maybe there are still bugs), and also maybe it's inacurate (because of the caching system for example). There are other sources of drift between prediction and actual trajectory, as you mentionned, which make it hard to know where the problem is exactly when you don't land where it was predicted.

Staging is not implemented, so when you separate the command pod, it's completely normal that the prediction changes a lot. The prediction for the whole ship probably has similar drag forces, but as the ship is heavier, it will go farther. The command pod alone will fall short of the initial prediction. Ideally, the mod should be improved to allow select the stage that will enter atmospher, but I haven't tried yet, and I don't know if it's possible with FAR.

I don't think using the stock indicators is a good idea (assuming that would be possible), because they already have a meaning, that is different from the meaning of the new ones. But I do agree that the new indicators are ugly, and also they are displayed even when on the hidden side of the navball, which is wrong and misleading. As you stated, the correction indicator is just a hint : it is only relative to the distance of the impact point relatively to the target. So it doesn't account for any aerodynamic feature of the craft, it just assumes that pulling up will make you go farther (I'm sure it's plain wrong for some craft designs, but it should help with most planes). It should be replaced by some kind of arrow though. The other indicator just represents how the descent profile is configured, so if you follow it, you should follow the displayed trajectory (but chances are you will slowly drift over time, which is why the correction indicator is there). About calculating maneuver nodes, I wanted to follow the original game philosophy instead, which is to show you what will happen after the maneuver, but not tell you how you should modify it, which is quite efficient at making you learn orbital mechanics. The mod is not an autopilot either. These are interesting features though, but maybe for another mod. I use Verlet integration. It can probably be improved, but concerning accuracy I'm more concerned about the correctness of aerodynamic forces computations. It's hard to tell though.

ok, thanks for the feedback, I'll take a look at the stock aerodynaic code and bring the body-fixed mode back on top.

One of the big changes of latest release is that trajectories are computed incrementally. Each frame, it will compute a bit of trajectory, and then suspend until the next frame, where it will resume computing, and so on until the whole trajectory is computed. Then it will display the result, which will remain visible until the next trajectory is fully computed, etc. So the rest of the game shouldn't lag (this is the point), but depending on your computer, the trajectory might update at a low rate. 15s seems a lot though, especially if you didn't have performance issues before (the previous behavior was that the whole game was frozen until the trajectroy was computed, each frame). Maybe it's just a matter of tweaking how much time is dedicated to Trajectories each frame, I'll add an option for that. In the mean time, can you confirm that - the game does not lag? (only trajectories do) - no errors are reported? (counter displayed in the settings group) - what time is indicated in the "Perf" section? (this is the average time spent for computing trajectories per frame) - if you know that, what is your CPU?