bac9

It's already there, but it's not an up to date copy, I think

Some issues I have to look at before releasing: - Specular material settings are out of whack, completely different from very specific values other parts are using - Tiny buttons to the left and right of the sliders no longer move values in steps (they were introduced to make fixed width stuff like 2m, 3m, 7m pieces easier to configure) and instead ram into min/max values with a single click - Stock drag cubes are recalculated on every geometry change - unless they directly affect CoL, with the absence of any drag visualization tools in stock it might be better to keep that laggy process running just once, on flight scene startup

Finally got the alternative texture set done, consistent with stock parts by Porkjet: I will upload a new release with all the fixes from Crzyrndm fork soon.

Ah, alright, makes sense then.

Looking great! But speaking of which, do you have access to his repository? It would be better to just push the files there instead of using separate archives that might easily be lost once the thread turns a few pages.

As I've said, that's intended. It's as if four visually different identically sized parts with four fuel presets each were merged into one part, resulting in 16 subtypes.

Okay, I need some help. Essentially, I need to test how new PartModule (subtype switcher) is working on every MK2 and MK1 part included in the archive. Some of them contain as many as 16 subtypes. https://bitbucket.org/bac9/b9_aerospace_plugins/downloads/B9_Aerospace_PSSM-01.zip I decided to disconnect meshes from resources - it's nicer to be able to stack four different designs than to be forced to stack four identical ones just because you need a sequence of four LF tanks in your craft. Every visual has every resource preset available. I will probably introduce small resource-dependent visuals later, like minor colored stripe decals appearing on top of parts, but for the moment colors and seams indicate nothing about resources housed within. Some parts also have attachment node switching, specifically MK2 to 1.25m and MK2 to 2.5m adapters which have offset variations. Part descriptions and costs are placeholders and drag cubes for cargo bays are missing, the rest should be okay (resource amounts and all that), and if it's not okay, please do tell. Check whether all subtypes have correct number of resources for their volume Check whether all subtypes have correct attach nodes enabled Check how attach node switching works (reattach things, duplicate things etc.) Check persistence, jump between flight and editor, save/load and so on

It can be handled in the way similar to B9-PW fuel switching. Give me assembly names, and I will disable fuel switching logic if they are found on module startup, turning the switcher into strictly mesh and node switching component with no access to part resources. Disabling the new switcher completely would be a pretty bad idea, I think, as no other switcher handles stack nodes and I need to switch stack nodes due to multiple shapes sometimes being packed into one part. So leaving my component doing visual and node changes and other components doing resource changes is the best solution.

No idea what that is, to be honest.

MK2 parts are going well. I'm also almost done with updated 1.25m and 2.5m cylindrical pieces matching the style of MK2 - I was always frustrated with the need to insert ugly stock tanks or out-of-place KW tanks into various crafts, so those would come in handy. In other news, I finally have a working implementation of the new subtype switching part module that can supercede the use of Firespitter fuel switch and mesh switch modules, offering a nicer config format: MODULE { name = PartSubtypeSwitcherModule subtypeGroup = 0 uiCaptionNext = Next uiCaptionPrev = Back uiUseSecondButton = True availableInFlight = False availableInEditor = True massBase = 0.34 // Stack nodes // Define key/node identifier pairs here, then use the keys in subtype definitions // Allows you to enable only particular stack nodes when particular subtype is used PRESET_NODE { key = 0 name = top } PRESET_NODE { key = 1 name = bottom01 } PRESET_NODE { key = 2 name = bottom02 } // Objects // Define key/object name pairs here, then use the keys in subtype definitions // Allows you to show only certain parts of the hierarchy when particular subtype is used PRESET_OBJECT { key = 0 name = body_mk2_section_2m_a } PRESET_OBJECT { key = 1 name = body_mk2_section_2m_b } PRESET_OBJECT { key = 2 name = body_mk2_section_2m_c } PRESET_OBJECT { key = 3 name = body_mk2_section_2m_d } // Resources // Define the key and preset name here, then use the key in subtype definitions // Type and size fiels are optional, leave them out to define a structural preset // Those fields can house multiple values separated by commas (e.g. "LiquidFuel,Oxidizer") PRESET_RESOURCE { key = 0 name = STR } PRESET_RESOURCE { key = 1 name = LF type = LiquidFuel size = 672 } PRESET_RESOURCE { key = 2 name = LFO type = LiquidFuel,Oxidizer size = 302,370 } PRESET_RESOURCE { key = 3 name = RCS type = MonoPropellant size = 672 } // Subtypes the player will switch between // Use the keys you have defined above to configure nodes, objects and resources // You can use multiple node preset and object preset keys, but only one resource preset key // Do not include references to resources into the subtype name, resource preset name is auto-added SUBTYPE { name = Standard A massAdded = 0.06 costAdded = 732 nodeKeys = 0, 1 objectKeys = 0 resourceKey = 0 } SUBTYPE { name = Standard B massAdded = 0.06 costAdded = 732 nodeKeys = 0, 1 objectKeys = 1 resourceKey = 1 } SUBTYPE { name = Offset A massAdded = 0.09 costAdded = 503 nodeKeys = 0, 2 objectKeys = 2 resourceKey = 2 } SUBTYPE { name = Offset B massAdded = 0.04 costAdded = 865 nodeKeys = 0, 2 objectKeys = 3 resourceKey = 3 } } The module also supports node switching, so it's finally possible to roll things like centered and offset adapters into a single part, with correctly handled stack attachments changing as you change the subtypes.

Not at the moment. I recommend each and every one of those mods and aim to make new MK2 parts visually compatible with Porkjet style used by everyone. I don't think there is a point in wasting time filling B9 with duplicate parts.

I think it was both, reference MK2 bay config. That's probably an oversight of someone responsible for the configs.

Speaking of drag cubes, absolutely no understanding of their format or any math is required to do them for the cargo bays. Just get the auto-generated drag cubes of the identically sized non-hollow fuselage parts from PartDatabase.cfg and copy that into the cargo bay config, done. Hollow parts that are see-through on the stack axis get incorrect estimate of the cross section area, and pasting the drag cube values from another part is fixing that. No values have to be changed at all. If you are feeling fancy, you can copy and replace only two specific sections in them, as only those are relevant. I think it was third and fourth vector, but I'm not sure. I think NathanKell posted about that on the forum recently.

@JohnFX It's impossible to enable shadows from any point or spot lights you are using, because KSP is using forward rendering mode where shadows only work on a single directional light (sun). Performance drops don't come from shadows and setting shadow casting flags in the Light objects has zero effect.

As far as I remember, stock resource flow was broken in some way, necessitating resgen. Something about radially attached parts not receiving resources properly. I don't remember what it was exactly, it was a decision by Taverius and Snjo, I think.

One consideration here is the fact that stock engines are... hideous, aesthetically speaking. So, I'd say it's reasonable to balance turbojet and F119 as replacements for two currently existing stock engines, not as parts that must go to some new niche relative to stock and must keep stock parts place in the craft designs. Also, if I remember correctly, stock engines were a bit unreasonable with some stats (low mass or insanely low fuel consumption? can't really remember well, best to ask ferram4), so, just like in the previous versions of the mod, I don't think it would be a big deal not to use them as an absolutely neutral baseline.

Hey, just in case: don't bother updating the node plugin yet, it has some fundamental issues and I just came up with a better way to switch nodes that avoids them. I'll probably make a new module for that task on HX parts.

I don't really mind a question mark, to be honest. HX is a very isolated set of parts, and it's with it's insane cross section size a shaped icon won't tell you much about it's difference vs. for example S2 profile anyway. But if you feel it's a necessary dependency, go on, it's up to you to decide, you are doing the bulk of the update job anyway, - I'm just fiddling with some assets. :^) Speaking of which, here is a quick and dirty job at MK2 pod IVA. Needs prop placement, and that's the most unfun and tedious work ever, made worse by quirks of the Part Tools, so I don't know when I'll finish it, heh.

We have found an actual reason for the voxelization issue - negative scale being applied to any part with mirrorRefAxis config parameter, which will introduce incorrect vertex ordering into triangles. The parameter is rarely used, hence it makes it seem like the problem is specific to B9-PW, but it isn't. There will be a fix in the next version of FAR, I think.

Probably not, there isn't a single shared dependency between B9 and B9-PW, and B9-PW requires frequent updates to plugin code, so it makes no sense to cram them into the same download. It would be very inconvenient to reupload entire B9 just because of some minor change in the B9-PW plugin.

I think blowfish wanted to make a legacy pack as some people prefer old wings, so I wouldn't say it was for nothing even if procedural wings would be the only wing part left.

That depends on the definition of support. I'm thinking it would make sense to remove every single wing part from the pack once B9 procedural wing mod is stable, which is compatible with stock. Old issue with mass dependent drag making stock B9 aircraft impossible to fly is gone, and old B9 sample crafts are gone forever anyway, because new part set won't be compatible and balance is different. Old issue with intakes having to use absolutely insane mass values and very delicate aero values to work properly in stock is supposedly gone too. This makes stock viable with B9 again, I guess. It's not about "adding support", it's about some insanity disappearing from stock, which makes the part somewhat usable with no work on our side. I still can't recommend using stock over FAR at all, though, as it lacks extremely important features like occlusion between wing pieces.

There are no rigidbodies in the exported parts, so that's not an issue (and objects with that component don't break in U5 anyway). Parts don't contain audio components, so that's not an issue (they weren't changed anyway, U5 is just introducing a godly mixing system that has nothing to do with them). Nope, absolutely nothing like that. The only thing that can be stretched to be described as UV changes is the swap of Beast lightmapping system to Enlighten lightmapping system that made results of on-import UV2 lightmapping coords generations different between meshes imported in U4 and U5. Except parts have nothing to do with lightmapping system and not a single part is ever using UV2 coordinates, so that's not an issue. There are actual changes that can affect the mod, like removal of old wheel colliders - all B9 landing gears are guaranteed to be obsolete with U5 update landing. Except, uh, I'm thinking of dropping every single landing gear part from B9 anyway, because they serve no purpose anymore. BahamutoD adjustable landing gears are far, far superior versions of the same design filling every niche and far more than old static parts could ever have. And there are new perfectly looking stock landing gears from Porkjet. So there is no point in including old B9 gears anymore. To be honest I'd prefer not to add any new external dependencies to already enormous dependency list, and I'm working on removing Firespitter dependency for mesh/fuel switched parts.

New MK2 cockpit, slightly inspired by F-35. Has a subtype with an intake somewhat resembling X-32. I hate opaque matte glass material KSP parts are forced to have, so I guess I'll use a sideloaded reflective shader.

S2 is 2.5m with sides cut off and it has a very short adapter to 2.5m available, so I don't see any point in creating MK2 to S2 adapter. As about heat shielding, we'll see, I need to come up with a good way to toggle the textures on select parts of the mesh and the system from B9-PW will not work here.