Booots

This is absolutely true. Exceptions are the program's way of saying something didn't go the way the program expected. NullReferenceException is the program's way of flagging that something it thought should exist doesn't, which makes complete sense with stock code being bent to display an orbit without a real vessel. Looking at the call stack, it isn't even possible to hide this message with a catch block since it's from a Unity/Stock call tree... Does it show up every frame? 1MB/s seems like a lot (I'm not sure if other users see that rate or not), but it's going to hard drive and not RAM so it's unlikely to crash KSP - just fill up your disk. :p

Hey all! I'm working on a new part for this for the first time in... years! Anyone with graphics experience able to help texture it?

Holy! Well done! I liked the post because I saw you'd had success drawing orbits. But after reading what you'd actually used it for makes me wish I could like the post multiple times! This is superb! Adding it to my 'must-have' list.

I've considered making that as a separate mod, but the problem of optimizing atmospheric ascent profiles for multistage launch vehicles is beyond me. From the research I've done, that seems to be at the cutting edge of academic papers (though I'm sure industry has some lovely and complicated code for it). Like, if I could make it work for KSP, I could publish a journal article about the algorithm. Tempting for the cred, but no... Sorry. I'll do some more reading on the current state of research and if I come across something I can just adapt for KSP instead of developing from scratch I'll reconsider. Thanks for the bug report! I've seen that error too, but I can't figure out how it's going out of bounds. In theory, though, the "Wind tunnel task faulted" message means that it's failed gracefully and shouldn't CTD but this mod is doing background work that Unity never expected so who knows... I'll look into that error and see if fixing it prevents CTDs.

Unfortunately no, this mod does not account for fuel burn and neither does it calculate burn time. Fortunately, it’s relatively easy to calculate burn time from Isp (you will have to make an assumption about whether to use vacuum or sea level). From that, the rocker equation, and some simple physics it’s pretty easy to calculate how high it’ll go. (I could link you the equations if you like but they’re all on Wikipedia and I encourage self-learning because it’s retained better) Now, those equations ignore drag and that’s one area where this mod can help. The ‘Velocity Curves’ tab will let you get your rocket’s drag coefficient by Mach number. Multiply that by the dynamic pressure and wing area (the sum of all your fins) and you’ll have everything you need to predict how high your rocket will actually go!

Haha, soon I hope! I made sure to check the ‘Add to CKAN’ box when I uploaded it to Space Dock.

Craft files are easiest (at least if they're stock) so I can recreate issues at will. It doesn't use the debug log for much since I don't want to spam at every frame but screenshots could help. It's interesting that you're seeing blades jump to too high of an angle. Are the blades 'regular' (do they emanate from the rotation axis and form a disc with zero deploy angle being flat in the disc)? The 'stuck' behaviour you describe could be what it does if it can't solve an equation - it will just leave the prop at the angle it was. It could also be that it's decided that that angle is optimal for high speed, which may not be the case for very high speeds since it doesn't account for blade drag in its decisions. And yes, I seem to have auto-mapped reverse thrust to brakes in the released version. That can be changed in the Actions menu in the SPH. And feathering overrules reverse thrust so you can feather the props until you're ready to takeoff. The blades stretching is out of scope for this mod. I have been considering another mod that will make propeller blades physics-less at high RPM and collect their thrust at the center but I want this mod to be a simple stock patch so people doing challenges can still use it.

Well, I tried to use my own in-development mod to try to win this but the fact is that you all are simply much better aircraft designers than I. I humbly release my creation in the hopes that it can help you beat the speed records and that I can be a part of it in that way. @fourfaGood luck, mate.

With apologies to the great movies starring Anna Kendricks. Ever get frustrated that your propeller aircraft don't seem to gain speed? Annoyed that mapping blade deploy angle to throttle can result in less thrust with more throttle? Wish you could just use the throttle to control the force of your propeller without finicking around? Well now you can! This mod will handle all of the details while you just fly. How to use: Add blades to any rotor. Make sure that they are aligned in the disc plane in their undeployed state and that increasing the deployment angle makes them take a bigger 'bite' of the air. Set them deployed. On the rotor hub, select which mode you want: Thrust: Keeps the blade at its maximum thrust angle. Throttle the motor's RPM or torque to control your thrust. Throttle: Makes the blade produce thrust proportional to the throttle setting. Set your motor to the desired RPM and a torque setting that will enable that. This is the default and probably easiest to fly with. Efficiency: Keeps the blade at its most efficient (Thrust/Torque) angle. Throttle the motor's torque to control your thrust. This mode is likely the least useful unless you're trying to build a maximum range craft and even then... Fly. For you extra 'Kerbal' types, the math is there to try to optimize weird, non-radial or conic propellers but I don't guarantee it will be able to optimize anything. The steps above are well tested but I can't predict everything you'll try. If something doesn't work, please let me know and send me the craft file. Also, a caveat on my promises of optimization: this optimizes the thrust of the propeller blade, not thrust-drag of the propeller blade. At high forward speeds, it might be a few fractions of a degree away from absolute perfection. I'm working on that. Reverse thrust is also roughly implemented, but isn't perfect yet. I'm still actively developing this but it's good enough to start. Downloads: GitHub: https://github.com/DBooots/Pitch-Perfect/releases SpaceDock: https://spacedock.info/mod/2616/Pitch Perfect License: MIT Dependency: Breaking Ground

CPU utilization going to 100% is normal - it’s doing a lot of math. The freezing is bizarre but I’d have to see a log file and/or the craft file to reproduce it.

Oh yes... Excuse me while I use the power of math to crush the competition before releasing my blade pitch control mod. Maybe this should get its own forum thread, but the automatic blade pitch controller is well underway. Your gut is absolutely correct - for the special case where the blade pitch axis is orthogonal to, and passes through the disc axis. It's really simple to figure out the inflow triangle (knowing forward velocity and angular velocity X distance) to figure out the relative inflow angle. Then if you know your max lift AoA (trick here is the lift curves in the CFG files are normal force, not lift force so take Cos(AoA) X Cn) you can just add that angle to the inflow angle to get your optimal deployment angle. The tricky part (and I have three pages of math to address it) is when people go full Kerbal and have swept blades or ?dihedral? blades or blades that are offset transversely from the motor's axis. But it turns out that there's an analytical solution even for that.* As long as the pitch axis actually allows for that AoA to be reached. But there's even an analytical solution to determine that! Since it actually just boils down to four dot products, a cross product, and solving the quadratic equation, it's actually a reasonable amount of calculation to do each frame. My proof-of-concept mod is working so I'm gonna have a go at this speed run thing. Between optimizing blade angles for thrust and using Wind Tunnel to optimize the rest of the plane, I feel like I have a decent shot. I am running into some weirdness with the stock helicopter blades - for some reason they aren't behaving the same way in my mod as normal props in forward or vertical configuration. It's made propeller craft much less frustrating to have the throttle map directly to how much forward thrust my prop is producing.

To check a specific expansion you’ll want the ExpansionsLoader static method IsExpansionInstalled. Expansions.ExpansionsLoader.IsExpansionInstalled(string name) The string to check is the same as the folder name in GameData/SquadExpansions. “MakingHistory” and “Serenity” (Breaking Ground). There are similar methods under that same class to check if any expansions are installed or to check a list if you need more than one.

New update is released! Propeller thrust and drag is accurately and intuitively shown. Forward and upward propeller forces count as thrust. Backward and downward propeller forces count as drag. Do the vector magnitudes not add up perfectly, maybe, but that's like a rounding error. It'll be fine! Propellers are simulated at the angle they are currently at in the editor. Optional optimization will come later. Enjoy testing it out while I take a break to update my other mods and maybe make a variable pitch propeller controller PartModule. Massive performance improvements! Propeller engine support! Not likely to crash your game anymore! *Propeller simulations not as fast as other simulation.

There's also the case where the blade angles are set too shallow and the blade actually makes negative thrust. Using a tick box might be possible, but would complicate the code. I'm leaning towards counting it as thrust, which I think is what most users would expect. I might try a clever trick to count the hub and spinners as drag separately from actual rotating parts.

New release is out. Thanks to @The-Grim-Sleeper for the pull request. I also took the opportunity to update the GUI to use the newer system for that sort of thing. The toggles to enable joints across robotic or KAS connections do disable themselves if the applicable mod or expansion isn't installed, so if you're not seeing them that could be why. The setting from the settings file are read and followed regardless, so if I've messed up checking for the mod or expansion there is a workaroun - but please let me know if the button isn't showing in some case when it should.

Alright! I've got rotors and props roughly working. I still need to do some testing to sort out the deployment direction (there's four different flags listed in the API so I have to figure out how they interact). Question for the users: should the output from rotating part groups (like rotors and props) be shown in the graphs as negative drag or as thrust? Pros/Cons as I see them are: The drag of the hub and spinner will be hidden if the total is counted as thrust. VS Lift/drag charts get broken if the force is counted as negative drag.

Hey! I haven't been the most active in the community recently because of IRL work, but I'm taking advantage of some time off over the holidays (Merry Christmas and Happy Holidays, btw!) to catch up on my mods. Wind Tunnel is my passion at the moment so it's getting a lot of (desperately needed) attention. Next is CommNet Manager and then I'll be over to ReCoupler. I see the pull request now and I'll incorporate it alongside some other updates to the settings menu. Cheers!

The CTDs are weird and occur randomly - they're a result of something one of my threads is doing interfering with the Unity game engine. I've resolved them by changing how I access certain information so that I stop doing things the game engine doesn't allow for. Whether a CTD occurs or not shouldn't be a function of accumulating anything but might be made better or worse by an increased or decreased CPU load. But don't worry too much about fixing them on your end, I'll have a new version out soon that will eliminate them completely. For propellers, I'm going to start by just locking them at the pitch angle they're set to in the editor. Once I finish the thrust-optimization math I'll put out another update to include that.

Oh. Oh... See, I was just going to rotate each rotating sub-component at its max RPM as set in the part menu. That sort of clever torque-splitting on a freewheeling one wouldn't propagate back upwards, and making it so would require a complete re-write and much more expensive computations. There are compatible contra-rotating setups that can be used with this mod, but that won't be one of them. I think basic propeller/rotor support is the most I'll be able to do. If I can figure out the vector math, I'll have it used optimized blade pitch angles, though. I need a bigger whiteboard by my computer...

Thanks! I've accepted the pull request. Everything compiles well against KSP 1.11 so I'll do a bit more testing later today and put out an updated release. Is there anything else you'd like added, or is the CNMHome setter all?

Alright, thanks for confirming the crashes for me. I guess this beta still needs debugging. Ugh, I hate chasing down weird bugs. I haven't built any successful propeller craft myself yet. For these contra-rotating setups, do you mount the second hub to the front of the first or you do mount it to the same part as the first hub and then offset it to the front? I.e. do the two rotating hubs have the same parent or is one a parent to the second? If the second hub is a child of the first, do you have to make sure to de-rate the max RPM of the first to half the RPM of the second? These questions all feed into my plan for how to recognize scenarios where we can take the shortcut. The rule was going to be if the rotor hub had no children except for control surfaces (which is how the game classifies propeller blades) and whitelisted parts (nose cones), it would apply the maximum CL AoA to the lifting surfaces. Otherwise it would use the angle configuration set in the editor. We're also making an implicit assumption that the effect of the inflow vector is averaged out across various blades - an assumption that should hold for symmetrical hubs (any N-symmetry works). I'm sure there are edge cases and abuses but honestly, if you're gaming the prediction algorithm that's your own loss. :p Yeah, for top speed and max acceleration you want max -ve drag/max thrust. But if you're fuel-conscious you may want to reduce the torque of your motor and you'd then want best thrust/torque. For a fixed blade length (God help you if you're using extending servos within your blade setup), this equates to Thrust/angular component of drag which I'm intending to approximate as just Thrust/Drag - I haven't done the math yet on how accurate that approximation is for high forward speeds. How fast are you really intending to get on propeller power? Have you seriously built a propeller-powered spaceplane?! If so, can I see a picture of this wacky thing?

Sometimes I'm amazed they even work in real life! And I did a master's in propeller aerodynamics! I had the luxury of disregarding all the linkages that actually make variable pitch possible in the real world - getting mechanical power to a rotating component at several tens of hundreds of RPM... craziness! If we hand-waved actually adjusting the prop angle of incidence, I wouldn't have to iteratively find the optimal angle. I could just grab the peak from the propeller's lift curve and use that as the Coefficient of Lift and use the same point on the drag curve. This won't give you the most efficient prop disc, but it will maximize thrust. I could add an option for best Thrust/power instead of best Thrust, of course. As I write this, I'm liking this option more and more. Maximizing prop thrust will also work for the rotor case, which is good because I try to always program for the general case. On that note, I've been building this so far in a construct that would theoretically support nested rotor components (spinning things on top of spinning things) because... Kerbal. If we go this route of just picking the best thrust, I'd apply that only to the lowest level of nesting. There also isn't an easy way of making sure the chosen prop angle is actually within the range of the prop's motion. Optimal prop angle is actually only a function of speed and RPM (assuming roughly perpendicular airflow), so I could add an output to say the ideal angle. Actually... *checks if anyone has already made a lightweight prop control mod* *not quite* *has new plans for tomorrow night - make a mod that will optimize propeller blade pitch for thrust or efficiency* Fun things to think about! Programming is actually paused for a few days because I got really mad at KSP. For some reason, I'm experiencing weird crashes to desktop with no error logging when I use this mod on other craft besides my go-to test craft. Has anyone else experienced a CTD, or is it just me? I even reverted to the version I put on GitHub which seemed stable and reinstalled the game but I'm still having crashes. So yeah, that's gonna be tricky to solve.

How have I only found this now?! I love it and it’s on my must-have mods list. Until I came across this I had been percolating ideas on how to make a mod like this but you’ve made it more elegantly than I had even considered. Brilliant!

Wow, propellers in KSP are hard. Not to simulate (that's just a matter of creating a rotating reference frame), but to design! Getting the right blade pitch for a given speed and RPM is a fine balancing act. For the purposes of wind tunnel, though, it's basically impossible to adjust the blade pitch across the flight envelope (I could add a module to optimize that, but it would make the rest run really slow). @Linkageless do your propeller planes use variable pitch? Any suggestions on how to account for that?

Anyone here have experience with the Breaking Ground robotic servo PartModules? I'm trying to find the rotation axis (both direction and location) so I can predict the motion of its child parts. In the API I see ConfigurableJoint servoJoint but it's a protected attribute and so I won't be able to access it without sketchy reflection calls. Next would be 'servoTransformName', 'jointParentName', or 'baseTransformName' and 'mainAxis'. These seem promising, but I'm just wondering if anyone has any experience they could share before I dive down the rabbit hole. Thanks!