AccidentalDisassembly

I start at 2.1GB of RAM used and every time I load vessels in the VAB/SPH, switch scenes, or really do anything (you know, play the game), memory usage goes up as a trend - at certain points, what I assume is what other people have called "garbage collection" (not a programmer) does reduce RAM usage momentarily. But the trend is always upward. Even starting as low as 2.1GB, I can't really play for more than 45 minutes if I am regularly switching between vessels, launching new ones, etc. The same thing happens on stock, it just takes longer to crash because memory usage starts lower. Dear Squad: please fix this ASAP!

How can MFT have duplicate TweakScale references? The mod includes no parts that could be TweakScaled...

No clue if this will be helpful, but I use this mod: http://forum.kerbalspaceprogram.com/threads/90678-0-90-Science-Containers-v-08-2 ... and I wonder how his containers handle multiple samples, or if they do. Even though I've played with it, I honestly can't remember what happens when you have two surface samples, let's say. But if they somehow allow duplicate samples, it might be one possible avenue for having just one container part on the return capsule. Maybe.

Crazy thought, but would it be possible to use Contract Configurator to ask for a bombing contract using BDArmory? E.g. "go drop a bomb on this spot" or, though I imagine it wouldn't have to do with this mod per se, maybe go destroy this ship/object/something that gets spawned at a certain location...

Log's here: https://dl.dropboxusercontent.com/u/59567837/output_logTexAnim.txt I absolutely wouldn't put it past myself to have screwed up some install, either, so there's that possibility...

Might also look at Goodspeed's automatic fuel pump (no link, sorry, but google will help you) - it still works in 0.90, I think someone updated it.

It was also abominably slow when I tried it in 0.25, I also had a lot of mods though. But I don't see why the number of mods would change anything, I am guessing it's just some problem in the code?

0.90, Windows 32-bit version, but running on Win 8.1 x64 enterprise. Lots of other mods, too... EDIT: I'm eagerly awaiting (hoping for) a renewed version of the hangar extender... sigh.

Here's another request if you're interested: a very long, skinny hinge, essentially a laterally stretched (and smashed in other dimensions) pivotron that would be useful for joining a panel to a panel, let's say. It would essentially look like a long cylinder. Great for using structural panels to make ramps and stuff. Here's a crappy drawing:

Speaking of RAM... this looks awesome, do you have an idea of how much memory it will take up? Ish?

If you do, and maybe this is insane - would it be possible to write some sort of magic code that says "when this thing hits Kerbin, take all the science in it and give it to the player" - or that sort of thing? So you don't necessarily have to micro-manage return capsules, you can just shoot them at Kerbin on a reasonable trajectory and have the game automate the rest? Unless of course that's not really what you want to do!

Quick note: the tiny wheel part name is KF_TonyWheelALPHA - was it supposed to be Tiny? EDIT: Also, this shows up in my logs. Meaningful? : [EXC 21:56:40.556] TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'TextureAnimator'. System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType) System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit) System.MonoType.GetCustomAttributes (System.Type attributeType, Boolean inherit) KConfigDocumentationGenerator.GenerateAssemblyDocumentation (System.Reflection.Assembly assembly) KConfigDocumentationGenerator.Generate () KConfigDocumentationGenerator.OnLevelWasLoaded (Int32 level)

The descriptions aren't bugged - they are simply references to where the parts are located right now, just FYI - you're not crazy. They should show up in game as [thedirectorystuff] that you saw.

I did notice something re: the skids - as you can see in the picture, they tend to sink into the ground. They also have a strange behavior when moving at high speeds - they seem to catch on the terrain now and then with a little jerk or twitch. I think it's a function of how fast you are accelerating, but I'm not sure. Low thrust on that same engine resulted in smooth-ish movement, high thrust = twitchy. Maybe it just has to do with them clipping into the ground though. They also appear to be lubricated by a never-ending fountain of grease, having very little friction... EDIT: on some terrain they sink (runway?), on other terrain they don't seem to, or not as much... they're a little bit catchy/twitchy/jerky all the time under acceleration though, I think... SECOND EDIT: Hahaha, I also did a nosedive straight into the ground at 100 m/s with that rover body, and every other part of the ship blew up instantly, but it survived. IMMORTAL! THIRD EDIT: And the reaction wheel is strong enough that you can just roll the rover around if your wheels blow up. That thing is awesome. Pretty sure Jeb is the only one who didn't vomit profusely.

Higher speed version of the tracks, you say? I did notice that, as soon as the tracks exceed their normal speed (16-ish m/s), it's basically impossible to keep the vehicle going straight. Better not touch the steering! I also learned it's nearly impossible to destroy the rover chassis, and it also floats very... unusually. =)

Totally possible, nearly impossible to control in a meaningful way. Have to use engines to keep it upright, so I think it could be done with any wheel and enough reaction wheels/RCS/engines. A better designer than me may come up with something superior:

You know, Haifi's motorcycle thing makes me think it could be possible, with enough reaction wheels, probably, to create a unicycle of sorts...

I think it's from SXT, could be wrong though.

Haha. HAHAHA. HA. (maniacal laughter). Far too late for that, I'm afraid, I lost all my remaining sanities back in 2007...

Wait a second... Where are those mini-tracks from? Is that in the dev version, but not 1.7 (unless I am blind as a headless bat)? Can we all have access to that dev version? Why is the sky blue? Are we there yet? ARE WE THERE YET?! I am just full of questions.

The problem is that TAC-LS needs to determine if you have other mods too, like DRE, and ALSO add those resources to its tank types - so TAC-LS would have to make a tank type for every conceivable combination of mods that add stuff to command pods. The minute you have more than one mod with more than one resource, things get messy. But adding an option to just "keep = thisresource" or something would make all of that much easier, or having two different types of MFT tanks: one that replaces, one that just adds. Otherwise, what happens when putting MFT first in the application of MM patches and adding RESOURCE{} stuff after it? Maybe that would work?

Actually, here's a crazy idea - maybe this can't work, but what if MFT had two behaviors for tank types: additive and replace? Normally, adding an MFT tank would remove all other resources; with the additive option, MFT wouldn't delete existing resources and would just add to them instead (based on the TANK definition being applied)? E.g. MODULE { name = ModuleFuelTanks removeOtherTanks = true/false or keepExistingResources { resourceToKeep1 = AblativeShielding } } ... or something.

Would be nice especially for AblativeShielding (possibly others that I can't think of) - since a different amount is added by DRE for each pod (ish), you'd have to create a bunch of tank types to retain those same amounts (I think)...

I have the same issue as you, and find that it happens on stock too. Reducing textures/mods/whatever just slows it down, but at least it does that!

I'm fairly certain there is at least one more memory leak in KSP: just load stuff into the VAB/SPH a lot, switch scenes a lot, and you'll notice an upward trend in memory usage (in stock as well as modded). Sure, occasionally it will go back down some, but the trend is upward an out-of-memory crash is inevitable if you play long enough. Very irritating.