Gaius

Well, you can, but only if you have an infinite number of them...

Does the generator actually deliver 300% power under those circumstances? If you ask it to deliver more power than it should, and it does, then yes, it should overheat. If you ask it to deliver power for more drills than it should and instead of doing so, it just delivers its rated maximum power and no more, it should not overheat either. It should only overheat at >100% capacity if it's actually doing >100% work, or where's the extra heat coming from? It's not actually doing any more work, despite your demands, so... Basically, if the amount of power it delivers is dependent on the number of drills you connect, then yes, it should overheat if you connect too many. But if the amount of power it delivers caps out, and does not increase when you turn on more drills, it shouldn't burn any hotter when you do, it ain't doing any more work regardless of how many drills you try to split the insufficient power between...

"Impressive. They can make planets." -- Maltz

I did notice that if you still have parts with the old MODULE { name = TacFuelBalancer } in their config (as my command pods all did), it still puts the "Show Fuel Balancer" button in the right-click menu, but it doesn't work. I prefer the new partless interface anyway, but I wonder if it wouldn't be possible to support both methods: if there's a part on the current vessel that has the interface, don't draw the button so people don't have a cluttered UI if they don't like that button always being there -- but if no part has the interface, put the button up so the fuel balancer is still accessible? Not sure if that's even possible but if it is, it would basically give you the best of both worlds, and people can either use the part or not as they prefer...

I find that quite counter-intuitive, actually. Red is the lowest perceivable frequency (below that is infra-red), whereas violet is the highest (above that being ultra-violet). Roy G. Biv says red=low, violet=high. The exception being when you're trying to indicate something negative/bad, e.g. redlining or red alert or any indication where "higher" means "worse" (in this case, the inversion because "higher" means "lower" in a sense -- lower safety = higher danger, the situation is going downhill, you're indicating a high depth, etc.).

Well, I've seen what I assume is the same bug affect engines with only 800 ISP (as mentioned previously). I assume it affects any engine, it's just most noticeable when the engine's ISP range is so great. When it happens to normal engines, odds are you don't even notice. When it happens to an engine with a minimum ISP of zero, the fuel would disappear in an instant, right?

Personally, I only count it as a stage if there's a decoupler involved. Parts falling off is a "variable geometry vehicle".

That was fast! You are made of pure win.

Okay, I removed EVERYTHING from GameData except the Squad folder, ModuleManager.dll, and the following test file, called customize.cfg: @PART[probeCoreCube]:Final { @rotPower = 0.0 @linPower = 0.0 } Also went through the legacy plugin folders and made sure there were no plugins there, either. This should be a complete stock version of KSP now, nothing added except ModuleManager.dll. Still doesn't work, although instead of ALL the parts disappearing, only most of them disappear. Saved the log to here... Looking at this log... it probably comes as no surprise, but -- the parts that don't disappear are the ones that load before [LOG 02:37:19.035]. The ones that disappear are everything that tries to load after that. Something is being clobbered during that change that makes the loading of every subsequent part fail...

For me, it's definitely all parts, both stock and addon (and my addon parts outnumber the stock parts normally). My debug log looks pretty much like pictured above, except every part, not just the stock ones, follow that pattern: [Log] PartLoader: Compiling <whatever> [Error] PartCompiler: Part config requires value 'name' is defined [Error] PartCompiler: Cannot compile part <...over and over and over...> And definitely just the one ModuleManager.dll: <skyhook> ~/Software % find KSP_win -iname modulemanager.dll KSP_win/GameData/ModuleManager.dll

Okay, installing the latest version causes all of my parts to disappear. Reverting to the previous version brings them back. EDIT: Moar testing... Reinstalling version 1.2 caused all my parts to disappear. Removing my customize.cfg made them reappear. Adding one with a single modification (included below) made them all disappear again. @PART[cupola]:Final { MODULE { name = MechJebCore } } Debug console shows the part compiler failing on each and every part, complaining that 'name' is not defined.

Actually, the links in the first post are entirely messed up. The one that it says is for kerbalspaceport takes you to mediafire (3.1c), and the one that it says is for mediafire is actually to "..."

Ah, okay, that makes sense. At least, as long as the part shows up with the appropriate resources it needs. e.g. if you're using that rocket that comes with 10 Thorium in it at launch and can't be refilled, it can still work with this... EDIT: Talking about this engine. It's supposed to have the resource in it when constructed. Once it's empty, the engine is not usable by design... I must have explained it poorly. It would work with any mod done the way I was thinking, it would just waive the requirement for any resource it doesn't recognize, supplying it exactly as the part.cfg specifies, unless the mod author defined the node for your mod saying not to.

Yes, it's compatible with 0.20, but not designed for 0.20. Install it in the legacy folders.

There are really no right or wrong names for what folders you organize parts into. Use "Gizmos" and "Doodads" if you like...

Wouldn't it be more reasonable to default the other way around? If this mod doesn't know what a particular resource is, it should probably not require it to be supplied. So if a rocket has a part that requires KIntakeAir but the mod doesn't know what that is, it just ignores it, but if maker of SuperTimeSphere mod wants this mod to require Element115 be on hand to make their rocket, they can define the node to add the rule. I.e. the mod should maintain a list of requirements, not exceptions, and mod makers can add to the requirements list rather than add to an exceptions list (that most mods won't know about and never add themselves to, making them incompatible with this mod).

Very nice. I've love to see a bicoupler, too, for extending two 2x1 parts from a 2.5m circular base.

Brilliant! Thanks. One bug report, and my apologies for being vague as I haven't exactly nailed down what's causing it: but occasionally it gets into a state where I can no longer make changes to my tabs. I mean, I can make them, but if I leave the VAB and come back, everything is reverted to exactly like it was before I made them, and if I try editing at that point, the editor seems to be a little bonkers (sorting by mod lists the same mod multiple times, parts are all over the place, etc). The problem seems to occur when I make changes to which mods I have installed. I think it might be related to the tag list having parts in it that no longer exist. At that point, the only way to get it working again is to go delete "catalog.txt" and recreate it fresh with the current part set, after which it works fine (until I fiddle with my mods again). EDIT: I should add, this was with 1.1b. I'm just downloading 1.1c now... EDIT2: Okay, it has nothing to do with parts that are removed. It seems to occur when I update a mod that has a part added. Specifically, UDKLD's Large Structural Components gets a new part added every day or so. I update to the latest release, load up KSP and attempt to add the new part to my "Miscellany" tab that has that and a few other mods under it. The new part goes in fine for the moment, but if I leave the VAB and go back, it's gone again. The only way to get it in permanently is to delete and recreate the Miscellany tab. The editor going bonkers is an separate, unrelated bug. That happens any time I sort by mod and "-" everything. Leave the VAB, come back, and the display is a complete mess, but hitting the Sort button a few times fixes it. Both of these problems still occur in 1.1c.

Mods have been known to include their own parts before...

If you do, please do support regular expressions. It's a good solution to the problem of pattern matching, and enables you to give very specific and robust instructions on exactly what you want matched. The existence of many mature and debugged libraries would help I should think... although I'm not familiar with what libraries are usable with Unity.

...and that's the coolest thing I've seen in KSP in ages...

It would be nice is there was also some way (shift-rightclick?) to create a union instead of an intersection.

There are no words to express how much I love you right now.

It's not true for any stage or launch vehicle, but it's true for many vehicles, and it's not unique to KW, I see the same problem with Core Anvil rockets. MechJeb seems to be horribly confused by fairings. I'm constantly flying around with the system telling me my current stage's delta-V is zero, usually because the next stage contains fairings. Autostaging just stops when it gets to them, too, although that may be intentional. Sometimes it just says my delta-V is zero when there are no fairings, though. Again, nothing to do with KW -- happens pretty often with rockets with no KW parts as well. Not sure what causes it -- I've had identical probes both have working delta-V displays or not, depending on the launch vehicle (which has now been left behind, so why the now identical probes have zero delta-V in one case and not the other is unclear but apparently related to their history and not their now identical current configurations). I suspect it might have something to do with the "root part", which changes sometimes depending on how I launch particular probes. MechJeb was completely flummoxed by my Jool MapSat package (sending half a dozen probes on one vehicle), and even after separating so they were now perfectly indepedent, single-brained bog-standard space probes, MechJeb could not autostage when the lower stage ran out of fuel, and displayed delta-V of zero for every stage and as the total. But it seems to randomly bug out on perfectly normal things, too, from time to time, so I dunno...

That's what she said!