AccidentalDisassembly

Huh... something is REALLY buoyant here: h latest DL on a more or less stock 1.5 - all of those nubbins (EDIT: and the saddle tanks, and the main Tundra tank...) are full of lead, too... super-buoyant ISRU, service bay or cargo tail, maybe...? Or just need MOAR LEAD (There's 1820 lead currently loaded in that craft)?

I use this handy dandy python script to find stuff in every folder in my GameData, if that helps. Disclaimer: not a coder, don't really know Python, just got curious: import os import fnmatch import sys import codecs folderpath = "C:\\Games\\Kerbal Space Program\\GameData\\" configFileList = [os.path.join(dirpath, f) for dirpath, dirnames, files in os.walk(folderpath) for f in fnmatch.filter(files, '*.cfg')] print('\nThere were ' + str(len(configFileList)) + ' config files in that folder.') def checkConfigs(): for elem in configFileList: char1 = '{' char2 = '}' filePathName = elem fileContent = open(elem, 'r', encoding='utf8', errors='ignore').read() numOpenBraces = fileContent.count(char1) numCloseBraces = fileContent.count(char2) if numOpenBraces != numCloseBraces: print('Check ' + str(filePathName)) checkConfigs()

Small note - in CryoTanks\Patches\CryoTanksCTT.cfg, there's an extra closing curly brace that may or may not bork some patches. Dunno how MM handles extra stuff like that anymore.

Small note - in these two files, a curly brace is either missing or there's one or more too many: AirplanePlus\Parts\Command\cessnacockpit\partcabin.cfg AirplanePlus\Parts\Structure and Fuel\r22set\mk3s1.cfg

Just a heads up: in these two files, a curly brace or two is either missing or extra: GameData\002_CommunityPartsTitles\localization\en-us_mk2ex.cfg GameData\002_CommunityPartsTitles\localization\en-us_patch_kfoundries.cfg

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!

... I would assume that this might be because there is no Kopernicus version compatible with 1.4.1, but I could be wrong about that.

I think the fact that the OP thread title still says 1.3 might contribute to people's confusion...

Seems to work. I recompiled the HabUtils dll just in case, and I have no idea if I actually did that correctly (because I don't actually know how that stuff works), but with that simple recompile, stuff moves around and expands in flight and whatnot. But: no extensive testing, to be sure.

Okie dokie, no prob. That's one thing I can't remember seeing a definitive answer to - can the stock system not switch fuel / modules / anything but meshes, textures, and nodes? If not, you've got to wonder... why the heck not?

If you want, I can help out by changing all the mesh switching stuff (like for the lift fan engines) over to the stock system. I gave it a try on one engine and it seemed to work. If you give the green light, though, what repository do I do pull requests for? the dev one? have barely started learning how to GitHub... EDIT: I mean, it might be pointless to do since B9PartSwitch will probably eventually get updated, just throwing it out there.