CBase

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.

Yeah rockets in KSP are not that bad at it Actually you can achieve pretty high reentry angles and unbelievable aerobraking using this. My standard angle is nowadays -45° from retrograde at reentry and around -15° @ 35km altitude, but may change by +- 15° to hit KSC, so yes I am doing reentry angles up to 60° with rockets . PE from deorbit is ~5km, which is steeper and more precise to target, but still low enough on dV for deorbit burn. I stopped testing lower PE even at -250km coming from 100km orbit as it was still easy to aerobrake with this high AoA until parachute safe speed. If you have procedural wings try a starship like configuration with controlable pair at both ends for even improved body surf. Bottom one is doing pitch control on ascent but stays fully deployed for lift and drag at descent, upper one is straight on ascend and invers half deployed at descend with negative authority pitch control to keep body surfing angle. I did post a couple of screenshots recently here: With control surfaces you can as well use the parachute descend to improve landing precission if you keep speed ~50m/s by several hundred meters. Either stage some parachutes or do powered touchdown with low parachute count.

I do not know about kOS, but coming from Addon coding, the KSP coordinate system is strange. Probably for historic reason rockets in KSP do fly UP, not Forward by the Unity definitions. However Planes and Rockets in Orbit still fly UP to be consistent, not forward. Some Addons tried to "fix" this by swapping Y and Z components, but every time they exchange with KSP code of course they need to use KSP conventions, so they can only be partially consistent. Reference Frames is another Topic: Rockets fly around Moons, which fly around Planets, which circle Kerbol and all of these Bodies rotate. And intersolar suns move in a galaxy and galaxys around.... Seriously: Get comfortable to always think in terms of a reference. There is no "right" coordinate system and even if you define any as this, movement equations would be too complicated, so just get the reference right. Oh and one caveat about rotating coordinate systems: If you do calculate the movement equations when changing from one to the other https://en.wikipedia.org/wiki/Coriolis_force and https://en.wikipedia.org/wiki/Centrifugal_force appear. They are small enough to be neglected if you fly around Kerbin and think about the Kerbol rotation once a year. However they get way bigger if you transfer into the rotating Kerbin system and to get fixed Latitude / Longitude. So better keep bodies rotating and just stay in a center of momentum frame. Finally one advice: There are already tons of conversion systems, try to find a solution before solving something yourself: Unity has Quaternions and Transforms, KSP has Transforms and CelestialFrames. These are battle proven, handling corner conditions etc. Your life will be easier with finding the right reference transformation than coding it yourself. Since KSP is already pretty mature, someone will have had the same problem before and there is propably a solution out there. Somewhere.

Actually I always assumed that the game uses the correct surface speed for given altitude for drag calculations, the basic methods in CelestialBody are there and these are used in Trajectories addon (simple vector cross product of radius and angular Velocity). However Trajectories never got Drag 100% right and I never understood why, so I looked into this part of the game and to my surprise something complete different was there: It seems the game splits movement between Unity (only mionor part) and internal handling in Krakensbane Class, which as the name suggests fixes vessels being ripped apart by the Kraken. However the difference is very small from a test, so in respect of your question the answer is: Yes the game uses the correct rotational surface speed for each altitude. Yes, sorry for not being clear about this. They are all calculated per part, so you can display them in aero part debug output (which is a good reason to do the same), but the function is the same for all parts.

I am afraid, I found another bug in Research Contracts: If the contract requires a return to Home and you save and load after completion, the contract is never fulfilled. I did trace it down to experimentCompleted being false in a second save, although the WBIExpCompleteParam state is Complete. In WildBlueTools/Contracts/WBIResearchContract.cs Load method you have: if (node.HasValue("experimentCompleted")) bool.TryParse("blah", out experimentCompleted); I do think it should be experimentCompleted = false; experimentCompleted = node.TryGetValue("experimentCompleted", out experimentCompleted ) && experimentCompleted; // only true if config has value and it is true

Okay this might get a longer post, so first I like to give overall structure: Prograde Drag Drag Cubes and Angle of Attack Special cases I am aware of Before I start, let me point out that all of my knowledge I got from reading posts, working on Trajectories addon for my personal need and finally some reverse engineering when documentation was sparse or outdated: Only KSP holds the truth for stock aerodynamics ;-) Prograde Drag Drag is created by motion and always opposite of the surface velocity. Therefore air sees your object from a single side: Opposite of velocity. For simplicity first lets assume you are flying perfect prograde. Real Drag is gets very comlicated once air get turbolent. As long as it is laminar, the newton equation you found is a very good approximation: KSP does basically this for every single part and then adds up all the drag from the parts with respect of the point, so asymmectrical drag will turn the object. Let us take a moment and think how S and Cd are derived: The exposed surface area is the surface projection of the part in the plane normal to direction of drag. So going to your cylinder example: from sideways the surface area is a rectangle with surface area of length * diameter of your cylinder. For constructs KSP subtracts the opposing surface area of parts attached via nodes. In Stock KSP nothing else. The drag coefficient Cd is holding all information about the shape when looking at the object in the direction of the drag, really look up https://en.wikipedia.org/wiki/Drag_coefficient to understand Cd. This is the answer how a flat surface rectangle can model your round cylinder drag. Especially for flat backsides turbolences are the true reason for their higher Cd value, so by clever calculations of Cd you get more realistic than the original assumption. Cd and S are usually calculated by Unity from the parts model when loading the game assets. ModuleManager caches these part values in case you want to look them up. In the theory outlined on wikipedia the Cd value includes drag contributions from all sides of the object: Front, side and backside. Since constructs can modify for instance the backside by a pointy cone, KSP splits real world Cd into contribution by side and via multipling with exposed surface area only relevant contributions are counted. Now we have an understanding for prograde drag using Newton drag approximation. Newton drag has its limitations: Once you get close to the speed of sound (mach 1) drag changes a lot and when the laminar assumption fails you need to modify your calculations. KSP does both of this by applying a factor for each to the calculated drag, one is a function on mach number, the other a function on a pseudoreynolds number which is rho * v. The actual functions are parameterized curves, since they are exposed in the API for Addons, I never cared to explore them more. So still for prograde drag we are at: 1/2*rho*v^2*Cd*S*f(mach)*f_reynolds( rho*v) Drag Cubes and Angle of Attack So far the natural orientation of our object and the flat surface defined by the drag vector as normal were perfect aligned. Of course we could calculate Cd for any object orientation (remember that Unity does this on loading), KSP choosed to only do this for all 6 perpendicular sides of an part, which forms the Drag Cube. If you want to create a mental model of this drag cube, do this as rather wireframe with scaled surface cross sections painted on the sides. Before I mentioned only a f(mach) function which is now split into 3 different functions depending on the orientation of our cube face: f_front(mach), f_back(mach), f_side(mach). In order to get the resulting drag KSP calculates the normalized dot product of velocity and each cube faces normal, which is basically the cosinus of angle of attack for each cube surface. Depending on the angle it uses this cosinus to linear blend between f_front(mach) and f_side(mach) or f_back(mach) and f_side(mach). Since sideway modifiers are smaller, drag is smaller if the angle of attack for a surface is higher. Special cases Most obvious case: If the part is shielded inside a cargo bay or fairing it has no drag. Some parts like struts or fuel lines have simplified constant drag values instead of Drag Cubes. Parachutes nowadays have Drag Cubes for each state (packed, semi deployed, deployed), but ommit the area occlusion and chute direction is independent of part. I did saw some special case code for very low drag situations, but never cared enough to investigate further. All lifting surfaces (wings, control surfaces) do calculate drag completely different, mostly dependent on a function of cosinus between velocity and wing normal. https://github.com/cbase2/KSPTrajectories/blob/master/src/Plugin/StockAeroUtil.cs has all wing calculations if you are interested, the official repository from neuoy has them more obscured via KSP function codes which has some side effects on using the current orientation.

For getting the terrain height of course there are documented API functions: https://kerbalspaceprogram.com/api/class_celestial_body.html#a3a7c07a805f442124a523a149923f8a6 The calculation of perfect suicide burn is something different. I only displayed the readout from Kerbal Engineer Redux (KER) Addon in KSP, but never thought how it is calculated. For non atmospheric bodies you can rely on KSP Orbit Class calculations, which does a great job on all spherical 2-body gravitation equations: https://kerbalspaceprogram.com/api/class_orbit.html The current orbit can be retrieved from the vessel Object. Since KER has a suicide calculations, you might want to look how they did it (actually it seems they didn't like calculus and physics that much as well): https://github.com/jrbudda/KerbalEngineer/blob/master/KerbalEngineer/Flight/Readouts/Surface/ImpactProcessor.cs Basically they follow the orbit until it hits the ground and then do interval search for a breakpoint. Fun fact: KER developers never used the TerrainAltitude property, but some more complex based on rotation matrices, although it might not been there at the time when it was coded.

Hi, since my rocket builds that I land with Trajectories usually have some deployed control surfaces, I did stumble across some orientation issues with original lift calculation and added deploy angle for control surfaces. Cache precission and decent configuration was also something I wanted to change. Finally I extended the API to integrate with an altered MechJeb Landing autopilot. Right now my personal build works for me, but since I do play on most recent KSP version only and actually the most important feature is v1.8+ I am not sure if a pull request is a good idea. Anyway if you are interested: https://github.com/cbase2/KSPTrajectories/tree/new_features I did cluster most changes into feature commits in this branch.

That's it ! Thank you ! Actually I had to edit the savegame as well, because my Lab on the Mun was created with the wrong value and the attribute is persistent.

I have all requirements: Situation Orbiting or Landed: Checked as visible Crew: 2 scientiest on board LabTime 36 in vessel: checked (via display as a resource) So why doesn't it complete ? There is a requirement that isn't listed or anywhere described like pressing a button and so. Shouldn't it display somewhere that it is completed ? It can not be found anywhere.

Actually that is a good question, how do I tell and what is needed to complete ? Actually I had to add Module WBIExperimentManifest in \WildBlueIndustries\000WildBlueTools\ModuleManagerPatches\MM_Stock.cfg or "Show Manifest" would not appear. As I look into the WBIExperimentLab definition I do see it creates a resource LabTime that is required for the experiement, but no stock part has the resource. In the screenshot there is a field "LabTime:" with no value. Is this the problem why the experiment does not complete ? LabTime was on vessel base collected, when adding the resource I saw 36 LabTime in vessel overview. I found out that I should "Start Experiment" somewhere, but somehow the GUI from WBIModuleScienceExperiment is missing, no idea why.

... sort of! ahhh come on, it didn't tip over and within 10m of target from orbit isn't that bad. But challenge accepted, today I improved powered braking, so descent angle settings and remaining error from Trajectory are less of a problem. As well the final approach now slowly decreases deploy of control surfaces near target and some builds got within 1m: @ SpaceX: Got any jobs open ? I did try as well some 1.25m, 2.5m and a massive air breathing 5m first stages: The Rockomax one is little more off, since the single drogue chute had a terminal velocity ~150 m/s which proved to be challenging fast for MechJeb target predictions. During my tests I noticed that the "free falling" landing burn calculations, which are perfectly fine on a moon, waste a lot of fuel with any parachutes. First optimisations were maybe a little too aggressive But finally another 50-100 m/s dV could be shaved off, so right now 350m/s in orbit is totally fine for a full recovery landing if the parachutes slow down to ~ 50m/s. Overall a very successful day

Finally modified MechJeb code to land using Trajectory predictions and actually hit the target close enough to land at LaunchPad: All corrections are done by control surfaces and using two drogue and a single normal parachute. For final touchdown engines helped to shave off last bit of velocity. Total dV used from 80km orbit to touchdown was less than 200 m/s. Now it is time to clean up code a bit for pull requests and test with other rocket sizes / builds.

First: I studied physics and the general trajectories in KSP are doing good on physics (there are some few simplifications which are sure too subtle to notice by common sense alone). Your problems are with the visualizations in map view, but lukcily these can be changed: Please note: The movement is still the same, it just changes how to display them to you in respect of different world views.