AccidentalDisassembly

Word. I could see how that might get very complicated - many possible combinations. Door on only one face; symmetrical version with one on each side; doors on other face, etc. Maybe even a door on the end of the part.. that's a lot of doors to animate and whatnot. However, they would be very cool. Currently in the process of attempting to construct a 50,000-ish-ton gigantic tweakscaled 6x-size space carrier of doom in Kerbin orbit. Add me to the pile of people who think you've done an awesome job with the mod!

Just a suggestion - the braces on hollow parts (pic) prevent creating long, open bays and whatnot where a very long object could enter/dock via the side(s). Would it be possible to have yet another mesh option on those without those bits, throwing structural strength to the wind, or would that be a gigantic pain?

Seem to remember some talk about HX-style bridge / cabin parts a while back. Dunno if this is helpful, but it seems to me that the HX end piece already kind of looks like a bridge...Maybe you could just texture the bit crudely outlined below as glass? Could do something similar with the other end piece. Just a thought, am sure you already have ideas of your own:

An update on what I mentioned earlier re: MFT + TweakScale causing strange mass problems. I have since migrated to 32-bit, and have not experienced the same problem exactly. However, I've experienced something else that may or may not have anything to do with anything. EDIT: Actually seems like it might be vaguely related. With a different tank than below, adding in symmetry to the VAB and tweaking upward in scale caused ludicrous mass increases, then tweaking upward in scale once more caused tanks in the part to disappear. This is also hopefully captured in the output log below. New issue: with certain parts, scaling the part up does not increase the amount of fuel/resources inside the part like it normally does. This happened for me specifically with a couple NovaPunch tanks. It is possible to simply tweak the amount of fuel to full in the VAB to solve this. Mass etc. seemed normal, unlike problem I was having before. Does not have to be in symmetry. Tweakscale 1.43, and I *think* all my other mods are updated. So many! Parts it happened with: HH-500-A short tank, HH-500-C long tank, HH-500-B mid tank. Couldn't find any others that had the same problem, but doesn't mean they're not out there. Possibly related, or not: Certain other parts, like the NP_interstage_375m_5m_tank interstage adapter thing, have no fuel tanks when added to the VAB. I couldn't find any problem in the MFT config for the part, or the TweakScale one, or the part itself, so I have no idea what's up with that. A tank can be added with MFT, and it seems like it has vaguely the right volume,but it doesn't begin with one. Anyhoo, steps to replicate: 1. Put one of those tanks in VAB. 2. Scale it up: watch fuel/ox numbers not go up with the scale. 3. Put one of the interstage adapters in the VAB - no tank in it. I have a ton of mods installed, as you'll see: here's an output_log with multiple tests of different tanks in it: https://dl.dropboxusercontent.com/u/59567837/output_log_TS_MFTstuff.txt Sorry if this has nothing to do with TweakScale, but it seems to interact with it in some way, so figured I'd post here for lack of any other ideas. EDIT: Also thought I should mention, though you're probably aware of it already, that TweakScale works, but not optimally, with the kind of tank switching that the new B9 5.0 pre-release does. What happens is this: Add a tank to a part by cycling through its types, THEN tweakscale the part - no problem. Tweakscale the part, THEN add a tank to it by cycling - tank contains as much of Resource X as it would have at the smaller size. So long as you add tanks, THEN scale, it *seems* to work OK. Hopefully that's helpful in some way. M-M-M-MULTI-EDIT! Apparently there are also specific parts from the new B9 packs - the low-profile adapters - that are immune to TweakScale. I have an MM patch meant to apply TweakScale to them, but no GUI element appears in the VAB.

Are there any settings one can change or secret handshakes that make OpenGL perform as well as non-OpenGL mode (DirectX?) does? For me, it works as advertised - lots less RAM used - but my framerate goes down quite a lot for whatever reason.

I was looking through the parts to see which ones would make the most impact if they were removed - I found that just 8 textures are responsible for 100MB on disk. Almost all the textures are 4MB or 3MB or less, but those 8 are between 10 and 16 MB. Are they supposed to be that big? Sorry if that is an idiotic question.

WITHOUT texture management, it takes far more RAM than the previous version (IME). It alone will push a clean install of KSP to ~3000-3200MB RAM used - at least it did for me. With ATM, my experience is a little different: it seems (subjectively) to still take more RAM than the previous version, but not a huge amount.

But it's safe to say that the one texture per folder scheme that's there currently (or really just the overall size/number of texture files/whatever) will not change much? It's 482MB without the deprecated folder. This tells me I need to start the culling! =)

Perhaps this has already been answered somewhere, but... I thought I read somewhere that the new version of B9 uses a lot of shared textures/resources/somethingorothers in order to cut down on memory use. Is the current downloadable repository a good reflection of what the final 5.0 pack will look like? I remember the 4.0c (?) being something like 200MB on disk, but the current download unzips to something like 480. Does size on disk correspond to memory usage - not MB for MB per se, but proportionally such that a 400MB mod uses roughly twice the RAM of a 200MB one? I ask because I tried out the new parts as the only mod on a clean copy of KSP, and without ATM, the new B9 *alone* pushed me to 3300MB of RAM used (plus or minus). I know ATM would fix a lot of that (and do use it), but I use an unholy heap of mods and scavenged parts and wonder whether I should start placing lesser-used ones on the sacrificial altar now to prepare.

I've just switched to 32 bit from 64 bit and have to pare down my mods a bit (even with ATM) - therefore this may take me a while to test out, if I can remember! EDIT: Also, the fact that you were unable to replicate it makes me suspicious. My 64-bit install was horrendously unstable (used to be perfectly fine, changed at some unknown point); it's possible it was a conflict generated by some improper install I did (or edit, or deletion or whatever). I'll see if I can reproduce it though.

Word. 10characters

Also getting a lot of this: ArgumentNullException: Argument cannot be null. Parameter name: key at System.Collections.Generic.Dictionary`2[KSPParticleEmitter,TweakScale.EmitterUpdater+EmitterData].ContainsKey (.KSPParticleEmitter key) [0x00000] in <filename unknown>:0 at TweakScale.EmitterUpdater.UpdateParticleEmitter (.KSPParticleEmitter pe) [0x00000] in <filename unknown>:0 at TweakScale.EmitterUpdater.OnUpdate () [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.Update () [0x00000] in <filename unknown>:0 (Filename: Line: -1) Mean anything?

Awesome. Thank you!

Getting a strange interaction between TweakScale 1.41 and Modular Fuel Tanks 5.1.1 (I think, or whatever is the latest). Replicate: 1. Add part in VAB. 2. Connect tanks to it in symmetry (seems not to be problem for lone tanks). I happened to do 12 of them. 3. Scale up tank. Mass is way off, Volume Avail reads wrong (negative large number), amount of fuel in the tank is far higher than it ought to be. 4. Remove all tanks and re-place them: fixes it. 5. Now scale the tank down: somehow goes from some number of thousands of fuel to a small amount of fuel (Single digits) out of 5 million or so - but reads as full. Volume only labeled as in the millions, but isn't actually. Weirdness. Only me?

I can see where that's very possible - don't know what to tell you other than that with about 8923058 mods installed and RC7, KSP crashes reliably (though not always at the same time). With RC6, it doesn't. It could be coincidence - who knows! Figured I'd throw a log out there in case it wasn't. EDIT: Maybe (probably?) coincidence. I give up on analyzing KSP failures.

FYI - RC7 of PartCatalog seems to cause constant crashes in KSP 24.2 64-bit. Here's an output_log: https://dl.dropboxusercontent.com/u/59567837/output_logPartCatalog.txt That was on a clean install of KSP with only some NovaPunch and AIES parts installed to play around with. RC6 does not cause the same crashes and seems stable.

Are you using Modular Fuel Tanks by chance? I think I'm having an issue between MFT/TweakScale interaction with the latest TS version and trying to see if it's just me. I get something similar: Scale up a tank with MFT installed, mass goes VERY high. Remove all tanks and replace with MFT: mass back to normal. However, I'm not having the same mass issue when tanks are scaled down. Instead, scaling down a tank radically reduces the amount of LF/OX/whatever in the tank: think 25,920 for a big tank becomes 0.824 Liquid Fuel (not a typing error) when scaling from 5m to 3.75 after having replaced the tanks while the part was scaled to 5 meters so the mass corrected itself.

P.S. the tracks, repulsors, wheels you've made are pretty effing awesome, allowed me to build this karbonite-mining monstrosity - seen here weighing in at 500ish tons, with built in suicidal and very short-lived turbo mode activated, for when 15 meters a second just doesn't cut it: On a side note, the parts seem to behave well with TweakScale (the tracks there are 200% or 150% size or something) - though I'm not sure about the suspension. Although 500 tons is pretty freakin' heavy...

Very cool! Playing around with the surface mount repulsor, perhaps a little strange behavior to report - or I don't know how to use the parts, equally probable. Steps - I don't know how essential any of these steps are, you might be able to do it with any number or placement of repulsors, but I could reliably make it happen this way: 1. Place 4 repulsors in symmetry mode in the VAB underneath something simple, but place them so that they are angled roughly 45 degrees from straight vertical. I used a GoodSpeed station command core for this for convenience (handy 45-degree angled corners). You can see in the pic. 2. In flight, figure out a way to flip your craft so that only one of the four repulsors is pointing straight down toward the ground - flip the craft up onto one of its corners with a repulsor. The way I did this was to raise the height on one of the repulsors to 8, but I think anything could work. Like so: 3. If you manage to do this, your craft will no longer fall back down onto the other repulsors, and has a hard time falling any direction at all - it will remain "perched" on that one corner, like it is in the picture, even if you lower the height of the repulsor you raised and try to use the reaction wheel to rotate it back down to normal. You can get it to flip over by lowering the height of the downward-facing repulsor a lot. The reaction wheel in the part there was insufficient to flip it. Second strange behavior (still surface-mount repulsors): 1. Make a long tube craft (AKA a long fuel tank with a probe core and some juice). 2. Place repulsors at either end of it, again angled in relation to the ground: put mine at 60 degrees from the ground, or 30 degrees tilted down from horizontal. Four total. Like so (here shown after it flipped over so you can see how I placed the repulsors): 3. In theory, you'd think the repulsors would kind of even out and make the craft sit upright in relation to the ground (played around with height, no difference), but it will actually fall to one side or the other instead like this: Maybe this is how they're supposed to work though? Intuitively, I thought placing them at an angle like that would make it roughly achieve balance when vertical. But maybe my intuition is just wrong. Before messing with the above cube-shaped experiment, the ones placed at 45 degrees do make the cube sit vertically.. Kind of vague, hopefully it's not just a case of me not understanding how these really ought to work, and hope that's helpfulish.

Huzzah! Cool models on the engines, by the way

Fresh install on mostly fresh KSP... There are a couple other parts that appear as quasi-duplicates as well: MP-45 monopropellant engine, cormorant MP engine, and Albatross, I think, have two versions of the same size, one of which has no name/description. I unzipped the file NOT into a KSP directory and there are still duplicates there. Notepad++ search for RLA_mp_small and you'll see one of them.

Just a heads up - in the mp_small and mp_sr directories under engines, there are duplicate parts methinks

Aha, cool, that does seem to fit the 3 masses, not 4 deal. If that update is coming soon, then yeah, I think I'll just wait. Thanks for the help!

Not sure if anyone else has reported this, but here's what happened: 1. Went into IR's tweakscale configs, decided I wanted larger IR rework robotic parts. 2. Added new values higher than current max (e.g. added a new 1.5 scale whereas highest was usually 1.0 for most of the IR Parts). 3. Attempted to scale up IR Parts. 4. They appear to scale up, but I get debug log spam and VAB/SPH lag. Does not happen when scaling down or when scaling *back* to original size, only seems to happen when going above whatever was in the bundled tweakscale config. Here's an output log: https://dl.dropboxusercontent.com/u/59567837/KSP-IRTweakScaleStuff.log Please let me know if that's not the right log file. It didn't make anything crash, no output_log in a crash folder... Latest versions of MSI/TweakScale (I think!), but tons of mods installed...

I mean - I'm guessing that what's going on is a design issue, but I sure can't figure it out. Either that or it's a combo of my bad design + parts that don't interact well with NEAR/FAR = really weird behavior. Or it's that I have 98395839583 mods and something, somewhere, is causing things not to work right, or KSP x64 is. Figured I'd throw it out there since it sounded like dtrauma was experiencing vaguely what I was.