blowfish

Right, because values are always evaluated before nodes. Not ModuleManager's fault, as KSP keeps them in separate lists (so there's no way to know the original order).

Yes. First, delete the config cache (GameData/ModuleManager.ConfigCache) so that MM loads everything from scratch. Then open KSP and allow it to load to the main menu. Then take a look at the log (KSP.log for these purposes and look for lines like this: [ModuleManager] Applying node DeadlyReentry/DeadlyReentry/@PART[*]:HAS[@MODULE[ModuleAeroReentry],#leaveTemp[*]]:FINAL to Squad/Parts/Wheel/LandingGear/GearExtraLarge/GearLarge Probably easiest to search by the last part, i.e. look for " to /path/to/my/part"

It will give you an error. The math operators can't be used with %

Probably because it encountered errors: [ModuleManager] Applying node DeadlyReentry/DeadlyReentry/@PART[*]:HAS[@MODULE[ModuleAeroReentry],#leaveTemp[*]]:FINAL to Squad/Parts/Wheel/LandingGear/GearExtraLarge/GearLarge [ModuleManager] Cannot find key leaveTemp in PART [ModuleManager] Error - Cannot parse variable search when editing key leaveTemp = #$../leaveTemp$ ... [ModuleManager] ModuleManager: 19349 patches applied, found 15 errors 15 errors related to GameData/DeadlyReentry/DeadlyReentry.cfg

Well hmm [KSP Version]: 1.1.0.1228 (WindowsPlayer)-pre ==================================== Looks like you're rather behind on KSP releases. Be sure to opt out of the 1.1 beta so that Steam will download the latest actual release (1.1.2). Also, in general, modding your Steam install is a recipe for unpleasantness. Best to copy KSP out of where Steam installs it to somewhere else (it will work fine) and mod there. Also best not to assume you're on a particular version of anything. It will make debugging a nightmare (as evident here).

You can definitely get download count for a particular file through the Github API. Whether or not that's what you would want here is a different question.

2.6.20 was the last version for 1.0.5. You can find it here.

You might want to read up on virtual methods a bit. There's no loop going on, it's just calling OnStart on the base class. When OnStart() is called on an instance of the derived class, that will always use the derived class's implementation, but you have a mechanism for also calling the base class's implementation if need be, through base.OnStart()

I was under the impression that bouyancy was based solely on drag cubes. Perhaps there's something here I don't know. Anyway, if you want to submit a patch, I'd be happy to include it.

If you looked at B9's own patches, you would see something like @PART[B9_*] { ... } The * matches any characters

The only requirement on moduleID is that each ModuleB9PartSwitch has a unique value. It can be blank if there's only one module. I have definitely tried to use conventions throughout B9. If you're trying to identify parts with fuel switching capability, I would recommend :HAS[#baseVolume[>0]] - that's what I use in B9's own RF/MFT patches.

I'm confused. B9PartSwitch won't touch resources it doesn't know about, so what would be the issue with having those parts use B9PartSwitch for the mesh switching and SSTUVolumeContainer for the fuel switching?

I've been contemplating adding the ability to modify MFT/RF volume for a while, but the truth is that there are very few B9 parts where the subtype actually changes the volume, and then it's usually not by a huge amount. If someone (probably not you or I since this is a large amount of work) wanted to create B9 patches, as a first pass they could just disable the fuel switching on the B9 module and add SSTUVolumeContainer (this is the way B9's MFT/RF patches work currently).

This one's on RO's end, sorry. RO patches are part of RO. Interesting. I'm not sure what the justification for using EC is. My other worry about making the precoolers actually do something is that they're only available in two form factors. It might put some craft with rear-mounted engines in an awkward place.

Wow, that seems like an unnecessarily large amount of bitterness for one post. Could I suggest a clean install of KSP? Hard to say of what you describe is CKAN's fault or not without knowing every exact thing you did (in and outside of CKAN). CKAN's error handling leaves a bit to be desired, but almost no one has problems of the magnitude you describe, so there's probably just something weird in your install. If you have games in progress you should just be able to copy over the "saves" folder assuming you're installing all the same mods.

I think you're looking at size rather than mass. Hydrogen isn't very dense compared to other fuels, so the same size container will hold a lot less of it. If you increase the amount of hydrogen such that the masses of the two craft you are comparing are similar, you should start to see a benefit. Or for the same delta-v (whatever your mission requires), you will require less mass (thus requiring a smaller rocket to get it to orbit).

In Stock KSP maybe ... in real live almost never. Good vacuum efficiency requires having a very long nozzle to expand the exhaust as much as possible. Anyway, what's so bad about having a rocket a couple of meters taller?

That should be sufficient, yes.

@Canis Dirus Leidy Couple of points on that patch There's not way that part could ever end up with ModuleEnginesAJE* - that condition is unnecessary :FOR[RealPlume] should only be used within the RealPlume mod, since it tells ModuleManager that that the RealPlume mod is installed. You're probably looking for :BEFORE[RealPlume]

Possible, but unlikely. There are only a few mods using B9PartSwitch right now, and to my knowledge none of them modify the command seat (and why would they?). If you want to determine the responsible mod, you probably have to do a binary search through your mods - disable half of them, see if that fixes it, if not it's in the other half, keep narrowing down by half until you isolate the mod responsible.

Welcome to the forums! Could you try again and elaborate if the problem perists? Could just be a temporary outage or Github throttling if you've downloaded a lot of stuff recently. I just tried downloading and it worked fine.

@kananesgi Shouldn't be. This mod will only affect parts that have ModuleB9PartSwitch (which is none if you don't install another mod that actually uses it).

And are any of the parts in question actually using B9PartSwitch? It has nothing to do with procedural parts. Looking at your logs (good that you provided them regardless), I don't see you ever placing a part that uses B9PartSwitch.

The precoolers don't actually do anything. The best we could really do is just make them required for the engines to work, but that's not particularly interesting from a gameplay perspective. 1.7 km/s sounds about right ... they should take you to about Mach 5.5 before they seriously overheat (even precooled engines have their limits). What happens in rocket mode after that is outside of AJE's domain. However, it's been called that my attention that that SABRE's specific impulse in jet mode is probably too low. Will look at fixing that at some point.

The heat tolerance is higher, yes. I think it's actually slightly longer than the FL-T100, hence the slight additional volume. But evidently I didn't apply this consistently. I'll see about updating the Mk2 parts ... if I just take the diameter of the round section, they should have 44% more fuel than the equivalent Mk1 tank. I'll probably just round to 50%.