blowfish

@kcs123 It has nothing to do with B9PartSwitch. The cargo bays use the stock ModuleAnimateGeneric. If it were in my code, I could fix it. I suppose I could completely re-implement ModuleAnimateGeneric but I have very little interest in doing that. Re: Mk2 fuselages: The stock ones have an oddity where they don't hold any more fuel than the equivalent-length Mk1 sections. Especially since even the round section has a larger radius than the Mk1 parts. Maybe double is too much (even though the parts have enough physical volume to justify this), but the stock amount also seems wrong. Re Mk1 0.5m fuselage: It should have 104 volume units. If it's showing up as something else, then there must be a patch modifying it.

B9PartSwitch now has its own thread. Please direct all inquiries about that plugin specifically there.

B9 Part Switch About B9 Part Switch is a plugin that allows mods to make parts switchable, similar to Firespitter and Interstallar fuel switchers. This mod doesn't do anything by itself, but provides a way for other mods to enable switching. Features Parts can switch their resources, models, stack nodes, textures, heat tolerance, surface attach position, crash tolerance, and many other fields Mass and cost can be modified Tanks used to switch resources are defined centrally to allow easy modification and minimal setup Easy to read, easy to write configs Configs are designed for easy patching by ModuleManager Unlimited switchers can be defined on the same part, provided that they do not conflict Download Download Latest Version from Github Also available on CKAN Latest development builds can be found here. Please only download if you have a specific reason. Development builds are not guaranteed to work. Troubleshooting If you are experiencing an issue, please read this topic, if you have not already, on how to get proper support. Incomplete support requests will not be processed. Most importantly, include logs. Source On Github Requirements Each release of B9PartSwitch is intended to be run with a particular version of KSP. Please only use that version. If you have an earlier version of KSP, find the correct download for that version. All previous releases are listed here. B9PartSwitch requires ModuleManager to work. Documentation Wiki in progress. Feel free to contribute. Changelog On the wiki License B9PartSwitch is licensed under the GNU Lesser General Public License Version 3.0 Authors @blowfish Main developer @bac9 author of Part Subtype Switcher, upon which this is heavily based And all others who have submitted fixes and enhancements

@Kolago I don't believe that's possible, no. Unless you want to make a separate patch for each possible position.

No, it doesn't touch save files. You don't want to rescale the solar system on an existing save.

I don't think it has anything to do with the mesh other than the animation. In any case, I don't have access to the Unity files so I can't change that. It's possible that some combination of all those true/false fields could make it work properly, but I tried to figure that out and I could not determine what it might be, and I don't have the time or energy to go through that again.

@kcs123 The problem isn't getting ModuleAnimateGeneric to work. It's used on all the cargo bays currently and works fine. The problem is adjusting the deployment parameters so that the deployment limits actually work the way they're supposed to. When I tried it, they ended up being very glitchy, so I just disabled the deployment limits. I think the problem may have to do with whether the animation starts open or closed, but I'm not sure.

This is due to an edge case stock bug. As it stands, dependOnEngineState default to false, which means that the animation depends on the vessel's main throttle, however, trying to access that causes NREs in the editor. Setting dependOnEngineState to true is really better anyway. I can provide more info on what the parameters are and how to use them if need be.

Probably? It strengthens joints between all* parts *there are a few exceptions for certain parts with specific modules

Almost all of the cargo bays use ModuleAnimateGeneric now. I tried to get the deployment limits to work, but I think the deployment direction is reversed compared to the stock bays ... I couldn't get it to work and gave up. If you want to mess around with the parameters to see if you can get it to work I'd definitely love to see the results

Yeah, that issue has been brought up in the past. I think CKAN removes the directory as long as there are no files in it, but plenty of mods store settings somewhere in their directory, so in those cases it ends up not getting removed.

MM does look for directories. This is documented.

Sure. A while back I split out the HX parts (big blocky ones) in to their own pack. They're the only ones that actually use that tech tree node, so the patch came along with them. You can see it here.

Because it should be :HAS[@MODULE[ModuleReactionWheel]]

The NEEDS[B9_Aerospace] should probably be changed to a NEEDS[B9_Aerospace_HX], since that's where the node is defined now.

Oh, and I forgot, welcome to the forums!

All previous releases are available here: https://github.com/ferram4/Ferram-Aerospace-Research/releases. Looks like the latest version for KSP 1.0.5 was v0.15.5.7.

That shouldn't be too hard. Can I ask what the use case is though?

Some of them are, but they're 100% normal. If you're crashing without an exception, it might be the infamous mystery crash, particularly if it happens when deleting a part or at scene changes. This exception has been reproduced sporadically on all platforms and for both modded and stock installs. It seems to be very configuration dependent too - changes such as removing or even adding a mod can cause it to appear/disappear.

I know that OPT has a lot of exotic engine types that AJE isn't really designed to support. AoA Tech maybe ... what engines does it have? If you want to try it on your own, I tried to explain all the parameters in this post:

@PROPELLANT,* will get all PROPRLLANT nodes.

True, but the lack of documentation in KSP is a larger problem.

MM will only use the cache if no configs or plugins have changed. It will also tell you what changed in the log.

@Diazo How can that work? If you're writing to the file, but other mods can change it, then couldn't whatever you save could be clobbered by a patch and never take effect? Maybe there are some settings you want to be controllable by the user and some you want to expose to other mods?

Only way to fix this is to keep checking and alert the mod authors when it happens. ModuleManager tells you what changed on each database load, so it's pretty easy to figure out from looking at the logs. Eventually hopefully we can eliminate most of them, and possibly raise awareness of how things should be done.