bac9

I have no idea what is the objective of the stock drag parameter since stock as a whole is not really rooted in reality, but FAR accepts no drag parameter as an input (only semispan, mean aerodynamic chord, mid-chord sweep and taper ratio) so my wings don't set it directly when you use a proper model. As far as I understand, FAR might actually take the thickness into account for wing interaction, because thicker wing naturally occludes more stuff, and it might take it into account for drag if something like frontal snapshot is taken to determine the craft shape. Just not for lift. - - - Updated - - - There are buttons on the bottom of the new menu, appearing contextually. If, for example, you have a wing that has a parent part that is also a procedural wing, a "Match shape" button appears that tweaks it's root measurements to match the tip of the parent. You also have "Match materials" button for any procedural parts attached to any other procedural parts.

Makes sense. I'll modify the volume calculation used for fuel-related parts to exclude any edge widths then and will keep the centerpiece at 70% use then.

I highly doubt it's the case with very thick wings, it would leave huge volume unused. But thanks, I'll look into it more.

Thickness is cosmetic in terms of aerodynamics, since there is no way to actually use real wing profiles without disastrous results - FAR is using one of the average profiles from NASA, I think, but it contributes to volume correctly, so it's not cosmetic in terms of fuel tank limits. It would work but I'd prefer not to add it there to avoid cluttering the interface. There is no point in doing that, I think, in most of the possible cases where logging might be necessary I'd prefer to have it enabled right on the first load of the KSC scene and not afterwards, god know when from within the flight scene.

When you select edge type 1, calculated volume is correctly adjusted to remove edge width no matter it's value, so it shouldn't be an issue. It was not always the case, but it was fixed few versions ago. Volume is also correctly adjusted to any edge width setting, be it 4cm, 40cm or 1m and any difference between root/tip widths of the edges.

This is whole volume including edges, yes, so if the wing has the volume of 3.25 cubic meters, only 2.275 cubic meters are available to fuel, which in case of stock equals around 305 units of liquid fuel. 70% is a pretty high estimate too, some people suggested 50% is closer to reality, so I think the current multiplier is pretty fair.

Version 0.23 RealFuels support added, wings switch from inbuilt fuel switching code to RealFuel tweakables automatically upon detecting it installed Fixed the alternative UI getting stuck in the timeout mode upon after you exit and reenter the editor scene Added a button to the KSP editor appbar allowing you to close the alternative UI window and reopen it without mouseover+J (the button appears and disappears automatically whenever a procedural part is present in a scene) Added a configuration menu to the KSC scene, accessible through the appbar button. It allows you to enable one of 12 logging modes (all disabled by default) and might come in handy later when I might ask some of you to reproduce an issue with a certain logging mode enabled, sending me the resulting log Fixed fuel per volume multiplier - previously you were able to use the total internal volume of a wing for fuel, which is fixed now, with only reasonably realistic 70% of it available Various minor fixes and optimizations - - - Updated - - - It should be there, as a third from the last value with aero stat readout enabled in the stock context menu. Use the alternative UI, I don't think it's possible to entirely stop the stock context menu from doing that. I'm considering removing all tweakable options but fuel from it altogether, leaving only alternative UI for shape and material configuration. Well, Cl is taken into account, which in turn means aspect ratio and surface area are taken into account, which in turn means semispan and MAC are taken into account for joint torque/breaking force values. No idea how effective the formula is, though, it's pretty much the same as one in pWings: aeroStatSemispan = (double) sharedBaseLength; aeroStatMeanAerodynamicChord = (double) (sharedWidthTipSum + sharedWidthRootSum) / 2.0; ... aeroStatSurfaceArea = aeroStatMeanAerodynamicChord * aeroStatSemispan; aeroStatAspectRatio = 2.0f * aeroStatSemispan / aeroStatMeanAerodynamicChord; ... aeroStatAspectRatioSweepScale = MathD.Pow (aeroStatAspectRatio / MathD.Cos (MathD.Deg2Rad * aeroStatMidChordSweep), 2.0f) + 4.0f; aeroStatAspectRatioSweepScale = 2.0f + MathD.Sqrt (aeroStatAspectRatioSweepScale); aeroStatAspectRatioSweepScale = (2.0f * MathD.PI) / aeroStatAspectRatioSweepScale * aeroStatAspectRatio; ... aeroStatCl = aeroConstLiftFudgeNumber * aeroStatSurfaceArea * aeroStatAspectRatioSweepScale; aeroStatConnectionForce = MathD.Round (MathD.Clamp (MathD.Sqrt (aeroStatCl + aeroStatClChildren) * (double) aeroConstConnectionFactor, (double) aeroConstConnectionMinimum, double.MaxValue)); ... part.breakingForce = Mathf.Round ((float) aeroStatConnectionForce); part.breakingTorque = Mathf.Round ((float) aeroStatConnectionForce); Where constants (provided by Taverius long time ago, I think) are: float aeroConstLiftFudgeNumber = 0.0775f; float aeroConstConnectionFactor = 150f; float aeroConstConnectionMinimum = 50f;

I'm aware of the issue, already noted it around five versions ago. I'm not planning anything like that at the moment, sorry.

Version 0.22 Control surface edge width limits no longer reset to 0-0 instead of correct 0.24-1 (rogue Vector2 was used instead of Vector4 at a certain point, losing those limits due to absence of .z and .w values) Notes: Resource displays have to trigger stock context menu redraw to update themselves after wing volume is changed, which makes it impossible to continuously drag stock tweakable sliders on wings with fuel tanks - only single clicks will work. Either use my alternative menu, or switch the wing to STR mode for the duration of slider tweaking if that irks you. I don't have a slightest idea whether wing joints correctly support the added resource mass, I'll look into that later

Nope, craft files are not necessary, just trying to figure what's causing wings to bend in some setups.

Thanks, I'll look into the edge issue. Meanwhile the next big thing I'd like to tackle is improper connection strength and flexibility between wings. I'll need some testing results to work with - please test modular wings (wings created by stacking several parts together) with and without Kerbal Joint Reinforcement and with and without FAR. In case of FAR, test whether FAR mass/strength slider is capable of alleviating the issue. Do not use any fuel tanks for that testing for now, I'd like to figure out why lightweight empty wings can still bend too much under lift.

Version 0.21 Implemented fuel switching based on code by Andreas Aakvik Gogstad (Snjo): You can use the button in both tweakable and alternative menu to scroll through four possible internal configurations of a wing: empty structure (STR), liquid fuel (LF), liquid fuel with oxidizer (LFO) and monopropellant (RCS). As you alter the shape of a wing and change it's internal volume, amount of fuel within the wing is altered accordingly. Fixed some style and formatting issues of the alternative menu Fixed incorrect trailing edge width limits on control surfaces Added opt-in update notifications supported by MiniAVC Notes: Resource displays have to trigger stock context menu redraw to update themselves after wing volume is changed, which makes it impossible to continuously drag stock tweakable sliders on wings with fuel tanks - only single clicks will work. Either use my alternative menu, or switch the wing to STR mode for the duration of slider tweaking if that irks you. I don't have a slightest idea whether wing joints correctly support the added resource mass, I'll look into that later

You can already match width and other properties to parent wings through my menu. Actually shifting the attachment point is another thing, though, which I'm unwilling to do since it has potential to break joints and so on. That sort of thing should be left to Infernal Robotics, rest of the mods usually steer very clear from touching attachment joints.

That's the edge of the frame mesh used as a border in collision generation. You should not be able to see it because you should not actually be able to decrease the edge width on a control surface below 0.24 (on your screenshot it seems to be zero). I'll fix it in the next version.

Version 0.20 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads The alternative UI height no longer shifts during slider editing, tooltip label height is now locked, tooltip text adjusted to always take two lines The description of the last edited property is always correct now, jumps to improper descriptions eliminated Editing mode button changed to J to prevent conflict with Editor Extensions hotkeys It is now possible to force the part you are editing to match the shape (parent tip width becomes child root width, parent tip thickness becomes child root thickness and so on) It is now possible to force the part you are editing to match the surface material settings of a parent Control surface offset settings can now assume a wider range of values, allowing proper setup of control surfaces on high-sweep trailing edges

I feel like every single hotkey ever is used by everything, this is third time I have to change it. What is the one that's not used in any other mod and is reasonably close to the center of keyboard?

There are no real CPU costs in using 4 wings instead of two or 16 instead of 4, FAR being a CPU hog is a myth. No real difference in stock either. There is no way to dynamically limit the offset, so raising the upper limit to, say, 16 meters will allow completely ridiculous low-length wings with angles near 89 degrees with awful texture distortion. I'll investigate it later, but for the meantime +-8 meters seems like a good choice to me - you can always stack multiple wings for more sweep.

@Van Disaster Why not use multiple wings in a sequence? You can get any sweep you want that way. There is no real need to always use one part per wing. As about inheriting parent properties, I'm looking into it.

Version 0.19 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Leading and trailing edge width is no longer taken into account when type 1 (flat) edge is selected Control surface main body width lower limit is now set to 0.125 (I'll look into making it lower in the future, but at the moment I have to snap it to the increment and it can't go to 0 without breaking geometry)

There is no API for existing gizmos so it's only possible if I implement them from scratch with will require far more time than I can spend on this mod. So nope, not going to happen anytime soon, unfortunately.

The approach I'm using is different from KerbPaint in that it's not reliant on material properties, which means that parts with different colors and textures are not in fact breaking batching, increasing drawcalls, or rendered separately. Performance impact is pretty similar to non-colored single texture wings from stock no matter how much configurations you use in your craft. You can also split insides of my parts into any number of independent areas with their own texture and color settings, because those properties are delivered into the shader through vertices and not through material properties. Here is a simple illustration of what I do to four vertices of a top wing surface: Grayscale layers packed into RGB: Color mask for those layers: Theoretically, it's possible to make some sort of KerbPaint 2 using my approach, but I don't think I'll have the time to do that anytime soon.

KJR ignores my wings just like it ignores pWings, I think, which might be the reason they are too wobbly.

Yeah I'm aware of this, mentioned it in 0.17 notes. Something not immediately obvious is going on with the tooltip update even through tooltip header is always updated correctly.

Version 0.18 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Fixed symmetry counterparts not updating properly _______________________________________ Ah, figures. Though I don't wait for the game to load, I always switch to other windows - but I never has this problem. Maybe you're not using Active Texture Management and it's a problem specific to stock texture loader?

Try the new version of the .dll I just uploaded to the repo. https://bitbucket.org/bac9/b9_aerospace_plugins/src/75dd0083fcda20d5a83717dc45e6dd75178dd8dd/GameData/B9_Aerospace/Plugins/B9_Aerospace_WingStuff.dll?at=master