bac9

@Starwasher, is it possible to implement slightly more complex shielding definition than the current one? Right now shielding direction is defined by a single Vector3: MODULE { name = ModuleHeatShield direction = 0, 1, 0 reflective = 0.5 } It's workable for vast majority of parts, but unfortunately, not for something like this: When users have an option to separately select the shielding on top, bottom, leading and trailing surfaces of the wing, one direction can not adequately describe the shielding of a wing. I propose a few alternative models: A. Six floats or two Vector3 values, representing reflection multipliers on X+/X-/Y+/Y-/Z+/Z- directions. Instead of evaluating the difference between reentry direction and orientation of an old vector, you can interpolate between those six values on a sphere, finding exact shielding multiplier for a given arbitrary vector. Not very precise for very complex shapes, but still covers 99% of cases, including parts with shields on multiple vectors, like my wings. Let's say we have a wing with a leading edge covered with RCC, topside and trailing edge covered with LRSI tiles and underside covered with HRSI tiles. The config would look like this: MODULE { name = ModuleHeatShield reflective = 0.5; multiplierOnXPos = 0; // cross section, no shielding multiplierOnXNeg = 0; // cross section, no shielding multiplierOnYPos = 1; // leading edge, RCC, highest shielding multiplierOnYNeg = 0.25; // trailing edge, LRSI, low shielding multiplierOnZPos = 0.25; // topside, LRSI, low shielding multiplierOnZNeg = 0.75; // underside, HRSI, high shielding } B. Array of arbitrary Vector3 and multiplier pairs. The most precise way, allowing to correctly describe even very complex shapes with varied degrees of shielding. Instead of evaluating the difference between reentry direction and orientation of an old vector, you can find the value of shielding at a given vector by averaging contributions from array vectors weighted by their relative placement on a sphere relative to the vector you're checking. Closest vector-value pairs contribute more, ones at 180 degrees from evaluated vector and further contribute nothing, vector-value pairs in between contribute to an appropriate degree. This allows you to describe anything: for example, shovel-shaped shielded parts like lander from Interstellar or OPT cockpit, space shuttle nose cones with their intricate distribution of various materials facing various vectors, hemispherical shields and so on. Here an example of possible syntax: MODULE { name = ModuleHeatShield reflective = 0.5; velocityCurve { 0, 1, 0, 1 0.25, 1, 0, 0.25 0.5, 1, 0, 0.65 // and so on, just random sample here } }

Version 0.13 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Implemented a different setup method for the flight scene to prevent FAR checks from running before all procedural parts take their shape. It probably works. Minor logging changes _______________________________________ Yes. Probably not, FAR already controls weight based on connection strength, I can't interfere with that. And from what I understand, differences between those materials are not that significant mass-wise. Maybe cost will differ, but that's it. I'll look into it, but remember that top/bottom surfaces and the trailing edge are using different textures (check the part folder to find the difference) so the trailing edge can not really show the same texture as the top/bottom surfaces. If I go two property route, it will be a sync between two separate textures that just happen to look stylistically similar on layers of same index, which is not very nice. Some people would actually prefer to control them separately. That's too many options for my liking, because then you'll have to use four edge texturing properties for the wing part. I need a tweakable menu with collapsible property sections and a very robust replacement to existing property UI to make that sort of thing convenient to use. Same deal with other properties, like adding separate leading/trailing edge scaling parameter for root and tip side of every edge of a wing. None, just random names somewhat attached to how textures look, it's better to have those than forcing people to remember featureless index numbers. Feel free to suggest better ones.

That's an ancient bug on stock KSP side. Stock Bug Fixes mod should have a workaround for that.

KSP will load it correctly either way, - as far as I understand, that advice is only relevant for mods that fork KSP API Extensions functionality, and I'm not doing that, only using custom tweakable types.

Discussing it with ferram4 now, and it looks like the issue is not with OnStart order but with fundamentally wrong sequence of actions. Implementation from pWings is incorrect too. The problem is arising from the fact that FAR StartInitialization method computes per-wing occlusion data and not craft-wide occlusion data, so calling it after setup of a particular wing is not correct - you must complete geometry setup of ALL wings in the craft before starting to call that method for every wing in the craft in a separate loop, otherwise checks those wings perform can be potentially done before their eventual neighbors take shape. Looking for a good way to implement that now.

Well, that's problematic, OnStart is still too late then. I can't use Awake because it's only called on the loading screen, same as OnAwake. What else is there to allow setup before FAR startup? I'm not sure if Start event on MonoBehaviours runs before KSP OnStart. There is no way to influence execution order of classes without access to source Unity project settings, so if I want my module to run before FAR every single time, I need a method different from OnStart.

Version 0.12 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Added new surface type (uniform fill) by exploiting other vertex color channels in the shader - even though new texture types can not be added anymore Fixed alternative UI breaking in some detachment scenarios Potentially fixed an issue with wing geometry being constructed only after FAR performs vessel checks in the flight scene, which was leading problems like control surfaces stalling when they shouldn't Added value descriptions to material properties in the alternative UI Fixed some minor issues To remind, stock tweakable UI stores min/max values in the craft file for some bizarre reason, which means, for example, that you will not able to make control surface cross sections wider than 1m on crafts saved before version 0.11, that you will not be able to use new material type on wings created before 0.12, and so on for any change to types and value limits. My custom UI still works, though, so you can use that to set new values on old crafts if you don't want to rebuild them, until I figure out a way to override that bizarre tweakable UI behaviour.

I'm not sure I follow. Editing mode window (one with property hints and "exiting edit mode" message on exit) never appears on it's own after just attaching a new part. Have you missed "pressed G while keeping the mouse on B9-PW" step between steps 2 and 3 from the previous post?

Uh, is that happening when you edit procedural wing specifically and create a new part from the catalog that is an all-moving surface specifically? Or is that happening to the wing property menu when any new part is created while editing is in progress? Or is that happening to the property menu of any procedural part with a specific new part created? Or is that happening with any procedural part when any other part is created?

Ah yeah, forgot that control surfaces have 9 and not 7 properties, so a check in a certain place was rejecting the last two. Fixed, thanks.

That's not enough information, I need to know what other mods you are using, at which particular point they are breaking, whether there are any errors in Alt+F12 -> Debug log window and so on.

Version 0.11 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Centers of mass are now shape-dependent Added an alternative UI/input method in addition to existing tweakable support Minor fixes in code, textures and descriptions Increased the control surface width limit to 1.5m More info on the new way of editing the wing (implemented to avoid tweakable window memory leak and to provide an alternative control scheme for those who are familiar with pWings): Small window that appears in the editor when you attach a procedural part to the craft Window saves it's position and initially shows only a small control hint about entering edit mode You can point at any part with your mouse and press G to enter editing mode on that part As you do that, window starts showing contextual info about the wing and new hotkeys are registered You can move your mouse to adjust the currently selected wing property (like semispan) Alternatively, you can use two buttons to adjust a property by a fixed increment You can scroll through properties using other two buttons Order of properties is exactly the same as in the tweakable context menu, so it's easy to remember) The window shows the short name of the property used in the tweakable window, expanded description of what it does, and control hints Unlike with pWings, adjustment is not stopping as your mouse pointer leaves the wing (always irritated me) Once you're done, pressing G exits the edit mode (detaching the part or clicking the catalog does that too) The window can be hidden at any time by hitting close button on it

No and they won't be on any hollow object, that's just how collisions work. You can only use convex shapes for collisions, so the only way to make decoupler rings pass-through is to use about a dozen of rectangular colliders arranged like a donut. Using that many colliders is very bad performance-wise, so unless you have a pressing need to allow movement within a hollow area (like for a cargo bay part), sticking with a single cylindrical collider is the most reasonable. Yes, kerbals can't fall through a part like that, but this is negligible in comparison with performance cost of an alternative.

Well, I can call it from OnStart before geometry is created, sure. I prefer not to because the game spams OnStart every single time you mouse over a part over a potential attachment point. As about Start, I'm not sure it's safe to call anything from other plugins from that event, but sure, I can try.

I don't think I understand the issue from that sentence, can you elaborate? Not at the moment, I dislike severe distortion that occurs on leading and trailing edge geometry when you go that far.

Probably something like that: DRE integration linked to heat shielding configuration of a wing FAR-exclusive support for fuel tanks within a wing Alternative UI/input method in addition to tweakables Trailing edge shape selection for control surfaces Proper aerodynamic value calculation for distorted control surfaces (right now distortion based on Offset R/Offset T is not accounted for, which makes some heavily swept and distorted shapes imprecisely simulated) Optional support for leading/trailing edge collisions I think those additions are than enough for a mod that was supposed to take just a few hours on one weekend but still isn't finished

Yeah, there are some issues with that That's extremely complicated code-wise, there is a reason why leading DCC software spent decades perfecting those kinds of tools Construction of meshes at runtime is a memory leak risk, deformation and skinned mesh renderers are as far as you should usually go There is zero reason to implement that as even FAR is not accounting for any thickness, cross section and leading/trailing edge shapes, instead using a particular standardized cross section from NASA for it's simulation It's not compatible with the concept of modular wings unless you want to severely complicate the tech even further by allowing longitudinal wing sequences to take on arbitrary intervals of arbitrary cross sections And finally, if we're talking about leading/trailing edge curving in the top-down plane and not about curved cross sections, there aren't many reasonable designs that actually use significantly curved edges (underlying structure is always a grid of cross-sectional supports linked by straight plating anyway, which existing parts approximate well) Aside from the fact that most designs can be replicated by simply stacking varied narrow quadrilateral pieces, simulation of curved wings will have to be approximated using a set of quadrilateral shapes anyway, defeating the purpose of actually supporting such a part type when slice-based wings are already simulated properly Yeah, and I have almost implemented it. As my mod has quite a few more properties than pwings, it's control scheme is not really usable, but I came up with a relatively elegant solution (mix of mouse input and a window).

I do not recommend using that fix unless you absolutely need HX parts today or tomorrow. The plugin causing the issue is essential for setting up proper centered connections between numerous HX attachment points. MrBlaQ might investigate the issue with it tomorrow if he'll have some free time.

Version 0.10 https://bitbucket.org/bac9/b9_aerospace_plugins/downloads Added an all-moving control surface (configured exactly like procedural wing, rotates around attachment point). Fixed some property captions Added proper descriptions to all three parts Some internal fixes No solution for the SPH/VAB memory leak available so far (the issue is reproduced with some other mods like RSS and seems to be reproduced in stock in some cases, so there is no clear fix), the only workaround so far is to monitor your memory use in the editor and reload the craft when it goes too high - this will trigger Unity garbage collection and clear all objects cluttering the memory.

Got all-moving control surfaces working, will arrive in the next version.

I'd say I agree with removal of Poodle name, use of shared texture over adding unique ones just for one stripe, and four nozzles on the SRB. Those are not sacred pillars of stock style and don't really deserve particular respect I think.

I'm afraid the issue is not linked to FAR or this particular mod and simply scales with amount of stuff in the tweakable UI, which happens to be longer than in stock and therefore leaks more memory. I'm reproducing the issue with a stock fuel tank here, although at a slower rate (probably because the window contains only two sliders): K3|Chris, I know, I posted those images in the first place.

Reading the description, I doubt it's a good idea. Changing the shader to alpha-tested instead of properly transparent allows shadow casting, but will break semi-transparent editor rendering mode that helps during craft assembly. Aside from that, stock Unity shaders do not contain proper rim lighting code, so that breaks all highlighting, including highlighting on picking up, highlighting on editor selection, highlighting used by FAR, and so on.

I think I found an issue with the tweakable UI, but I'm not sure how exposed that part of KSP is to allow a third-party fix. It's pretty easy to replicate on any stock part in the editor, like a LFO fuel tank: Open the tweakable menu: ~1.1mb RAM allocated Close the tweakable menu: ~1.1mb RAM deallocated Move the slider: ~1-3mb additional RAM allocated per second I suspect there is a leak somewhere in the tweakable UI, because the memory used on tweaking is never freed unless you change the scene (i.e. trigger garbage collection). I have managed to bring memory usage from 2.5Gb to 3Gb through simply tweaking stock fuel tank oxidizer and fuel values for a few minutes. Can someone confirm the same behavior and @Claw, can you chime in on the possibility of accessing tweakable UI innards to potentially fix it?

Okay, still hunting down the leak. Aside from 0.9 testing, I'd like to know the results of testing this version of the library: https://www.sendspace.com/file/rmsmgv There is almost nothing to test it with, actually, because I have removed all code from it but tweakables and an update method checking changes to those tweakables. No working functionality there. So, if you'll find that the memory leak still occurs with this version, only two possibilities will remain - either my update method leaks something, or Squad tweakables invariably leak something into memory. Aside from that, I'd like you to test tweakables on stock parts without adding any of my wings into the scene. Let's see if the leak originates in the tweakables themselves.