blowfish

There's no stock resource switching, the switcher's presence just messes up the order of unrelated stuff.

Would appreciate confirmation but I am mostly sure the issue I brought up still exists in 1.8.1

I actually really suspect this is related to how the ModulePartVariants variant selector moves its UI to the bottom of the list and doing so in a way that some other logic isn't aware of. There are a couple of things I can do to test that hypothesis. Regardless though, not a B9PartSwitch issue.

@Lisias I think that's unrelated. Based on my testing this issue is specific to having ModulePartVariants on the part and is reproducible in stock KSP without any mods installed. you just need a part with ModulePartVariants and more than one resource.

Any chance you could dig that link up? I think I might be able to get a bit of traction on it...

Update: this issue seems to be reproducible without B9PartSwitch. Any part with more than one resource and the stock variant selector will show it. So it seems it has nothing to do with B9PartSwitch specifically. Will see if it’s been reported yet...

Update from the 1.8 front 1.8 seems to pin the top of the top the part action window rather than the bottom. This eliminates the need to move the switching UI to the bottom of the window (basically, you don't want it to move as you add and remove resources) Unfortunately, there seems to now be some weirdness with where resource items appear after they've been added. This seems to manifest in different ways regardless of whether the switching UI itself is moved to the bottom or not Will continue to investigate...

B9PartSwitch v2.11.1 for KSP 1.7.3 Fix default subtype not activating on the icon

B9PartSwitch v2.11.0 for KSP 1.7.3 Allow switching UI to not be moved to the end of the part action window ModuleB9PartSwitch now accepts bottomOfWindow = false which will leave it in place Modules without this new parameter are unaffected Allow transforms to be scaled TRANSFORM {} nodes now accept a scaleOffset which multiplies the transform's local scale scaleOffset either accepts a single number for all 3 axes or 3 numbers for x, y, z which can be separated by spaces, tabs, or commas Fix plume switching for ModuleEnginesFX Still doesn't support switching in flight Fix Texture switches getting stuck on copied parts Fix node offsets not respecting part rotation when attempting to move the part with the switch KSP 1.8 compatibility will probably come in the next update (should be very soon), just wanted to get one more out for 1.7.3 with these changes, particularly since the 1.8 version will not work with older KSPs

I think that's supposed to be Vanguard-Able (though I don't think they called it Able there)

Well your main problem is PART vs Part (it's case sensitive) But I'm having trouble figuring out what you want the patch to do, if the module exists you'll end up with duplicate moduleID, textures {} and objects {} ... looking at the differences, maybe you want something more like this?

Just out of curiosity, what bothers you about rocket engines taking a few seconds to throttle up?

Big lingering smoke trails like that typically only happen on solid rockets, and I know RealPlume has some smoke trail on its solid configs.

Only because it's been memed about so much in the context of BDB...

Found it in the log ... you have installed B9_Aerospace_Legacy without the rest of B9 (HX does not require it but legacy does)

Ah yes ... texturing ... the easy part Seriously though, you've really made that model come to life with the textures.

B9PartSwitch v2.10.1 for KSP 1.7.3 Add missing Russian localization keys Fix surface attach node modifiers not actually doing anything Fix surface attach node modifiers checking whether the part allows surface attach to it rather than to parent part

Hmm, could you provide your log after running KSP, seeing this, and then clicking OK? Maybe something unexpected is happening when you click that.

Does the OK button appear but doesn't do anything, or does it not appear? Maybe the window is ending up taller than the screen? I guess a screenshot might be helpful.

Yeah, so somehow Unity itself is crashing. It does seem to be somehow related to PartDatabase.cfg though ... all ModuleManager does is remove that file forcing KSP to regenerate it, which usually works fine, I admittedly don't know what could be different on your system. Does anyone else here have more insight?

@MulDoom could you get output_lot.txt? It tends to include some info about actual crashes that KSP.log doesn't. It should be in AppData\LocalLow\Squad\Kerbal Space Program\ from your home directory

I'm not too familiar with this module. A good place to start would be to check ModuleManager.ConfigCache and ensure that the final configs look the way you want them to (including spelling and capitalization)

What were you trying with? For something like a Centaur (especially single engine centaur) you're going to have to loft high on the booster in order to have enough time to get to orbit, and that's true IRL as well.

I made a couple of edits, as KerbMav said you don't want the nested @PART nodes, also you were missing a bracket. The [*] after @PART is fine but also isn't necessary, it basically says "has some name value" which all PART nodes do

No problem on hearing it again though, part of how I gauge the value of new features is trying to see how often they'll be used. If you have another use case then that's another reason to build it.