CBase

I just posted some pre releases of current state for MechJeb and Trajectories. I only tested it with KSP 1.9, but should work. Please note: These are private dev releases with some unreviewed changes ! Don't bother the official Trajectories team or bug report if you have any issues. https://github.com/cbase2/KSPTrajectories/releases/tag/2.2.2.0_MJ https://github.com/cbase2/MechJeb2/releases/tag/2.9.0.0_Traj

This is my typical 1st stage with deployed wings for reentry: My additions to trajectories for this: include deploy angle for control surface calculations fix orientation bug with up / down being wrong on retrograde entries, which affects tilted wings changed reentry altitudes and sliders to allow better control between -10° AoA (low altitude) and -60° AoA (reentry) Kind of. I did add some Trajectories API code and a major rewrite of MechJeb autoland to follow and adjust Trajectories AoA with the same goal. With a drag parachute at final approach the system is slow and stable enough to hit always the runway and often even launchpad with less than 10m difference. Without any parachute difference is still around 100m, so no pure SpaceX like landings. The rocket is simply to fast, Trajectory predictions not exact enough and since it should work a vast variety of rockets fine tuning control code for one design does not pay off.

The size of Kerbin and therefore required skill level to reach orbit is the fact I really admire most about KSP 1. And the decision to publish the API and embrace plugins was probably key to it's long running success. Without it would have been a great game, but never received the community and long term motivation of all players here.

I would guess that load and revert do set up the universe differently, and since any choice of origin is arbitrary, does it matter ? Compare rootPart.rb.worldCenterOfMass and vessel.mainBody.position with vessel getWorldPos3D: If all change, simply the origin was choosen different.

Actually you should plan as well for differences in surface altitude. Predicting the true landing position for the suicide burn is way harder than the speed timing. But without perfect position you do not have perfect altitude... So as Laie wanted to express: Add some safety margin for things that you do can not know exactly when starting the burn. Kerbin has atmosphere, the Mun not. The difference is huge even without parachutes, even from 1000m down. No single equation will get you landed on both. Unfortunately the equations are not that easy even for the Mun as the problem is 2d: You need to kill horizontal speed and gain vertical speed, both are connected by the vehicle angle which constantly changes. However you are right, basically it is a rocket equation reverse, so iterative solutions or known solvers might help. I did recently touch this topic by MechJebs Landing scripts, but only changed final descent, which kicks in once your are falling mostly straight.

+ Fairings Especially if you use procedural fairings or tweakscale to create smaller version just around seat this is most light weight solution. Do not forget to equip helmet on launch

Since I just managed to tame the throttle control PID for final touchdown, I can now share a short video, around 2:45 you see the parachute timing in action. I just noticed that I did not push a bugfix on bodies g value, so if you want working code, look again The following roll is actually just an effect that upside is always orientated towards target during parachute descend, which is mainly to fine tune landing as described above. But it has the nice benefit of getting the rocket vertical very fast using the lift of control surfaces to turn.

PartThermalData is way more messy about internal heat model than you need, Part class has it all. However do note that overheating has two separate aspects: Core and Skin temperature, so to get for instance the most critical percentage (vessel should be current Vessel object): double maxTempRatio = vessel.parts.Max(p => Math.Max(p.temperature / p.maxTemp, p.skinTemperature / p.skinMaxTemp) ); Or to get count above some limit double limit = 0.7; double maxTempRatio = vessel.parts.Count(p => (p.temperature > p.maxTemp * limit || p.skinTemperature > p.skinMaxTemp * limit) ); If you need both at once, you should actually code the foreach loop on parts.

Assistance / improved handling of manoveur nodes so it is less a dark art to find transfer and swing by. I do use MechJeb currently for transfer planning, but you just pick a point and then some transfer is created, however I would prefer to have an easier explorative way that as well lets me change parameters without loosing target. So really it is about another parameterization than the current orbital directions.

Is there any mod that helps to display the shock cones for reentry ? It would help to place high temperature parts where they are actually needed. The data structures in KSP do not look so easy, to make sense of them without display.

Actually I got pretty descent results on Kerbin on parachute timing, see https://github.com/cbase2/MechJeb2/blob/master/MechJeb2/LandingAutopilot/AtmosphericCorrection.cs. Parachute.Update() is what you are probably looking for, it is calculating horizontal slow down distance for netwon drag (F = k v²) until terminal velocity with open chutes: x(v) = m / k * (ln v - ln v_t) However I made some approximations you should be aware of: During semi and full deployment drag is linear increased which I ignored. I simply added the time from issueing deploy command until it is fully deployed and multiply with speed at start of deployment. It was good enough, so I never cared to adopt x(v) for a k(t) = k_0 + k_1 * t. This is probably biggest error so far. It is pure horizontal slowdown. Actually the slower you get, the more Drag points up and increasing fractions do not slow down horizontally. However you are already quite slow once this gets important. The slower you are, the less error the approximation results. If you have drogue and normal parachute however I do calculate that inbetween only the drogue chute will slow down until other is safe to deploy, which is easy by calculating x(v) for each section. KSP Drag includes a mach dependent term, which is a parameter curve. Damn ugly to integrate, Approximation k(current_mach) = k(v_deploy_start) makes life easy. KSP Drag is dependent on atmosphere density. Damn ugly even to predict the altitude, since altitude affects drag which in turn affects point in time you would deploy.... I am simply using current atmospehere density. Actually Physics in KSP are calculated 50 times per second or with 0.02s time steps. The last two errors are small since I update them every time step and adjust parachute opening. The very final precision up to 1m can be gained with control surfaces while floating down on parachutes when you rotate lift from static deployed control surface towards target.

Since I still like this challenge to stay cheap, here is another submission to the OBC comittee: Bootscience, a level 4 tech rocket with two crew spaces and full science: Material Bay, Goo, Temperature and Pressure for counting 4596 mission cost due to recovery capped at 5000. All without using Trajectories or MechJeb, although the pain for a perfect landing without Trajectories was bigger than I thought. In total I needed 14 landing attempts, 7 of them within 2km. Since currently I cannot upload full 2:30 h, here are 5 video excerpts. Some notes: Thermal Debug for Science Jr reads 2nd line "All Skin" if it is shielded by upper part and "Exposed Skin" if angle of attack is wrong. Switching between Stability and Retrograde get into optimal AoA. Total of 4 videos, hit next for failed, close and final successful landing attempts

I am in a single Career only, but since I racked up millions and unlocked the full tech tree, my career game plays mostly like sandbox propably. Actually I am only slowly following the career challenges and usually end up with some other stuff until at some moment I return to actually progress the mission line.

Yup. So I probably won't use that to land at KSC, because I might can't do that without it. For me it reduces landing attempts until it is perfect as it roughly simulates my landing position. Actually even with Trajectories I usually need 2 to 3 attempts until a perfect runway landing, without probably 2 more until I find the right timing. Basically you eyeball a deorbit node, quick save, perform the landing and notice the target difference. Then reload and adjust the time by distance/orbital_velocity, save and repeat. With Trajectory the intial guess is better. Actually my overall playstyle nowadays is that doing it manual is no solution, but to look for a SpaceX pipeline: set up an automation, then improve while repeating. So I spend propably same amount of hours on equations and coding as in game.

Actually when I played around yesterday late night I didn't really recognised that I found a bug about solid fuel calculation as mystifeid showed. In my head the main dV was still coming from the Terrier, just by factor of 4 disguised as it's ISP changes from 85s to 345s and I strapped on boosters in various configuration until I reached enough altitude to be over 300s. Actually I do think launchpad dV is hardly a good measurement for efficiency due to varying Isp. What is your vision of efficiency ? Is it about burning the least amount of fuel ? Maybe measure overall dry to wet mass ratio. An easy version is to simply take compare orbital mass to launch mass, but this strongly discourages staging. Up to you, if that is your intend.

Oh sorry, I never thought of MechJeb as this. Yeah of course I can, actually I am running a heavy modified personal branch where I touched most of the functions. I will make a video with MechJeb off, just to be sure, is Trajectories okay for landing at KSC ?

One challenge is about lowest dV on launchpad. Well since we all know that physics require you to have at least ~2250 m/s orbital speed and you will loose some dV due to drag and gravity: This is really about lying with numbers, make your rocket look bad to KSP Lets try: Boosty shows only 785 m/s and has mission cost of 4383 -1708 =2675 but still reaches orbit

Thank you for all your tips, I am getting pretty close but lack ~80 m/s on final speed with orbits of 60x2km at best. The flip is still $*%&* , but I never manage to get your speed and AP altitude. When I look at your screenshot from 18700m, with nearly same pitch my drag readings are 3x higher although AoA is only 0.1 instead of -0.09 and lift is about the same while my surface speed is 50-60 m/s slower. Maybe some more tries tomorrow

Sorry, I forgot to mention the science feature in my description, but you can see the temperature reading in the mission report , so I do hope to qualify for a Silver Claw too. And mission cost are 1176 funds after recovery. Thank you, I just discovered this new addition. Since I am the first and only one, may I suggest a change on this: Reward the highest dV in orbit, rather than on launchpad. Adding a Juno for instance would blow up the launchpad rating, but is hardly helpful and provide assistance to other players by bringing up clever designs.

While browsing the parts I noticed Rockomax to Kerbodyne tank adapter is pretty cheap for its content, so an idea was born: Fatty I 6 parts, 4873 funds on launchpad give 3803 m/s dV atmo dV and 934m/s in orbit, 3706 funds recovered with a runway landing. Now that I think of it, I spent propably more fuel to hit the runway than the 2% increased recovery was worth . But it gives a nice picture

Since I think the idea for this ship is incredible, I did try to rebuild and fly your design, however I am completely failing when it is time to turn the ship for the Spark: It takes me quite long and I am loosing at least 150 m/s speed during turn around. Can you give any hint how you pilot that thing ?

If it happens again: Look at the clock in left corner: is it green, yellow or red colored ? (which tells if your system can keep up with all calculations, which might be a reason for some function calls being skipped by Unity) If it is not green: Try to have Trajectories Settings Tab open, there is a time and percentage value how much it is taking from your main loop. You might want to enable cache at the price of reduced precission to get faster calculations.

No pretty pictures, just a day with motion equations for powered landings with and without atmosphere: After 15 years solving integral equations again But the target speed is pretty much now perfect, I am just fighting with the MechJeb PID controller now: Very hard breaking leads to overreactions and rockets hopping before touchdown. Although some looked pretty funny to hop, do a salto and then either crash big, run out of fuel or simply land and tip over...but many RUD today, lucky they all have drone cores

Nice Job for starting from scartch Just being curious, what is your guidance like ? I seems mostly a Gravity Turn starting at 100 m/s with 5-10 degree initial turn. However I did notice small throttle changes and heading is sometimes slightly off from prograde, which does not make sense to happen if GT is scripted. And the position / velocity error indicate that your script tries to follow some trajectory, but how did you gather this ? Or is it computed with MatLab ?

Ups sorry, I didn't intent to sound like a teacher . Just as you were suprised that a coordinate of Kerbin changed gave me the impression that you expected that it is constant. Actually I do think once you change to a vessel or the vessel changes SOI, the frame is choosen by some comfortable transformation and then simply stays as it is.