Booots

Wait, does it not work in 1.12? I didn't realize some breaking change had happened - can you confirm? That's something I could maybe look into some weekend with free time.

Maybe eventually. It was something of a proof-of-concept and I ran into an issue getting the blade angle optimization to run at speed. I'm in the middle of a really intensive year of work-sponsored school, so I probably won't work on this until next fall at the earliest.

Hey there! Sorry for the very slow reply. Life has been extremely busy since March (and will be for the next year or so). From what I remember, this mod takes all the atmospheric data from the celestial bodies stored in your game, so it likely will work. Let me know if you've run into any issues!

That was literally the first thing I tried to do in KSP 2 to see if I’d need to re-make my mod for the new edition. I’ve already submitted feedback to the Devs outlining how the ReCoupler mod does it, so hopefully it’ll be part of the default KSP 2 game eventually!

Sadly, no. I put a lot of time into trying to make it work, but it's just not working. And with the upcoming release of KSP 2 (get hyped!) I plan on recreating this mod in KSP 2 and leaving the KSP 1 version in its current state. Aha, yes. It assumes you have sufficient intake air. Intake air consumption rates was just one of those things that I never bothered to figure out. I presumed that spaceplane designers would add intakes as necessary for their design and so I only deal with thrust and aerodynamics.

Thanks @taniwha! That seems like a good call, though it might lead to people finally noticing one of the edge case bugs that I never got around to fixing... :p I've issued the update including that change. Sorry it took me a while to get to it - I was off getting married.

I feel like I owe you an apology @paulscoletta, for leaving you on read. I think I found the root of your problem 10 days ago but only now got around to writing a post. What I believe is happening is that there are two human-identical TMPro types at play that are not computer-identical. The KSP devs baked the TMP code into the Assembly-CSharp.dll and so inside of Assembly-CSharp.dll, there is one set of TMP types (TMP_Text, TMP_InputField, etc.). Meanwhile, in the Unity editor, you've been using another set of TMP types from the TextMeshPro-2017... .dll. While these types are identical from a source code and signature perspective, because they're defined in two separate assemblies, they're not the same to the computer. This is why you have needed to add the TextMeshPro DLL to your GameData folder to get your Unity assembly to load in KSP - the TMP types its looking for aren't the ones in Assembly-CSharp. The same goes for the TMP_Text elements throwing NullRefs - all the font assets they're looking for are font assets defined by the TextMeshPro DLL, and not the font assets loaded by KSP that are the Assembly-CSharp.dll versions. So how to fix this? That's what I'm working on right now too for the revamp to my Kerbal Wind Tunnel UI... I managed to get the Unity editor to let me include Assembly-CSharp.dll in my Unity project so that I only need one assembly for my mod. (I feel like I shouldn't bury this tip, but you can make careful use of 'AssemblyDefinition' assets to force Unity not to make its own 'Assembly-CSharp.dll' file and then it doesn't complain about loading KSP's - as long as you also import other .dll files that it needs) This also meant that I had to remove the TextMeshPro dll so that I didn't have conflicting type definitions. Fine, done. But then all of my TMP elements in my UI refused to show their text because KSP's startup sequence hadn't loaded any fonts. I think the underlying text data is still there, it's just that the font is null. KSP also only bundles the distribution/player methods for TMP, so a lot of the editor functionality was broken. I've fallen back on the method DMagic mentioned in their tutorial and have replaced all my TMP elements with standard Unity elements and have created a helper type that can change from Unity UI elements to TMP elements. It also acts as a middleman for other script references so I can ask it to change text values or act on input from input fields without having to know in my other scripts whether I'm in Unity UI mode or TMP mode. But this is still in testing. Hopefully this helps your troubleshooting, and I'd be happy to collaborate on finding clever ways forward. TMP is far superior to pixelated Unity UI text.

I agree that KSP 2 should support circular structures natively. But if it doesn’t, I’ll be porting ReCoupler over pretty much immediately.

I suppose I should have phrased my question more as a function of L/D than AoA. As @CBase mentioned, the Shuttle kept an AoA that would offer some lift and thermal protection and then scaled lift by banking to adjust the lift component - effectively varying L/D. @FleshJeb, thanks for the free advertising! I'm trying to make a kOS script to finely control landing latitude once reentry interface has started. I need to know what range of AoA (read L/D) I can use for control before further input in that direction becomes counterproductive. I used Wind Tunnel to get lift and drag polars at various supersonic speeds. I agree, subsonic regime is likely a rounding error - and it follows normal gliding flight assumptions. @CBase brings up the 'intuitive' approach of decreasing AoA to go further but increasing to shorten. The Shuttle did the opposite, though, increasing lift to go further with drag staying constant. That contradiction is why I'm so taken with this question. Why is the technique that was used in the real world not working for my control loop in Kerbal? Adding lift through AoA increases drag immediately, but decreases drag later because you stay in thinner atmo longer. Lowering lift through AoA decreases drag in the moment but you hit thicker air sooner. Can we figure out at what L/D these effects cancel out (either local maximum or local minimum), and is that L/D a function of planet radius, atmospheric characteristics, or otherwise? I'm working on a Simulink model of entry/descent to start to characterize this, but it's going to have to be brute force, I think. I'm using the assumptions from that NASA paper I linked: cylindrical planet, stationary (ground-relative) atmosphere, instantaneous vessel pitch changes, point mass vessel. @FleshJeb, could I get a copy of your atmo/temp models, please?

You're not disappointing because I'm not looking for a simple answer. Like I said, I'm trying to simplify the maths (where possible). The first part is taken care of - I've already got a method for characterizing Lift and Drag at any (reasonable) AoA through the range of speeds that will be encountered. I'm also ignoring the heating constraint and structural constraints for now because KSP's parts have such high heat tolerances and rigidity. I can adjust afterwards if vessels start exploding. I'm also not necessarily looking to maximize downrange distance - rather, I want to know what AoA range is productive to use in a control loop to bring the impact point to the desired landing location (though this would lead to maximizing downrange distance at its limit). Since it's not looking like there will be an analytical answer, it's time to start setting up a MATLAB script! Any suggestions for simplifications and assumptions that might help make the computation simpler/faster?

Sure, I guess. This is all feeding back into flying a spaceplane in-game, though I suppose like any KSP physics is generalizable to the real world as well.

To clarify up front, I'm looking for math help - not 'rules of thumb' or best practices. As a spaceplane enters the atmosphere, it's got three forces acting on it: gravity, lift, and drag. For the purposes of this discussion, I've got a well-developed model that describes drag as a function of lift, and lift as a function of angle of attack (AoA) (accounting for mach number in both cases). This theoretically means that the spaceplane's downrange distance is a function solely of AoA (assuming AoA is constant throughout the entry if need be). It's not going to be a clean function, but it is a function of one variable. I'm only interested in the regime where the flight path is pseudo-ballistic (i.e. the vessel is not 'flying' per se). This question centers around the effects before the atmosphere is significant enough to treat the vessel as a simple glider (say, h > atm_height / 2). Increasing AoA increases both lift and drag. More lift means the vessel's descent angle shallows and it postpones hitting thicker atmosphere, increasing downrange distance. More lift means more drag, though, which slows the vessel and decreases downrange distance. The question is, what is/are the critical AoA(s) where these two effects cancel? I believe there will be two roots, one where drag is minimized (low AoA) and one where lift is maximized (higher AoA). From my experiments, L/D(max) is not ideal for best range in early stages of entry - and this makes sense since it doesn't account for the delayed effect of prolonging the rarified atmosphere. I've tried doing the calculus of looking at a snapshot of a purely ballistic trajectory and treating lift and drag as changing the launch angle and speed, but this seems to be a dead end (at least to my sleepy brain). Before I start brute forcing this through a differential equation solver, are there any suggestions to how to find the optimum AoA(s) for downrange distance in a rarified atmosphere? Potential reading list: https://ntrs.nasa.gov/api/citations/19720022195/downloads/19720022195.pdf

No worries at all, as the mod is still supported under this thread (even if my replies are a little slow... sorry). I haven't tested craft sharing, but nothing this mod does should break craft sharing. I exploit a subtle quirk in how KSP processes craft when saving them to save all the data this mod needs in a way that won't affect other mods or users without this mod. It also means that it's perfectly safe to remove this mod at any time (though I don't know why anyone would want to ).

Hey @DerGolgo, did you ever get this resolved? If you’re still having problems, could you post your log file?

Interesting! I’ll do some digging this weekend and try to figure out the problem. I haven’t opened up the code for ReCoupler in forever - this should be fun!