blowfish

Regarding PartCategories.cfg... The fact that KSP saves to it means that it wouldn't really make sense for a mod to edit its contents with a MM patch. The changes in the patch would just be written to the actual file on the next save. However, there's nothing that prevents them from doing this currently as it's read from the game database. It seems like it might make sense to blacklist it

Nope, nothing newer. What do you mean "better works with FAR" anyway? Are you seeing a particular issue?

Since the node only has 6 values, just add it on to the end as a string @node_stack_top ^= :$:, 0: To briefly explain what's going on here, ^= tells MM to to replace something in the string. Next is :XXX:YYY: which says "replace XXX with YYY". Now, $ signifies the end of the string (since you want to add it to the end). Then ", 0" is what you want to add on. I'll add though, that rescaleFactor won't affect anything you're doing here. That, and most other scaling is done in KSP's code, not in the configs. So you'd really be fine to just replace it.

I dug a bit through the code and it looks like or "|" isn't supported for HAS blocks. @sarbian could confirm, but I think this is the answer.

That looks wrong to me. The second HAS block is supposed to apply to the MODULE, and you've got some extra closing braces.

Yeah, unfortunately with the U5 wheel collider stuff the landing gear would have to be completely reconfigured, and right now I don't even have the time to figure out what would be required there, let alone actually do it. Especially without access to the original models. If someone else wants to take a stab at it though, I and I'm sure everyone else would greatly appreciate it

@Rayder You're probably right that it's removing yours too. What you can do is set some flag in your node and check for it when deleting.

@StickLabs Still no idea what's going on. Please describe in detail the exact problem you are having and then post your either log (uploading to Google Drive/Dropbox/similar then sharing and posting the link is a good way to do it). We'd all like to help you but your post is rather difficult to decipher.

Probably because stock heating is balanced for the stock system. If you enter at much higher speed, it isn't going to behave the same way. Try turning down re-entry heating in the difficulty settings.

Actually, since I've encountered this error a couple of times myself, some guesses as to what it might be: Part cost has to be an integer now for some reason The 7th value of node definitions (size) (and any following values if you have them) needs to be an integer If it's not either of those I can still take a look

The error is probably in the config actually. Would you mind posting it?

Okay, exactly what parts do you expect to be there that aren't?

Are you running KSP out of C:\Program Files or Program Files (x86) ? Windows sometimes restricts writing to those locations in a way that prevents KSP from writing the log.

Pretty much everything looks fine there. Are you sure they're not showing up? Try starting a new sandbox game, and look in the structural tab in the SPH or VAB.

I don't know the cause of that, sorry. And I'm away from home this week so can't really do any serious debugging. But if you follow the normal steps for getting support (post logs etc, explained in the support link in my signature), someone else might be able to help you.

Welcome to the forum! I can't immediately identify a problem from your screenshots, so I will need to see KSP's log to understand what's going on. Instructions on how to find and upload it are in the "How to get support" link in my signature

Logs then? The IVAs and portraits work fine for me.

Can't reproduce this issue on the latest release. Not sure what would have changed from the last one, but if the issue persists after moving to 1.2.2 and updating you mods, please verify that stock engines behave different than B9 engines in this scenario and provide a log.

Well that's a place to start at least. Which engine were you using? Welcome to the forums! The HX pack contains the blocky sci-fi parts you may see in some pictures. Do you have the latest version of RPM installed? Should be 0.28.0

Interesting. My guess would be that the part upgrades are parse from the game database before MM has a chance to run. In that case, ModuleManager would need to force them to reload after applying all of the patches (I think something similar is done for resources). @sarbian thoughts on this? I can do some research if need be to figure out exactly what would be required.

It should function just like any other node. I'd check the log and config cache to see what's going on...

I'll look into the crossfeed issue, but I don't see any major differences in the configs that would point to what's causing the issue. As far as I can tell, everything relevant is the same as the stock docking port.

Could you log an issue for this at Github? I suspect that it's always been this way and that the warning is harmless, but probably worth just putting a placeholder texture there to suppress it. It's set up the same way as the stock docking port. Does the "disable crossfeed" button show up? Is it not working? (as always, more detailed bug reports are helpful!)

Yes, it depends on the most recent release of SmokeScreen. That version is included in the download. Maybe it means a couple of people will post here asking why their effects aren't showing up, but the answer is known, and there's really no reason not to update.

I know you said ignore, but just for future reference I will explain how this works. The key point here is that PROPELLANT is a feature of MODULE[ModuleEngines] and not of the PART itself, and that you can nest HAS blocks @PART[*]:HAS[@MODULE[ModuleEngine*]:HAS[!PROPELLANT[MonoPropellant],!PROPELLANT[XenonGas],!PRPOPELLANT[AblativeOil],!PROPELLANT[IntakeAir],!PROPELLANT[IntakeAtm]],!RESOURCE[SolidFuel],!RESOURCE[Karbonite],!MODULE[ModuleEngineIgnitor]]:FINAL Note that the @MODULE[ModuleEngine*] has its own HAS block, and that is where the PROPELLANT checking is done.