CBase

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.

Not that I am aware of it. I do have Here are all my mods: Verzeichnis von C:\Program Files (x86)\Steam\SteamApps\common\Kerbal Space Program\GameData 08.11.2019 18:37 <DIR> 000_ClickThroughBlocker 08.11.2019 18:37 <DIR> 001_ToolbarControl 02.11.2019 18:56 <DIR> AllYAll 29.04.2018 00:27 <DIR> B9_Aerospace_ProceduralWings 21.01.2019 17:03 <DIR> B9PartSwitch 30.10.2019 08:43 <DIR> CBase 13.09.2018 10:13 <DIR> CorrectCoL 13.10.2019 09:19 <DIR> CustomPreLaunchChecks 21.01.2019 17:03 <DIR> DeployableEngines 21.04.2019 13:12 <DIR> DMagicUtilities 26.03.2020 18:16 <DIR> KerbalEngineer 28.10.2019 17:32 <DIR> MechJeb2 16.09.2019 16:16 <DIR> MiningExpansion 22.03.2020 10:29 <DIR> NavBallDockingAlignmentIndicatorCE 21.01.2019 17:03 <DIR> NearFutureAeronautics 22.02.2020 20:30 <DIR> NearFutureSolar 08.11.2019 18:37 <DIR> PartAngleDisplay 12.05.2018 12:23 <DIR> ProceduralFairings 13.10.2019 08:52 <DIR> ReStock 13.10.2019 08:52 <DIR> ReStockPlus 13.05.2018 02:55 <DIR> SpaceY-Expanded 13.05.2018 02:55 <DIR> SpaceY-Lifters 14.02.2020 07:58 <DIR> Squad 20.09.2019 14:26 <DIR> SquadExpansion 08.11.2019 18:37 <DIR> TacFuelBalancer 17.05.2019 00:19 <DIR> Trajectories 31.08.2019 03:26 <DIR> TriggerTech 06.10.2019 10:25 <DIR> VABReorienter 08.11.2019 18:34 <DIR> WaypointManager 21.01.2019 17:03 <DIR> WildBlueIndustries 22.03.2020 10:06 <DIR> WindTunnel 22.03.2020 10:40 <DIR> ZeroMiniAVC CBase are only part patches for extended service bays, no code.

I am afraid that you need two vessels that started independently from Kerbin to fulfill a transfer crew contract. I am not sure if you can dock them at LKO and do the transfer to Duna combined.

I finished up with adding "Air breathing Gravity Turn" to MechJeb. Of course it needed some tests, but rocket purists in HQ did not wanted to risk too much money, so a smaller launch vehicle was used for first tests: Everything worked well. Since the idea of this GT is to stay low and burn as much in air breathing cycle, I did get rid of turn start altitude (fixed at 500m) and "Intermediate" settings, instead added speed when I switch the initial closed cycle to air breathing mode (~200/220 m/s depending on TWR worked for me) and a minimum TWR at which it will throttle down any conventionell rocket engines to save fuel. For real workloads a mixed engine layout with vectors help to get off from launchpad and they are more efficient later on as well. During tests it got obvious that efficient GT are very shallow and do get hot... So I did some work on thermal limiter, which previously was mainly designed to control core heat transfered from engines and will now prtect entire vessel including all skin from overheating. In the picture it can be actually seen that it completely throttled down to keep criticial parts skin temperature around 97%. If anyone is interested to push to main MechJeb give a note here. Commits are https://github.com/cbase2/MechJeb2/commit/d18719272ec01dd6d7b2296bdcd1717b64c77822, https://github.com/cbase2/MechJeb2/commit/eeb80f321eebc4ce750dfbd1c759c03b287a0453 and https://github.com/cbase2/MechJeb2/commit/3d2bf21b3cff074291d82d0bc9b82e390664d92a Afterwards I got inspired by some other post about how to control Starship like stages: Hmm actually two set of control surfaces on a SSTO rocket sound interesting and nice to control landings. SpaceX mentioned some 60° entry for Starship, if this would work ? It does And with a PE of 15km it was very smooth, although in lower atmo the angle needed to be reduced to 15 to 20°. The MCS near the engines bleed of speed very well at their high angle while the other has just enough control to prevent wild spinning. Perfect landings at runway got very easy to reproduce. Let's see how steep we can go without overheating from a 80km orbit: PE at 5km no heat problem, next PE -10km fine as well, -25km , -50km , -80km , -120km , -250km ... and never it got beyond 80% of critical heat. I did stop at that point because just the deorbit burn cost 400 m/s and slowed down so substantial that it was clear that it would be fine on reentry. Personal favorite design choice on SSTO from now on: two pairs of B9 full moving control surfaces. All this tests got back my interest from last year to get Mechjeb to do perfect landings with Trajectories on Kerbin...

I do hope this thread is the right place to ask: I did not install MOLE, but got the experiment science extension and contracts through Buffalo parts. I did accept an "Run Ice Cream Experiement on the Mun" contract and thought I could do it without installing MOLE since it modifies stock science parts as well, but I am struggling: I did load the experiement on a science storage, included the stock science lab and added a container with some additional research kits. All of this is now landed on the Mun, the contract shows green ticks for Transport experiement and Satisfy all experiment conditions, but not for complete experiment. I did try to transfer the experiment into the lab, then run again lab time. Progress goes to 100% but it only seems to complete some other Experiements, as review data shows texts like "Research indicates that you did not go into space today." From looking at the description in BasicExperiments.cfg this should only come at KerbinSrfLanded, however I am 100% landed at the Mun East Crater ! Also I only ever get the Result from WBISpaceResearch experiment, never any message from WBIIceCreamResearch. What is actually needed to complete a experiment ?

Just recently I discovered that optimised gravity turns gather speeds only slightly higher than spaceplanes, so I wondered if a rocket with R.A.P.I.E.R.s would work and how efficient they are ? So by start of last week I did design a SSTO stage for a 36 payload, which happens to be a little overpowered complete return science lab to land on the mun. And after some tweaking on construction and flight engineer support.... it worked ! Going from 3 Vector to 1 Vector and 12 Rapier saved around 38% wet mass on the SSTO stage going down from ~210t to 130t . I never got too fancied about spaceplanes because for bigger payloads proper air balance is a time consuming exercise, but this is about as easy as designing a rocket once you know the dV requirements. The Rapiers do start in closed cycle to assist with rocket lift off, around 200 m/s I do switch them to air breathing mode, throttle later back the only Vector to save fuel. When rapiers get near their speed limit - still below the ceiling altitude for air breathing - everything is throttled back up and switched to closed cycle. And all piloted by MechJebs Gravity Turn So next step: Automate flight engineer tasks in MechJeb Oh and I installed some near future mod with bigger dual mode engines for needs with bigger SSTO.

For me it is all about drag: Bigger sizes have less surface per volume. Note that even sides do produce drag. So center core + 2x side ? Fine. But before going for center+3x side I usually switch to 2.5m. Actually at the next steps ( I am using SpaceY up to 10m ) a factor of 2 is enough to switch for next diameter.

Exactly And my first stages do land near KSC for maximizing funds, although after some successful landings on the runway I don't consider it fun enough to repeat. But the first time to land there: Unforgetable.

My SSTO descend retrograde with some control surfaces at both ends deployed and AoA of roughly -15°. PE at deorbit is arund 10km, deorbit point choosen so that Trajectories prediction is at or slightly east of KSC. For return capsules always try how hard and deep can I set PE without blowing up. Usually it is around 25km and I hardly use dedicated heatshields, but rather burn off any transfer stages and land with parachutes. Actually retrograde burns do help as well as kind of heat shield beyond reducing speed, so I am throttling up any remaining fuel once KER shows 80%+ temperature on my critical part. Just as Snark I do not care about landing spot for mission returns: whatever comes back is usually not worth enough to make a difference in credits and I do not have to get into LKO to time for KSC.

Thanks to SpaceY Extended my first stages are all SSTO without SRB. The first stage might include multiple tubes, but it would still stay until return from orbit in the same configuration.

Actually for every celestial body there is a function to get the surface altitude for any latitude and longitude, so the question is only how do you get it into Matlab ? MechJeb Landing function lets you pick a target on the map and then outputs the altitude as well, while KER has output for a perfect suicide burn.

Actually you might want to go back to launch and plan first: Date and direction of first transfer make huge differences. 900 m/s is not a lot to play when changing interplanetary trajectories. How about using Just enter Kerbin -> Eve -> Kerbin, your start day, some dV limit from orbit and then let it search and sort for fastest solution. If you do an aerobrake for Kerbin, around 1100 m/s dV and 200 days travel time are possible. Note the incliniation: Solutions are not always planar !

I did try a lot with a fork of Trajectories and Mechjeb to land at KSC runway. With few tries and fiddling with some parameters depending on the rocket, I get enough precission to actually hit my intended target +- 200m. However I start from Orbit and can use a savegame to adjust. You want to start from launchpad and hit a target that is only few times bigger than a rocket. This increases your task to get repeatable. My suggestion: get kOS and fully automate the flight. Then note the position where you are landing and place your drone ship there. Now use trajectories to fine tune the very final approach. It will be still hard work.