Booots

Oh no! Sorry to hear that you've run into a bug. I'll find some time to check it all on a clean install on my end in the next week or two.

Hey there! I just moved and started a new job, but as I get back into modding KSP again I like this idea. I once thought about implementing #1 but realized that I couldn't do this efficiently because the matrix of points to evaluate becomes 3-dimensional instead of two (sweeping AoA for each speed/altitude combo), which makes the computation take a lot longer. But! Around six months ago I figured out a way to rewrite how this mod does the aerodynamics calculations in a way that would sacrifice a small amount of accuracy for a huge boost in speed. The problem is that I needed to do a bunch more coding from the ground up and my first attempt at it (which was all I had time for at the time) failed spectacularly with highly erroneous results. But now that I should have a bit more free time, I aim to add both of these plots (actually combined as one plot where the color corresponds to the AoA range between the neutrally stable angles) and a bunch more data for glide vehicles.

It does not, sorry. I tried really hard to get it to work, but FAR's internal code just doesn't support it.

I'm sorry it's not working for you. This mod was more of a tech demonstration/proof-of-concept. I haven't had time for modding in the last year+ (moving internationally and then learning to be a real-life test pilot) so I wasn't able to develop it any further. I had also started moving away from modding for KSP 1 thinking that KSP 2 was coming soon, but I may need to reassess that idea. If all the rumours turn out to be true, I'll be back to modding for KSP 1 again once my course finishes and I'll try to pick this up again. In the meantime, anyone is free to try to improve the functionality of this.

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.