Kobymaru

Doable, create an issue here: https://github.com/neuoy/KSPTrajectories/issues , try to describe what you want and what you need it for. Sorry, I'm not really interested in this feature. If you provide code, I'll merge it. As a workaround, you could use the Waypoint functionality or enter the coordanites manually into the text field next to the set button.

Done. BTW, there's nothing that prohibits you fromkeeping local changes and private branches around, you know?

This is only visible in the Debug build. No need, i already have a commit on my private branch that does that. If it really bothers you, I will merge that commit into the master repository.

Thank you guys, very good info in here! Turns out Eve is *even harder* than i thought.

Could you guys post a screenshot of that? That would be much appreciated.

That would be super complicated, because one would have to keep a copy of the vessel object around and predict what it looks like after the staging events, and change all the aerodynamic properties accordingly. No, far from it. It's the most requested feature right along flight-window trajectory display. But I'm no magician, don't know how to do these things and don't have nearly enough time. If you happened to be a programming wizard, however, I would love to accept pull requests for this feature! ps.: Like I said, the way that people do this is is leave like 2 rcs thrusters on the final capsule with a few drops of RCS to correct the final trajectory. We have bigger problems anyway, because right now the prediction is off by like 30 km.

Here is my understanding: Both situations, arrowhead front and arrowhead back are stable. One is obviously the lower-energy state, so one is "really" stable and the other is metastable. If there are any small perturbations to the metastable state (arrowhead backwards), then the craft starts flipping. It never starts flipping just by itself. Now where are those small perturbations if I have an active steering system that is set to cancel out any small perturbations? Think of it as balancing a broom on your nose. Sure, it's hard, because the broom wants to flip around, but with enough practice you can "steer" the broom so that it always points upwards. What I thought is that the Retrograde SAS setting would just do the balancing for me. This is what I don't get: why do I need a lever arm, and why do I need any more than minimal torque? If I align the CoP and the CoM perfectly along the direction of motion all the way from reentry, theoretically I would never need any steering at all. Practically, I would think a small reaction wheel would suffice to keep the two aligned. But even with a reasonably strong RCS system, they still slide away? I can't help but think that there is more going on. Especially since the flipout doesn't seem to be quite random.

I'm not sure I understand your question, but yes. Provided you have a sufficient TWR (which you need for landing anyway), you can do a suicide burn on any planet/moon. On the ones with atmosphere, the trajectory will look a little different, but the priciple is still pretty much the same.

Suicide burns with a horizontal component. When you want to land on a body, you usually come from orbit with a high horizontal velocity. The most efficient way to land from there is a real suicide burn, like a reverse gravity turn. "Stopping in mid air" and then dropping to the ground is significantly less efficient and isn't even a proper suicide burn. That's why I consider the current implementation of "suicide burn" not very useful.

I'd love to, but sometimes the design just doesn't allow that. Pancakes might be nice for going down, but especially on Eve they're a problem when going up. I already pushed my CoM as far down as I could. The craft above is just for illustration.

Hi! So I have been designing my Lander for eve, and run into problems on testing. I wanted to use the 10m heat shield to slow down, but it kept flipping out on me. I thought it was just my craft being asymmetrical, but after some testing, turns out that it's not. Check out the following craft: It only consists of parts on the stack, and the RCS blisters in a 4-way symmetry. Now when I use this craft to reenter in a steep angle, with RCS enabled and set to hold Retrograde, the craft keeps flipping out!! It always ends up in this position: Here is the craft and quicksave file for reproduction: https://www.dropbox.com/s/somq58cybk5aohw/flipper.craft https://www.dropbox.com/s/p2p1j25ybptcv3o/heatshield-flipout.sfs How can this even happen? Is there any way to fix this? Or is the 10m heat shield ultimately useless for reentry? Cuz that would be a real bummer.

Well it doesn't process atmospheric trajectories after SOI boundaries.

I don't know. It's compiled for 1.2.9, but maybe it works for 1.2.2. Just try!

It's not just about the decoupling force. The main issue in your case is that the craft has totally different aerodynamics after decoupling. If you ditch your heavy engine and only have a tiny light capsule, that is going to cause a lot more drag. And there is really not a whole lot you can do to fix that. You could guesstimate how much it drifts after decoupling. The most precise way is to leave some RCS thrusters on the final capsule with which you can correct your trajectory.

I'm afraid I can't reproduce your issue. On my install (with your archive unpacked) the windows is in the upper left corner. What I do see in your \GameData\Trajectories\Plugin\PluginData\Trajectories\config.xml file , however, is this: <ymax>-63554</ymax> Something seems to be messed up here. Deleting this file should really fix the issue. If not, then I'm actually out of ideas. Sorry.

Pre-Release for the Pre-Release for all of you early birds: https://github.com/neuoy/KSPTrajectories/releases/tag/v1.6.7-pre1 If you can get me the code of the mod featured in the video, it will increase the chances of implementation. BTW, What increases the chances of implementation to 100% is if you implement it yourself.

Great to hear! ps.: I think the color diversity is also a great idea, it's a pity that the ISM's and the Ranger SupplyPak's can't be told apart.

This is a wonderful idea! Could you do one for Machinery and one for SpecializedParts as well? I have dozens of storage parts because they are required for disconnected bases and I would really really like to reduce their number.

Doesn't really matter, but lets say that from now on, PR's should go to the original (neuoy) repository. I have merge priviliges there. I will be releasing the updates. ps.: I am loving these changes. I'm going to do a thorough review (takes a bit of time) and I already have a few change request, otherwise it looks really good!

The coriolis force doesn't exist. Surface velocity doesn't exist. They're all just artifacts of a rotating reference frame. Depending on the problem, sometimes it's easier to pretend that they do exist. I think this is not one of those cases. Or maybe it is. Who knows, I'm not a physicist.

The authors of about 6 scientific papers that I've read on this topic tend disagree with you You can't "just take the Integration", because sometimes the Integration doesn't even have a closed form (one that can be written as a formula). It matters in which direction, because ... That's cool and all, but what about the cosine losses in between horizontal and vertical? The optimal path is not a) a straight line or b) a quarter-circle or a cosine or any simple form. The optimal path is a strange curve that looks approximately like SQRT but isn't. That's what it looks like: Along this path, the cosine loss depends on your radial velocity around the body (because of the centrifugal force) and your current velocity angle. Your current velocity and angle depends on how much you have slowed down on the path before, and on the previous cosine loss. Your previous cosine loss depends on the previous radial velocity around the body and the previous velocity angle. And those depend on the cosine loss before that... This kind of recursive relationship can be expressed mathematically as a system of coupled differential equations. In its simplest form, these are: dv/dt == g * (TWR - cos(beta)) v * d beta/dt == g* sin(beta) This already is hard to solve, but possible (only for angle and velocity - not for altitude/downrange distance!), but mind you: this assumes Flat Earth Constant g Constant TWR No Rotation Which obviously breaks in multiple ways in KSP. Now any attempt to expand the model a bit to account for a spherical body, changing g, changing TWR, and rotation, you end up with shenanigans like this one: Containing mathematical functions that I haven't even heard of. Mind you, even these monstrosities come with a huge list of assumptions like "but only if the velocity is much lower than orbital velocity and rotation is low and it's a monday evening and it's full moon". Believe me guys, I *wish* it were as simple as "just add the second dimension". And I have read a lot of comments and a lot of threads that say "oh that should be trivial". But if you look at the physics, and if you try it out in practise you realize that it's not at all simple. edit: Click here for more fun stuff

Considering that you already forked it, you found it Please expose them in Plugin/API.cs

Ok. What did you want to change anyway? BTW, I would prefer to continue the discussion about Trajectories in the trajectories thread:

Yes, this is my fork: https://github.com/fat-lobyte/KSPTrajectories I will merge that into neuoy/KSPTrajectories bevore the next release.

You can make PR's on the main repo, I have privilges.