bac9

I'm inclined to believe that tweakable UI leaks memory when opened even on parts without my plugin, which is pretty weird.

Version 0.9 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads The mod is now compatible with NEAR (although I'd still recommend using FAR, near only receives compatibility patches these days and is not actively developed by ferram4 in contrast with FAR). Testing for memory leaks is still required.

Version 0.8 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Changed control surface geometry to allow topside and underside borders to go all the way to the trailing edge, improving the looks and readability of control surfaces with gray surface types. Added an additional wing edge type (round one) Improved texturing on wing edge cross sections Control surfaces can now have bigger widths Other changes are internal and attempt to close the memory leak. I don't know whether they actually succeed at this, so I need detailed tests again.

Additionally, I'd like to know whether memory leak persists into the flight scene. If there are no noticeable leaks with aforementioned craft with just one wing part, try flying a full-fledged craft like the sample fighter jet too. Yeah, I'm planning on making smaller sizes possible, but that will require some changes to cross section texture mapping for wings and some significant changes to allow variable trailing edges on control surfaces. As for gradual size unlocks, I'm investigating that too. Planned, but not in the next version.

Thanks, those are interesting results. And about craft loading, - yeah, it's supposed to reset RAM usage completely unless KSP does something wrong. Memory leak most likely occurs simply because some objects are created, forgotten about and created again, piling up in memory (for example, some geometry). As the craft loading is implemented as reloading of the SPH scene, those objects can't survive it - Unity garbage collection (search for all objects that are not referenced from anywhere) clears all objects like that on any scene change.

No ETA for the next version yet, but here is what's changed so far: Changed control surface geometry to allow topside and underside borders to go all the way to the trailing edge, improving the looks and readability of control surfaces with gray surface types. Added an additional wing edge type (evenly round) Improved texturing on wing edge cross sections Only thing left is figuring out what is causing the memory leak. I eliminated one of the potential reasons (wing leading/trailing edge type switching is no longer reliant on mesh instantiation), but it still seems to occur over time, so something else is in play. I would appreciate if some of you will do the testing of that particular issue. In particular, I'm interested in the following test setup: SPH New craft created with the latest version of the mod One part (say, stackable MK2 cockpit), one wing attached to it, no symmetry Open the game in windowed mode, open some process monitoring tool next to it, and observe how RAM usage of KSP.exe is changing. I am interested in the following questions: Is there a situation where memory usage is not raising while the wing is present in the scene? (check it with wing dragged from catalog but not attached, with wing previously present on the craft but detached, with craft loaded but untouched, and so on - maybe there is a particular situation where memory leak is not happening, and if there is, it will help narrow down the source Is any particular action performed through tweakable UI causing noticeably accelerated rate of memory usage? Is there any difference in the rate of memory leak between fully stock game and a game with FAR? Depending on results of those tests, I might be able to find the source of the leak, but so far search for it was inconclusive. I have eliminated all the obvious suspects like .mesh/.material calls and instantiation use, so I need more information.

Not sure what you're asking about - leading and trailing edges already have two curved cross section types available. Edges do not affect any collisions, though, as is tradition with KSP parts to make multi-part wings and control surface attachment less infuriating. The texture is not meant to be used on a small scale like that, and leading/trailing edges do not have scaling proportional to semispan and width, so at the moment those parts are unfit for small craft like that, yeah. I'm not interested in career in it's current state, but I'll look into implementing that if it's not too problematic. I don't think I understand the question, curved cross section types for leading and trailing edges are already there. If you're talking about some other curvature, specify the axis it occurs on.

Sure, should be possible. I'll need to modify offset implementations a bit to prohibit very distorted triangular shapes possible with those sizes, though. Sample 2 is not supposed to be particularly versatile atmospheric craft. I mean, it takes off alright and I did a few roundabout flights with successful landings with it, but mostly it's simply designed to glide back from orbit, not do aerobatics around KSC, as it has too little control authority and can stall easily. Requires flight assistance and gentle turns like any other design of unorthodox shape with suboptimal control surface placement.

Unfortunately it's impossible to fix, you'll have to recreate the groups. The developer of the gimbal plugin changed the name of the gimbal module, which breaks all previously created actions linked to that module. Absolutely nothing but B9_Aerospace folder consumes significant amount of RAM, so you should never remove anything but parts from B9_Aerospace/Parts/* to free it.

Forgot to add it into the last archive, uploaded a separate archive to the repo now. Unfortunately it's not possible to fix this. Attachment positions of parts should be controlled by the editor, not part modules. It's a very, very problematic area I'd rather never touch and leave to mods that really require it, like KAS and robotics. I'm unable to reproduce this, so I'll need more details and a log. Thanks, investigating that, likely linked to switching of trailing/leading edge meshes on the wings. At the moment aerodynamic values calculation for control surfaces only accounts for root/tip width and length, not root/tip offsets, which will probably account for the difference if you are using slanted control surfaces on a swept trailing edge.

Version 0.7 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads - Implemented trailing and leading edge surface material switching (4 types available for each on both wings and control surfaces - again, through the shader at no additional rendering cost) - Implemented a fix allowing crafts saved with version 0.5 to migrate to new tweakable UI without breaking - Improved debug output - Fixed some issues with startup - Included two sample crafts

5.2.8, looks like I forgot to push all recent commits to master.

Version 0.6 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads - Fixed control surface lengths being incorrectly clamped in the flight scene

This is not very helpful without the text of those exceptions.

I have no problem converting DDS files individually but I don't have the time to do that at the moment, which postpones move to DDS unless I can get batching to work. I'm also not using PNG files (I have TGA set from 5.2.2 lying around) to avoid widespread issues with alpha reading and unfortunately it has not helped. So yeah, for the meantime I'd recommend just using ATM and waiting half an hour for it to do it's thing.

Release 5.2.8 • Fixed gimbal configs for all parts • Removed erroneously included incomplete S3_V2 P.S.: Make sure you DO NOT have a GameData/B9_Aerospace_DEPRECATED folder installed. Remove it if it's there, it should not be used.

Version 0.5 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Updated procedural wings with tons of stuff. Bad things first: - Some existing crafts saved with older versions of the mod will have width and semispan tweakables locked - You have to manually remove all .mbm textures from B9_Aerospace/Parts/Aero_Wing_Procedural Fun things next: - Implemented shader-based surface type switching. No two separate surface materials per wing, no performance hit, no draw call inflation no matter the combination - wings are textured from one RGBA image containing four layers, depending on vertex colors I embed into the mesh. - Surface type switching now available for control surfaces - Surface type and edge type selection is now done through the same convenient slider as other tweakables - Reordered/renamed some stuff for convenience - Allowed catalog-created parts that were not attached immediately after creation to be picked again - Switched UI for wide-range variables like wing semispan to sliders from KSP API Extensions (stock tweakable sliders would not allow you to pick some values, being imprecise) - Fixed geometry corruption on reattachment - Fixed some other bugs (hopefully introduced less new ones) Next time: - Texture switching for trailing and leading edges - Got to investigate strange behavior of symmetry counterparts, causing tweakable UI on them to work slightly wrong - More precise aerodynamic value calculation for control surfaces - All-moving canards? - - - Updated - - - The former is not possible as the label is extremely limited in allowed character count. That's why parameters are labeled "Edge L" and not "Leading edge", etc. The latter will fit onto the label, but I'm unsure about it - sweep is typically understood as an angle (per edge) and this parameter is a distance between root and tip cross sections, not an angle.

Judging from the post with "certified" modders being last edited in the beginning of September, I would guess no one would mind.

Is the requirement to announce the intent still in effect? I'd like to use the library in my procedural wing mod to solve issues with stock float sliders not allowing proper selection of all possible values.

There is no way to work around that (a part is a part, plugin-based part modules don't ever get a say in that) and to be honest I do not consider this a cheat as the stock game is very inconsistent with part volumes anyway.

Some issues found and looked into so far, no need to report on those: Control surfaces becoming corrupted on symmetrical duplication Wings above 0.24 thickness becoming partially corrupted in certain circumstances Control surfaces clamping their span to 0.5 while allowing it's tuning to 0.25 Stock tweakable slider UI preventing you from selecting 1m wing semispan and some other values Ah thanks, I prevented this on the wing but forgot to do the same with the control surface. Logic creating the collision shape only runs if you attach the part, which makes it impossible for KSP to grab onto it if you leave it in the air without first attachment.

The cost of the part is scaled with it's size. Every wing only only counts as one part (obviously), but I'm not aware of any career mechanics making it a downside (performance wise it's an upside).

All those folders provide various special functionality (like engine gimbaling, context menu tank switching or IVA MFD displays) that's not available in stock and should not be removed. You can overwrite them, though - just make sure that you're not overwriting those folders with an older version, which can break functionality on B9 parts (easy to do by installing Firespitter mod released in September over the latest version of B9, for example - the DLL from the former is wrong and will break all switchable parts in B9, so it should not be replaced with one from such an old version).

Not really, no fixes for MK2 until we figure more significant issues.

Hi, I'm attempting to convert B9 textures to it, but I'm getting a weird issue where files are reported as found but are then completely ignored on export, with every single one skipped for unknown reason. Tried every mask setting, disabling config reading and every other option, zero effect.