blowfish

Welcome to the forums! What you should pay attention to are the dependencies. B9 Aerospace itself is almost exclusively parts, and rarely breaks with KSP updates but the plugins it relies on often do. Once they're all in place I'll do a release, mostly to satisfy CKAN/AVC concerns.

Unfortunately it looks like that info comes from a place shared by all instances of a part. There might be some hacks that would make this work but I don't really like them.

Yes, big surprise that code that is no longer run synchronously in the foreground no longer inherits from LoadingSystem. My recollection is that Ubiozur called ModuleManager in an unsupported way. Kerbalism also had an implicit dependency which broke in MM 4.0, but we worked with the author to find a good long term solution (hint: it wasn't reverting anything in MM)

If that mod has a conflict, it’s up to the author to reach out, build a shared understanding of what the problem is and to discuss possible solutions.

Plugins compiled for KSP 1.8+ will not work on previous versions of KSP. This includes SmokeScreen.

Look around. You'll see that yours is not a majority opinion among modders or players. And there aren't enough players who feel this way to for modders to waste time making the switchers optional. Even stock KSP has switchers now (although they're mostly only visual). So B9PartSwitch is here to stay, if anything its usage is going to increase in the future, and you'd best get used to it.

Pretty much stuck with what's there, I have not done any art for this mod.

This hasn't changed. Maybe something else on you computer is intercepting those keystrokes?

Well the brackets will definitely break your patch.

@juanml82 why the brackets around your delete statement?

ModuleManager can't operate on craft files.

@Lisias Start with a problem statement. What information do you need to see and what steps do you have to go through to get to it in stock MM. Be specific. Every actual change has to be motivated by a well understood actual problem, and you can try and propose solutions to poorly defined problems all day but nothing is going to change. @Warezcrawler @PART[mk3CrewCabin]: not the trailing : @severedsolo nested HAS is completely valid

Well, perhaps you could actually explain the problems you have finding info with stock MM. Because despite going back and forth for several posts about this, that information has still yet to emerge <snip>

Okay, well if you're having trouble finding the information you need, maybe start with what information you're having trouble finding. I've read plenty of logs and haven't had any issues but I also understand what MM is doing better than anyone.

@Lisias I think you're missing that what I'm describing is how ModuleManager currently works. This is not theoretical. And it's been this way for a while. And I've had to read plenty of users' logs since then so I know exactly what the experience is like. As for figuring out when things actually happened, every one of ModuleManager's log lines comes with a timestamp of when it actually happened. If there's an exception in applying one of the patches, that's going to end up in the MM log (and eventually copied to KSP's log). If the patching thread (or one of the logging threads) crashes (i.e. an unhandled exception), that's also monitored.

It was a mess before. The 2.80+ UI actually seems better overall, although it's still largely the same labyrinth that Blender's UI has always been, just a lot of things move around and a few paths straightened. I still haven't gotten used to all the changes, but then I have spent much less time in 2.80+ than I spent learning the 2.79- UI, and learning that took a very, very long time.

Trust me, you don't want patching messages intermixed with model and texture loading messages. ModuleManager runs on a separate thread and what KSP is doing in the foreground (loading models and textures) has no bearing on what ModuleManager is doing. The report is the log. ModuleManager's log is copied to KSPs log after MM finishes, at least for now.

They're relatively new. Since MM runs parallel to model and texture loading now putting things directly in KSP's log would create an incomprehensible mess. So it logs to a separate file and copies it into the main log later. There's a chance we could decide to remove that final copy at some point if knowledge of the separate MM logs becomes common enough. Also quick note about those logs, the content of MMPatch.log and ModuleManager.log are almost the same. MMPatch contains only the result of patching, the other one contains that plus everything that happens around it (cache checking etc). The reason is so that we can still have a record of what patches were applied even when loading from cache.

The parts pack is a separate mod. While it makes sense to use them together either can be installed and used without the other - they are installed separately.

Well look at that, I was all ready to release a few days ago and just forgot to run the script. B9 Aerospace v6.6.0 for KSP 1.8.x Remove references to unused textures Replace remaining FSanimateGeneric with ModuleAnimateGeneric Add default action groups for cabin lights

Sure, but there's an established pattern there where everything is called ModuleEngines* which makes it patchable

@zer0Kerbal that seems like a reasonable request. While it's possible to get things in the right order with MM patches, it can prove tricky to get right, and probably pretty brittle (likely to break) when changes happen. It's going to require some code cleanup first so please open an issue at Github and I'll try to address it when I can.

As convenient as it might make things, this goes strongly against the current design philosophy of ModuleManager. MM currently has no concept of what a PartModule, Part, etc are or how they are used. All it sees are nodes and patches, it modifies arbitrary data and then lets KSP parse useful information out of that data. It might be more worth your time to look at the structure of these modules, to me this points to them violating the principle of composition over inheritance. If there's a shared concern between all these modules maybe it should go in its own module. Or maybe there's jus one module and the specifics of it are plugged in dynamically based on the data.

That's a RO question, not a BDB question. RO support is maintained in the RO repository, not individual mods. That being said, RO does have configs for BDB but they're somewhat out of date and have some issues at present.

I don't immediately see what's wrong, however the real warning should be farther up in the log (what you posted is just the error/warning counts it prints at the end). If you can't find it just post the full log and I'll look through.