bac9

That's not reproduced on my side, editing original parts correctly propagates all changes to symmetry counterparts. There is some other factor I guess.

Version 0.17 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Implemented coloration - every wing surface (top/bottom/leading/trailing) can now have not just previously implemented separate material type, but also an appropriately masked paint overlay with configurable opacity, hue, saturation and brightness Reimplemented alternative UI, it now closely resembles tweakable menu with a number of improvements over stock (color coded groups, longer labels, hints, collapsable sections) Moved all sliders in the stock tweakable menu to KSP API Extensions UI_FloatEdit editor, which seems to positively affect the rate of a memory leak on tweakable window redraw (sometimes it even stops entirely). Unified all properties, control surfaces and wings no longer use isolated fields (breaking change, all previously built crafts will not retain wing part configurations) Added an option to set current configuration of a wing or control surface as default, making all subsequently created parts of that type use the same values (along with an option to reset default values back) Shifted all properties into logical groups Implemented collapsable menus to make editing more convenient Geometry and performance fixes, refactoring and minor fixes in other areas Improved some layer textures, surface type 0 in particular (rivets, more appropriate seam structure and so on) Alternative UI is now opened with H instead of G to solve binding conflict with some mods Note: Again, this update completely breaks all procedural parts in crafts saved with previous versions of the mod. Hopefully there will be no need to change part field structure in the same way again, but there you have it. Known issues: Alternative menu will not reappear if you will exit to the KSC scene and return to the craft (this scenario is not triggering initialization of a window for some reason, looking into it) Hint text in the alternative UI sometimes changes to description of a wrong field Stock tweakable menu can still leak memory, probably from UI_Toggle buttons Collapsible group contents and headers sometime come out of sync after certain sequences of switching between parts (can be fixed by double-clicking the group header)

I moved every single tweakable slider to KSP API Extensions UI_FloatEdit, those don't seem to cause the same bloating issue (I got up to 15 megabytes per second use growth before switching, that's insane), but that will cause every single tweakable on previously saved crafts to stop working because of unwanted UI data KSP crams into craft files. I'll see what can be done, maybe a bash script that can convert your .craft files to clear that garbage from them. I'm aware of this, but I don't know what's causing it yet. I need more testing and reproduction steps, including stuff like whether second part you clicked was a symmetry counterpart of the first or not. Control surface offset is a multiplier for shifting vertices on the lateral axis by their distance to root on the chordwise axis. At the moment it can not go over 1, which means no control surface can be swept by more than 45 degrees. I'll look into altering that, but distortion that is very problematic and can potentially cause hourglass shaped intersections with inward offsets. Yes, obviously, as that was a scene change and Unity mops up everything with a garbage collector in that event. Same thing happens on creation of a new craft or loading of another craft in the editor - those are implemented through complete reloading of the editor scene.

Not every new property is exposed through the alternative menu yet, there are too many of them to make it convenient (12 new ones). Shouldn't be an issue for you, because only properties that existed in the previous versions become broken due to that issue, but I'd like to have a permanent solution to avoid that problem with future changes.

The next update will bring some neat features, but thanks to KSP saving uneditable properties like range from KSPField UI_Control (tweakable UI) types straight into the craft files and attempting to override definitions from the class with those values, tweakable UI will be partially or completely broken for every single wing part placed before the next update. As far as I understand after asking a few experienced modders, there is no way to fix it except: Manually editing every single wing definition within every single craft file, removing the offending sections that break our stuff Making a script that can do the operation above automatically to an arbitrary craft file If there is anyone proficient in the latter, lend a hand - I don't have any experience with perl, .bat and other ways to create a script like that. The task is pretty simple, you need to find blocks called *_UIControl and remove them along with a set of properties surrounded by curly braces that follow them.

Everything is in meters.

From what I remember, temperature is added once per every module so multiple modules have a chance of overheating the part much faster unless heat is added just from the dot product between shock front vector and config vector, with no additional sources capable of overlapping. I'll check it out again though.

No, IVAs exist on an entirely separate layer and are rendered with a separate camera, properly configured light sources in parts can't enter them. That's how scattered light from my M27 cockpit works - there is a spotlight inside it with a huge cone, borders of which are perfectly matched to vertical window borders. (IVAs also have completely wrong orientation which makes the only light source entering them from outside (sun) incorrect, but that's another story)

If you want the spotlights to light up one spot, then use this trick, it will look almost identical while being twice as cheap, provided your part has enough length to shift the light source back as far as possible. Just make sure no backward-facing triangles enter the light cone before the point where you have spotlights modeled, drop some emissive in appropriate places, and it will look gorgeous.

Yeah, it might be justified here if you keep the beams from intersecting. What I meant by the part you quoted is the fact that some parts (like stock spotlights) are most commonly used in symmetry-based groups (2x, 4x, etc), so light sources in them should be kept to a minimum, as players will inflate light counts very significantly even with one source per part.

Ideally you should not ever use more than one realtime light per part, since it's extremely easy to go over default per-pixel light limit of 8 (or in some cases 4) lights. Using two spotlights is unreasonable unless you are making a part like a pod that won't be used in symmetry. Aside from per-vertex lighting that is used as fallback for any lights going over the limit being ugly as sin, there is another factor: KSP is using forward renderer, so every single light makes scene rendering more expensive, forcing a redraw on every vertex and pixel it affects. As you can imagine, 64 per-pixel lights affecting enough on-screen geometry is an extremely undesirable scenario. In controlled environments of other games, developers using a forward renderer never ever use so many per-pixel lights - if a game really requires that many individual sources, it should use deferred rendering. Remember also the fact that the sun already eats up one per-pixel light slot, and mods like PlanetShine eat another. Speaking of which, stock landing gear containing three light sources is an extremely bad example. Absolute majority of cases when excessive amount of light sources is used should have used emissive maps and emissive shaders to imitate the desired effect, be it a stop light, lit up lightbulb, crew pod windows and so on.

Single-vector config currently used by DRE makes it impossible to accurately represent shielding of separately configured top, bottom, leading and trailing sides of the wing. Ideally we need a way to define shielding per 6 major directions or to define an array of vectors and shielding multipliers of arbitrary length, but there is nothing like that supported in DRE at the moment. I'll have to postpone it's support for now.

The current limits are likely to stay in place. The precision of tweakable sliders is limited: at any given increment step you can only push the range so far before the players lose any option of reliably hitting particular values (for example, 0.00-8.00 range with 0.25 increment makes is impossible to hit values like 0.50) because there are only so many pixels to click. I somewhat offset this with layered tweakables for the parameters with the biggest value sets (like semispan), but still, I will never introduce ranges like 0-64 meters or increments like 0.01, because they will impair some precise designs and selections rather than broaden the options. Another reason for limiting range is stuff like wing flex you should not entirely sidestep - I don't think it's fair to drop one 60m wing piece and call it a day, avoiding all potential challenges. I'm not getting any lag, so that's interesting. There is an unavoidable delay before the movement of your mouse takes effect (the distance passed by your mouse must accumulate to at least the integer value of 1 in order to move a given parameter by one increment step - otherwise you it would've been possible to scroll through entire range of values in one tiny swipe, which is unusable), but I never encountered real slowdowns. What hardware, mods and part counts are you dealing with?

Version 0.16 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Wings support thickness of up to one meter from now on Removed leading and trailing edge multiplier property from wings Added leading edge root/tip width and trailing edge root/tip width properties, all four of them can be adjusted from zero to one meter, allowing you to set up vertically elongated edge cross sections, horizontally elongated edge cross sections and cross sections proportional to arbitrary wing thickness values alike. Added collapsable categories parenting logical property groups (dimensions, materials, edges and so on) to the tweakable menu, making the selection and adjustment of numerous properties more manageable All tweakable properties are no longer initially open in the context menu, being hidden under categories Replaced all edge models with new ones, improving cross section polycounts and adding hard material edge that looks better under arbitrary thickness and edge width combinations resulting in stretching Reordered edge models: first type is circular, second type is biconvex (between sharp and circular in shape), third one is triangular, which makes a bit more sense (progression from smooth to sharp shapes instead of random order) Reordered and renamed some properties for convenience Added flat fill support (fifth material type) to edges Improved aerodynamic value calculation for wings, edges now properly contribute to the behaviour Improved aerodynamic value calculation for control surfaces, trailing edge widths are now taken into account, along with contributions of offset properties to taper ratio Internal fixes and refactoring in geometry handling, setup sequence and field updates Top and bottom surfaces of control surfaces and wings are collapsed into one mesh with a slight benefit to performance (separate material selection still available, shader based switching makes use of one mesh a non-issue) Slight improvements to text in alternative UI Note: This update can potentially make the crafts made with previous version of the mod unstable, due to changes in aerodynamic value calculations for FAR. Specifically, with wing and control surface edges now taken into account, you might see unexpected increase in lift from your wings, which has potential of, for example, shifting your center of lift a bit forward. Nothing catastrophic and nothing that can't be fixed with a bit of tweaking (using, for example, four new edge shape properties), but I figured you should know.

I'll look into CoM issue, thanks. As about the report, at the moment it only works on procedural wings, not control surfaces.

This a very good thread, thanks for taking the time to put it up, PDCWolf. I have to agree that FAR is easier for me, and, more importantly, I'm of opinion that it's fundamentally a better choice for new players, as things looking like real planes actually fly like real planes when you have a proper aerodynamic model. Making aircraft design more intuitive is an undeniable benefit. I also think it's important to look at the difficulty in combination with design depth and potential for fun gameplay. If some system adds a bit more challenge to the craft design process but enriches it with branching, meaningful design choices (for example, making previously completely ignored wing shape or rotation meaningful), I can only welcome such a change. Puddle-deep mechanics are not necessarily easy and most definitely can't provide lasting fun.

Version 0.15 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Finally fixed the issue with incorrect wing interaction, parts should properly account for occlusion by surrounding parts from now on. Huge thanks should go to ferram4 for helping me to set up reflection of FAR wing interaction data.

Version 0.14 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads

1. pWings 2. No.

I have absolutely no idea about further possible causes for it beyond ones I have already taken care of. Ferram4 told me that an issue can be caused by per-part FAR module initialization being fired before geometry of surrounding wing parts takes shape, making occlusion checks performed there return erroneously negative results for parts that should actually be shielded. I have made this impossible by refactoring the way FAR modules are initialized - now that is performed only after every single part takes shape. Some people have reported it has improved improper stalling in their designs, so the solution was at least partially correct. What else is causing the issue in addition, I (and I suppose, ferram4) don't have a slightest idea.

The mirroring used by this mod is performed on the KSP side and only works correctly with very specific combination of part orientation and config values. It only works as expected on non-vertical surfaces within SPH, everything else gets random rotations. Nothing I can do, lack of proper mirroring is an issue of stock KSP. All I can recommend is not to use VAB, never roll your craft within the editor and never pitch your craft within the editor by more than 80 degrees from the forward axis.

Yeah, distorting the central box with split thickness values is possible, although some issues with that will remain (box colliders can't be deformed like that, you'll still have to use a mesh collider) and some new ones will pop up with that approach (one of the edges will be disproportionately distorted). I might look at it later, but just as with proposals about more properties and more fine-grained control over various parts of the wings (like separate configuration of top/bottom leading/trailing edge surfaces), I need to figure a way to radically rework the UI first - otherwise I risk making UI an unreadable mess of endless properties that is hard to use efficiently. Ideally I need something like a layered menu with separate property groups that can be opened and collapsed at will.

The issue he pointed out does not exist when the part orientation is set up properly and symmetry is properly configured, so all my proposals still stand. And nope, I'm not really interested in using 360 coverage.

Ferram has mentioned valid problems with visible camber and I agree with his opinion on wings made from a chordwise sequence of parts too. I am not planning to introduce support for it. Some reasons: Supporting shaped chordwise cross sections (especially asymmetric) will significantly complicate the way I control wing geometry even if I limit the shaping to the middle section of the wing without touching the way I handle edges Supporting it fully will require complete rewrite of the current structure (separate leading/trailing edge objects and middle box), making whole wing one piece of geometry with vastly complicated deformation code Supporting multiple cross section types is an additional memory leak risk and additional hierarchy clutter if I do it through mesh swapping There is no elegant way to allow a wing to take on an arbitrary slice of a cross section to properly support segmented wings (and you don't want wavy wing surfaces, do you) KSP attachment system will freak out completely if forced to deal with curved surfaces like those, goodbye precise landing gear placement I'll be forced to use a mesh collider instead of a box collider to support proper collisions, which will have significant performance impact While I got mirroring to work so upside down cambers won't be an issue, I have no way of controlling it which leads to random flipping of vertical surfaces and will require implementing separate geometry handling for vertical and non vertical wings if I want to keep the former symmetrical So yeah, sorry, it's an enormous can of worms I'd rather not open.

Haha sorry, I was in a hurry and mistyped. That's a non-issue, Porkjet found that an ancient mirrorRefAxis vector property in the part configs actually works and actually mirrors your parts correctly, but only if you use very specific combination of object orientation and attachment node configuration. So yes, my wings and control surfaces are correctly mirrored and have the same directions in local space pointing up, down, forward and so on.