Panel Flags are implemented with hard-coded drag cubes, not config editable, and with excessive drag.
HB-Stratos opened this issue · 20 comments
ISSUE
The Flags in KSP were a rather late addition, especially the thick Panel Type Flags. They appear to not be implemented very well and have excessive Drag.
I have tried to write a MM patch to reduce their drag, but it appears that due to the variant and size switching, the drag cubes appear to be hard coded and cannot be modified as they simply do not exist within the config.
PROPOSED CHANGE
I suggest the hard-coding to be removed and to instead be moved into a proper config for the part that can be directly addressed with a MM patch. With that players can reduce the drag of Panel Flags, as this drag appears to be excessive. This most likely has to be done through a MM patch that runs as :FIRST in MM as the mod most likely doesn't want to directly modify files in the Squad/Parts folder.
Another way this could be done would be to mark the excessive drag as a bug and reduce their drag in general through KSPCF, though this may not be in the spirit of the mod.
ADDITIONAL INFORMATION
Drop Test with Flag
Terminal Velocity: 106.2 m/s, Drag: 30.49
Drop Test with Wing (that is slightly bigger than the flag)
Terminal velocity: 138.3 m/s, Drag: 25.86
Result: a large Panel Flag has more Drag than a Type D Wing Connector, while the wing connector is slightly larger than the flag. Calculated by speed difference (not drag difference as speeds were not equal), Panel Flags have 30% more Drag than Wings.
This is a particular issue for flag-heavy creations within the game, as they experience a lot of drag and therefore loss of performance.
Example:
My Concorde, built mostly from thin flags, which have no drag, but also required some thick flags.
The one, single small 2.5m flag acting as the small door for the forward landing gear is producing a drag line over half the length of the aircraft long (that is 61m long), and that at a speed of only ~130 m/s
Concorde is unable to go beyond 200m/s ASL despite four Panthers, each on 300% thrust, providing a total of 1550kN of Thrust, and a TWR of 2.72.
MY ATTEMPTED MM PATCH
// I tried about everything I could think of to reduce the drag of the panels, nothing had any effect on the drag.
@PART[flagPart*]
{
@maximum_drag = 0.0001
@PhysicsSignificance = 0
@dragModelType = default
dragModifier = 0.01
dragCoeff = 0.001
dragCubeName = none
//dragAtMaxAoA = 0.001
//dragAtMinAoA = 0.0001
@MODULE[ModulePartVariants]
{
@useMultipleDragCubes = true
@VARIANT[*Panel]
{
//@sizeGroup = nonStructural
//@attachRules = 0,1,0,0,1
dragModifier = 0.01
dragCoeff = 0.001
maximum_drag = 0.0001
dragCubeName = none
//dragAtMaxAoA = 0.001
//dragAtMinAoA = 0.0001
}
}
@MODULE[FlagDecalBackground]
{
@MESH[*]
{
@indexOffset = 0
PhysicsSignificance = 1
dragModelType = default
@mass = 0
dragModifier = 0.01
dragCoeff = 0.001
maximum_drag = 0.0001
dragCubeName = none
//dragAtMaxAoA = 0.001
//dragAtMinAoA = 0.0001
}
}
}
The flags don't have any drag in stock because they are set as physicless in the stock configs :
PhysicsSignificance = 1
Your patch actually change that (@PhysicsSignificance = 0), causing the flags to be physics-enabled, and in turn causing them to induce drag.
Without your patch, you will notice that the aero debug data in the PAW doesn't even show up for those parts.
And to be clear, there is nothing hardcoded about flags. If you want to make them physic enabled and change their drag characteristics, you can. But "trying about everything you could think of" won't do any good, especially if you don't understand what the values you are setting are doing.
The dragModifier and dragCoeff keys don't even exist,
The maximum_drag key only applies when dragModelType is set to SPHERICAL, CYLINDRICAL or CONIC.
Also, dragModelType = default will cause the part to use drag cubes. If you want to disable drag altogether, you need to set it to NONE or OVERRIDE.
Edit : Actually, just re-read you, I'm not sure we are talking about the same parts. I have no idea what the "thick" flag parts you are talking about are.
@gotmachine I am not talking about normal, thin flags, but their thick, panel variant you can switch to in the part variations of the flag. All my research and testing screenshots were done without my patch in place.
I did in fact try drag model type none and physics significance zero, which is the default for the config of the flag. It does nothing. Only override I have not tried.
No matter what I set physics significance and drag model type to, the thin flags always have no drag, while the thick flags always have their insane drag.
According to the part config there is nothing that tells the thick flags to be draggy at all, but yet they are. That leads me to believe that this is hard-coded.
All values I tried to reduce drag in the patch are from some other config (did a grep over all parts). Maybe I used it in the wrong place, but I kinda ran out of ideas how to get the darn drag to go down. The only thing that changes something is setting useMultipleDragCubes to true, but that just adds more drag cubes and doesn't change anything about the actual drag of the part.
Please, try it yourself in game. Create my test vessel with a full ore tank, probe core and thick flag. You will see it acts like in my screenshot, being almost as draggy as a parachute, and more draggy than a wing. And look at the config for the flag part. There is nothing specifying that they should even have drag at all in the first place.
Regarding your edit directly: Thick Flags, otherwise known as Panel Flags in Game are a part that was introduced rather late, in an update after the flag was added. You can find it as the last three options in the part variants for the flag.
I need to use them as thin flags look very bad as structural parts when you can see their side, and because there's a rendering glitch with scatterer, where all scatterer screen space effects render above flags if a flag part either has a transparent flag png on it or if a thin flag is viewed from behind.
My Concorde originally used a completely transparent PNG to only get the background color of the flag to use for structural parts, but that causes the plane to go invisible over the scatterer ocean. So the Concorde uses flags that have the exact texture the flag has by default, but as a non-transparent flag png. That fixes the rendering, unless a flag is viewed from the backside.
Okay, thanks for the clarification, and sorry for having being a bit blunt.
Indeed, those thick variants are physics-enabled. The rationale is likely that they can be surface-attached to, which require them to be physics-enabled.
The configuration switch that cause the thick variants to be physics enbled is in the FlagDecalBackground module, it's the indexOffset key. Variants with the 1000 value in there will be forcefully physics-enabled, and their drag model forcefully set to use drag cubes.
As for your drag concern, it's expected behavior that you will get vastly more drag out of the thick panels compared to the physicless ones. Arguably, you're cheating the (terrible) drag cube / aero system by building stuff out of the non-thick panels.
This being said, those parts get a single auto-generated drag cube based on the mesh of the largest variant, which can indeed be qualified as a bug, since you will be getting the drag of the large variant even with the smaller ones. I can try to take a look, but this doesn't looks like an easy fix, and TBH this won't change the fact that "modelling" stuff out of structural parts just isn't something that the KSP drag model supports correctly.
Fixing the issue that all sizes use the same drag cube will probably require some deep hacking, as the multiple drag cube handler is the variant module, and it has no knowledge whatsoever of what the FlagDecalBackground module is doing or of the existence of meshes of different sizes. The least effort route would likely be to generate drag cubes on the fly every time the part is loaded or its size switched.
If you really want to remove drag from those parts, you can try setting indexOffset = 0 in the FlagDecalBackground module, and in the variant module, change the variants sizeGroup to nonStructural and remove the attachRules key customization.
Thanks for the insight. I have tried changing the index offset and attachment values as well as nonstructural before, but it didn't work. I may try that again though, maybe something was wrong with my patch.
Flag sizes cannot be switched at runtime, only in the editor. Hence it should be possible to do a pass on craft load to override the drag cubes of the panel flags when a vessel is loaded. Only concern would be performance here. Especially as people have built planes with many thousand panel flags. (I know of a F-35 with about 3k small panel flags. The thing can basically not move at all in air.)
The ideal fix would tbh be a rewrite where every structurally different variant of the flag has its own proper config. But that seems like very high effort. A fixing pass for drag cubes at launch seems like the best way to me.
Fun fact: I constantly use thin flags surface attached to one another by enabling it per part with precise editor when I build.
I am also well aware that I am cheating the physics system. I am doing that because the thin flags without physics have a lot less lag than normal parts, making higher part count replicas feasible with reasonable frame rates.This also avoids the issue of insane lift and drag from a wing made of many angled wing panels. This Concorde can do an actual high alpha landing like the real deal. Just a few flags around the engine and landing gear doors had to be panel flags. And they utterly destroyed the previously great flight performance.
Having a fix for the drag cube size would be very helpful for getting this plane to fly well.
Gave a quick look at this.
So, allowing discrete drag cubes configurations isn't easily doable, but generating a drag cube on the fly when the module is loaded or switched seems to work well enough :
That looks awesome! Is there any way you could give this version to me to test on the Concorde? I'd be super curious to see how it performs.
Patch released in 1.25.0
I believe one edge case still isn't handled correctly, at least by my limited testing: You can also switch curved panel flags to be in portrait mode, which cuts their area down to maybe 30% of the landscape variant of the flag. Those portrait flags appear to have the same drag as their landscape counterparts, despite being way smaller.
Ha, good catch. Turns out modding features you didn't know existed doesn't work so well :P
Will push a release with the fix for that.
Should be fixed in 1.25.1, through commit 6999172
I have tried to write a MM patch that just removes all drag from the panel flags based on the discussion above. I was not successful. Would you have any ideas why it is not working? I would appreciate any help, could really use this patch.
@PART[flagPart*]
{
@MODULE[ModulePartVariants]
{
@VARIANT[*Panel]
{
//@sizeGroup = nonStructural
//@attachRules = 0,1,0,0,1
}
}
@MODULE[FlagDecalBackground]
{
@MESH[*]
{
@indexOffset = 0
}
}
}
You can try with @VARIANT[*Panel],* and @MESH,* instead of what you have. It might be you're only hitting the first instances each time. Remember that only toplevel patches are applied to all matching nodes, subnode patches need to have ,* specified as otherwise they will only apply to the first match.
OH: Also your @variant[*Panel] {} does nothing, because what's inside is commented out. What do you want that patch to do?
Thank you! The ,* indeed did the trick, forgot that was a thing. I am aware the variant stuff was commented out, that was other testing I was doing.
However now a different bug is back as even the thick flags are no longer full physics parts:
Whenever there is a flag attached to a breaking ground servo, and another flag is attached to that flag (which is only possible through trickery using precise editor or with panel flags, the latter only has the bug with my patch active, the former always has it), the flag attached to the other flag will be left floating where it spawned, and never move with the vehicle. This may warrant a separate issue.
It also appears that setting all of them to indexOffset 0 breaks the flag selector, small stays, but medium becomes small panel, etc.
Also somehow when I enable the patch the rear gear on my concorde gets stuck in place. I don't understand why, can't seem to replicate the issue outside of it.
Concorde30 liveryfix2.craft.txt Custom flags not included, but debugging should work without, if you want to have a look at it.
Okay so as for the concorde gear becoming stuck, this appears to be an issue where there is hinge - i beam - panel flag (with patch). Then when autostrut is set either on the hinge or the I beam, the gear freezes in place, likely because the autostrut is not properly re-routed.
Removing either the patch or the panel flags makes autostruts work properly again, for some reason.
Apparently removing the autostruts makes the gear move again, but all part links become extremely weak. especially the piston attached to the hinge too. I mean what on earth is even happening?
what I conclude from this is that just changing indexOffset alone breaks all sorts of things, from the size selector to autostruts to joint physics. @gotmachine is there another way to fully remove drag from thick flag panels without messing with the index offset? Messing with that seems to break a lot of stuff.