AccidentalDisassembly

This will (probably) fix it for all parts, if you prefer: @PART[*]:HAS[@MODULE[ExWorkshop]]:FINAL { @MODULE[ExWorkshop] { @name = ELWorkshop } }

Things like MFT and fuel switchers are, if I remember correctly, incompatible with KR&D. Edit: as it says on the front page:

Small bug to report - on many if not all stock tanks where IFS allows for switching to xenon, resource amounts end up being 1 xenon per 1 unit of LF/OX volume in the tank originally. This is off by a factor of ~18-57 (depending on which stock parts we're supposed to take as models). For example: in the FLT100 (100 LF/OX volume), switching to xenon results in a tank that holds 100 xenon. It should hold about 5700 xenon going by the stock PB-750 (or whatever it's called). My guess is that somewhere in the patches, the Xenon resource value was set to 1 * the original LF/OX volume...

I'd just release as you finish. No point in holding out unless it makes it a pain for you in some way; you don't have to have NFC to enjoy the other mods, so no sense in waiting. Just my $0.02.

So... one mod? It's quite a popular one, to boot.

Not sure what exactly you're talking about, what mods are you referring to?

Still having problems with large scales - could be my config, who knows. EDIT: I was wrong. Some funny stuff happening still at large scales, but it's related to symmetry. One 4x-scaled part moves OK, 2 placed in symmetry --> phantom forces begin moving the vessel while it's sitting on the launchpad, and attempting to move the (symmetry) parts makes them blow up. EDIT2: Also, there's a KJR dll still included in the MagicSmokeIndustries Folder, and another similar DLL in the KJR folder. Something went wrong with divvying these up, it seems...

Hmmmm.... were needed?

I didn't have any opinion on it before, but frankly, now, it makes zero sense (to me) not to integrate mission building and the contract system. Huge missed opportunity for fun stuff to do in the game as opposed to something that's more or less like another game-within-a-game. Obviously there might be a lot of really good programming reasons (or something) not to do it, maybe it's impossible given constraint X, blah blah blah.. but in theory/on paper, it's a truly bizarre decision to divorce missions from the rest of the game, and you have to wonder about the thought process. Another example of bizarre decision-making evident in the latest versions: separating the process of choosing variant themes into its own "thing" as opposed to simply being able to change themes will still looking at the parts you're theme-ing...

OK, well then maybe *I'm* making some wrong assumptions...but I though the "occlusion" simulated by KSP works when it's the last part at the back of the craft, but not when there's a mismatch and another part behind the one that doesn't match (e.g. big part, small part, then another big part). Maybe this all changed? I don't know. But it seems like the first and second cases should in theory be at least a little bit "occluded" (quotes because, as you say, it's just a simplified model), while the third one actually should produce a little more drag than the first two...

You are making a nonsensical assumption within the context of the game. Analogy: If you draft behind a semi on the highway (the tanks), and if you radically simplify the model of drag you use so that it's more like the game's (which simply looks at parts' sizes to figure out whether one's big enough to "push the air out of the way" for another behind it), why would drafting with a narrow car mean MORE drag for you + the semi together than if you were drafting with a car the same width as the semi? Isn't the semi still moving the air out of your way for you? It's not mismatches that create more drag, it's the cross-sectional area (width of semi/tank) hitting the air in the first place. On the other hand, if your car was WIDER than the semi (as the engine bell is WIDER than the tank in the third example), wouldn't that mean more net drag on the combined "craft"? Bigger overall cross-sectional area, because now the craft is wider? Obviously that's a reductive analogy - but KSP's drag model is a reductive model, so...

Time for GitHub! EDIT: Or... just naming the ZIP files differently, that could be helpful work too...

If you did, it was by doing something not reflected in the TweakScale configs, or something... For me, same story about the 1.5x scaling - that or bigger and it won't move (probably due to node sizes as before). In the TS configs I'm using, TWEAKSCALEEXPONENTS tries to control the node size, but I'm not sure how to write the config correctly to make it do it right. EDIT: Im' taking the attachNodes { size = 0 } from the config included in your DL: SCALETYPE { name = IR_Standard freeScale = true scaleFactors = 0.25, 0.5, 0.75, 1.0, 1.25, 1.5, 2.0, 3.0, 4.0 incrementSlide = 0.025, 0.025, 0.025, 0.025, 0.025, 0.05, 0.1, 0.1, 0.1 defaultScale = 1.0 suffix = x TWEAKSCALEEXPONENTS { mass = 2.2 attachNodes { size = 0 } } }

In short, you rewrite the TweakScale configs (replace them). However, it seems there are still scaling problems in the most recent 1.4.1 version (so far as I can tell), so you still won't be able to scale beyond about 1.5x. I'm getting no movement for larger-scaled parts, and weird movement for very small-scale parts now... The limited values that can be applied right now were chosen because previous IR developers did not try to work around certain scaling limits created by the weird way KSP does joints. Some values were chosen because of the relative sizes of specific elements of the stackable extendatron models. Other values were chosen simply to line up with those values. I'll be creating a customized TS config for my own use, which I'll share if others want to use it too, but it won't do much good yet.

Not according to the thread title!