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!

I don't seem to have the original pictures, but I do have the Matlab script saved, thankfully. I've also contacted Imgur Support to see if they can say what went wrong on the old album. Images are recovered, and the original post has been fixed.

Maybe? I'll see if I have the original pictures saved. Worst case scenario I brush off Matlab and try to generate them again. Sorry mate, I appreciate the feedback but I found that the original sizes are a little... unbalanced? The small tank has 3x the density of Karborundum than the others and they're all over the place in metrics like tank volume/part volume, cost/tank volume, and mass/surface area. I've gone ahead and made tanks that are more compatible with the stock sizes and that have more consistent metrics. On the plus side, the tank volumes have all increased for a given diameter tank and I've made them cost a little less than before. Call it an incentive to switch. If discounts and increased volumes aren't enough, maybe some sweet eye candy will win you over. https://imgur.com/a/oV7IpP3 I've kept the original signage on all of the tanks and the background white/slight beige tank color is the same as the legacy ones to have a bit of throwback. The toroidal shape makes Karborundum feel more like a dangerous resource and I've gone with blue foil so that they stand out a little from other resources. I've also tried to make it feel like the level of refinement has increased with the larger diameter tanks. What do ya'll think?

Interesting! Unfortunately, I’m not able to do much without more information. Can you post a link to your log file?

Also, I'm finally re-doing the tank parts. Should the new ones be the same dimensions as the old ones or should they conform to standard tank heights?

Introducing the new line of ESLD Lens Beacons! (And version 1.3.0 of this mod! Download links in the OP) Lens Beacons shorten the effective distance by focusing the superluminal pathways. Line up your sending and receiving beacons with a lens beacon and get up to 96% off the effective distance of your jump, cutting Karborundum costs drastically! Link to Imgur album: https://imgur.com/a/6OtQBwW How to use: You'll notice a large number of fuel cells on the examples. There's a reason for that - these things run off Electric Charge so make sure you have plenty. There's also a maximum gravitational field limit for these, similar to the regular beacons. Each lens type has a specific directivity and gain pattern. You might even come across side lobes. See the description in the Editor window or below. Use cases: If you're really short on Karborundum. If you're playing with multiple solar systems. If you want to optimize your beacon network and do fun orbital arrangements. There's two ways of setting these up: Have the lens and a beacon in a synchronized orbit with one leading the other. This will let your lens' beam sweep across the sky throughout the orbit and you can time your jump for max effect. The jump confirmation window has a readout to help show the lens gain. Have the lens orbiting much lower than the sending beacon (or even orbiting the beacon's body's parent) and then time the jump for the right point in the beacon's orbit. LS-12 "Hoop" This is of the 'Opposing' type, which means it goes between the sending and receiving beacons. LS-25 "Lighthouse" This is a 'Bidirectional' lens, which means it can go either between the sending and receiving beacons or behind the sending beacon. (Its performance is slightly better with the sending beacon between it and the receiving beacon.) LS-350 This is of the 'Conjunction' type, which means that the sending beacon must be between the lens and the receiving beacon.

Model - Check. Particle Effects - Check. Emissives - Check. Normals - Mostly check. Just a few more tweaks to the code and we're good to go!

Thanks for doing the testing on this! You seem to be in favour of only ReCoupling parts once the user clicks ‘Apply’ or ‘Reset’; is that the consensus? I could imagine a problematic case where a vessel makes heavy use of robotics and a user has deleted a bunch of ReCoupler links; they would have to go through and delete them all again after EVA constructing a part (subject to ReCoupler). This is a pretty edge case, but could cause someone a headache. Should I tap into OnEVAConstructionModePartAttached to automatically do the ReCoupler thing? For the Kraken strike, I’ll see if I can intercept the beast in OnEVAConstructionModePartDetached to quickly break ReCoupler links to that part. I have no idea if the frame rate is normal or not (I actually haven’t played KSP since that update so I’ve never personally used the EVA construction). At this point I doubt ReCoupler would be at fault because it doesn’t do anything on a per-frame basis, but I’ll make a note to confirm I’m not accidentally tying into too many events or Coroutines and causing slowdown there.

This is actually a feature I’ve been meaning to test in ReCoupler: whether it’s existing logic works for the new in-flight construction. It might not, but that’s definitely something ReCoupler should do.

Oh I'm sorry, I didn't read the call tree on that one. My bad. More fun with environment manipulation!

Do you know what field it's looking for? I wonder if you could make add a pair of LateUpdate methods and somehow sandwich OrbitTargeter to set the field to something and then clear it without breaking anything... But if it only shows up once per node, honestly I'd leave it (maybe add a log statement earlier in the same frame telling users that it's okay). Heck, ReCoupler throws an exception every launch but I'm not going to spend the hours tracking it down. :p If it's just Debug.Log, consider wrapping it in an #ifdef DEBUG/#endif to remove it from the shipped version and you're good to go!