JonnyOThan

Post logs

No that's 100% incorrect. ConfigNodes have nothing to do with Unity or prefabs either. Generally hiding/deprecating parts is preferred because if the part is deleted then any craft files or vessels that use it will have problems.

Right I wouldn’t expect much difference at all at that scale. We’re talking about 4 draw calls vs one. Each frame is usually on the order of tens of thousands of draw calls. You only really need to start caring when you expect the impact to be multiplied hundreds or thousands of times. For example this is significant when dealing with props. And again it’s a trade off - maintainability vs memory vs speed - so you need to know what’s going on in order to make good decisions. And, yes, profile it

Well, no, it has pretty significant performance impacts. It's important to understand what's going on under the hood so you can make good decisions about how to build content. Most of this stuff is not specific to KSP though; it's general Unity knowledge.

Well they generally will be separate draw calls. But at least the mesh geometry isn’t duplicated.

When you click the button there’s a small pop up at the bottom middle of the screen. Click on that and the cfg lines will be in there. It outputs both euler angles and quaternions, just select the lines you want and hit copy. When you do this, you’ve made the game load the same mesh geometry twice. When you use a prop or reference other .mu files with MODEL nodes in the cfg, the mesh geometry only exists once and is just referenced rather than duplicated. Further it creates the maintenance headache that I mentioned - what happens when you want to update the chair model? You have to do all that work over again.

Blender is fine for positioning a few props, but if you need to do a lot then use Unity. And translating the coords from blender is easy - there’s a button labeled “show MODEL transform” which dumps the cfg lines you need to the blender output log. I’m pretty sure that’s not true. I don’t know of any mechanism that is able to share meshes within a single .mu file. But maybe I’m missing something. And the texture point is orthogonal - there’s nothing stopping you from putting prop and internal textures on one sheet if you wish.

That should already be happening..?

Not if the transform is in the prop. Well yes, just like every prop. And positioning those in blender or parttools is very easy. Duplicating meshes in the internal model itself is not great - the geometry is not shared between the objects; they're all imported uniquely by unity. Using a prop means that the model only exists once and is shared. There are some tradeoffs here - each gameobject will be drawn separately so there can be some benefits to baking stuff down in the mesh - but only if you're merging them into a single model and not leaving them separate. Props also have the advantage that you can update them in one place (better art, textures, more features) and it'll just work everywhere. This is super important when dealing with hatches, seats, etc. for FreeIva and KerbalVR support. Fine. Note that the seats in the stock mk2internal are already baked into the model, so you can't really apply this directly there unless you make a new model with them removed (which it seems like you're already comfortable doing, regardless of redistributing modified stock assets, but whatever). Note that FreeIva also has some functionality for removing gameobjects from internals at load time, which can help with that kind of thing and doesn't require distributing a new model. // Creates a new version of the stock Seat_Passenger prop that contains the internal seat PROP { name = Seat_Passenger_wModule MODEL { model = Squad/Props/PropsGeneric/Seat_Passenger } MODULE { name = InternalSeat seatTransformName = model allowCrewHelmet = false } } INTERNAL { name = mk2InlineInternal_demo MODEL { model = Squad/Spaces/mk2InlineInternal/mk2InlineIVA } // This prop was placed in unity with parttools PROP { name = Seat_Passenger_wModule position = 0.581,-0.358,0.296 rotation = 0,0.7071068,0,0.7071068 scale = 1,1,1 } } // make the part point at the above internal @PART[mk2Cockpit_Inline] { @INTERNAL { @name = mk2InlineInternal_demo } } Placing the prop in unity: s Seat in game: And then here's the same kind of thing but with the module in the prop placement: INTERNAL { name = mk2InlineInternal_demo MODEL { model = Squad/Spaces/mk2InlineInternal/mk2InlineIVA } // Using the normal stock seat prop PROP { name = Seat_Passenger position = 0.581,-0.358,0.296 rotation = 0,0.7071068,0,0.7071068 scale = 1,1,1 // but we put the seat module HERE instead MODULE { name = InternalSeat seatTransformName = model allowCrewHelmet = false } } }

No, it doesn’t use any modded code. This patch just clones one of the stock props and adds a seat module. Then you can place that seat in your internals and they all get modules in the right spot. it is *also* possible to place the seat module directly in the prop placement inside the INTERNAL node, which allows it to use transforms from the seat prop model without having to worry about duplicating or aligning transforms in the internal model.

No, it doesn’t. It can use transforms from the prop model or just the origin of the prop. Heres a synthesized version of a stock seat prop showing one of the techniques: https://github.com/FirstPersonKSP/FreeIva/blob/7483fe7ed01a4607c4a000d674f8b053ebb85c33/GameData/FreeIva/Props/Seat_Passenger.cfg#L16

Oh god this is so much more complicated than necessary. You can put the seat module IN the seat prop (either in the prop cfg or in the prop placement). Then it just goes wherever the prop does.

@Lisias I’d actually suggest putting the seat modules directly into the seat props in the cfg, so that you don’t have to maintain two sets of truth about where the seats are. Much easier to update.

It could, but I tested with restock.

This doesn't happen for me when I use your craft file, so I assume some other mod must be interfering.

Probably cck

Sounds like an installation issue likely, but probably with CCK? Post your log whenever you need help.

Which docking port? Mind posting a craft file?

For this kind of thing I’m going to need the exact names of the parts you connected together. Even better, a craft file and your KSP.log.

Thanks for the report. I’ve filed an issue on github and will check it out next time I do a tweakscale update. I *think* kspie has its own scaling configs? But if the value is showing up in the VAB and then resetting something is probably going wrong at a deeper level than just the cfg.

Getting locked out of buildings is a classic symptom of some mod throwing an exception during the saving process. You need to look at the KSP.log file to see which one.

The first one is just Part Volumes without requiring a restart? Sounds like the feature request should be made to Part Volumes instead. The second should be possible with a kopernicus patch, so not suitable for KSPCF. I’d be surprised if it actually improves performance, but maybe… If you’re looking for better performance when working on a mod, I suggest deleting the DLC, and all stock parts that you don’t need for actual testing. I can boot in ~20 seconds doing that. QuickStart is also helpful to shave off a few seconds of UI interactions.

FreeIVA support for most mods in k FreeIva itself, but BDB and KCHS are exceptions. And it sounds like it’s this issue which was just fixed (though not released) https://github.com/CobaltWolf/Bluedog-Design-Bureau/issues/1407

Hi, please post your KSP.log. Nope. Please post your KSP.log

You can remove the % from MODULE if you want it to just create a new module.