AccidentalDisassembly

Was anything ever done with the new cargo bay models that open on the end rather than the top? Those looked very neat...

Beats me. I run a ton of mods; all I know is that KSP reliably would not load as soon as I put SoundingRockets in. Removed ARP and now it loads - maybe it's coincidence? Maybe it's the number of times StoredCharge was defined somehow interacting with MM and ARP? I have no clue.

Welp - new working theory. Here goes: multiple resource definitions aren't a problem, but apparently they might be for the Alternate Resource Panel - I removed that (thinking still that maybe the issue had to do with resources, so...) and KSP loaded. Weird.

Windows 8.1 x64, running KSP 32-bit. The really weird thing is that the hanging occurs earlier and earlier every time I load KSP - that's just bizarre. Always on a different part name, always earlier in the loading. Maybe it's a MM thing...? I am really loathe to go through the process of dealing with something like 60 mods =(

It does load on a clean install, it doesn't load on a clean save on my modded install though - well, one of the times the game loaded, the parts still didn't on a new save, that is. Could it have to do with the resource being used, or it being defined 3 times, or whatever? Or maybe some MODEL{} insanity? Seem to remember finding another thread where the game would not load, and would give similar error messages, that had to do with a combination of MODEL{} being used and something weird going on with the .mu file and textures, or something. I definitely did already have the DLL.

Not even close to RAM cap, about 1.5 gigs of RAM used - it is not crashing, it's hanging, I am absolutely certain it's not a memory issue. Game runs happily for hours about about 2.2 gigs when fully loaded. Hangs with the SoundingRockets folder, doesn't without - but not on a clean copy, apparently, so I would just assume there's some sort of weird interaction going on? I have no idea. Here's the log from the latest attempt at loading: https://dl.dropboxusercontent.com/u/59567837/output_logSoundingRockets.txt The hanging seems to happen earlier and earlier each load, different part name shown in the loading bar each time. EDIT: OK, 1.8 gigs of RAM used, to be precise (this most recent attempt)...

Something about the sounding rockets is preventing me from loading KSP on a very heavily modded copy, but (apparently) not on a mostly-fresh one with just a couple mods, like PartCatalog/MM/couple others. I was able to load twice on the copy with lots of mods. When I did: 1) First load: PartCatalog (or something) borked, parts don't display in VAB/SPH - not a question of autotagging, that did nothing (same with rebuild of catalog). 2) Second load: no parts listed in VAB. After that, KSP wouldn't load. First time I tried, this was at the very end of the log when it hung near the end of the loading process: Second time, it was this instead: Third time, same as first time. Stopped on a different part every time, though, at least according to the loading screen. Removing SoundingRockets directory solved the problem, could load once again and see things in the VAB/SPH. This thread: http://forum.kerbalspaceprogram.com/threads/101122-KSP-Keeps-Freezing-while-Loading suggests that maybe it has something to do with resources, I only link it because I thought "hey, there's this new StoredCharge resource, maybe there's a connection." I have no clue, I'm just guessing based on superficial similarities between words, possibly useless! =( EDIT: seems maybe Community Resource Pack, NearFuture and Sounding Rockets all have cfgs defining StoredCharge - could this be a problem? Er... copied the configs to my KSP Tests copy so that there were 3 present defining the same resource.. that didn't seem to break the clean copy...

The cool little parachute from the nosecone might be neat for other applications as well... I have no idea what those would be, but.. you know, for stuff.

I think I've also seen some airbrakes in SXT and RetroFuture - SXT at least is a very lightweight parts pack (and you can delete all but the airbrakes if you want). Just in case that's an option for you.

Oops, missed that! Sorry!

Very cool update!

Hah, that sneaky son of a... still though, the difference is astronomical; surely whatever dark magic DirectX stuff is working isn't (almost literally) 50x or 100x faster than what you're doing...? Or is it?!

Any way of pairing this with DDS4KSP? The first conversion on ATM takes an ungodly amount of time - DDS4KSP does the whole GameData folder in under a minute...

Sorry if this is an idiotic question - I get what the max_size variable in the config file does, but what about min_size? I assume that it means that anything of size X or smaller won't be scaled at all - does it exclude certain images from scaling like that, or does it prevent downscaling past that size? E.g. size 512x512, scale set to 4 (would become 128x128), but min_size set to 256: that image becomes 256x256? I guess in other words: is it the minimum size of images to be considered for scaling, or is it the minimum size of the resulting scaled images (which would include the first case, too)?

I'm not Biotronic, so take it for what it's worth - I believe you can simplify this further. All of your tweakScaleCorrector values scale linearly with your scaleFactors - increase the scaleFactor to 2.67, the tweakScaleCorrector is then 2.67, for example. The following will do the exact same thing you're doing, but it will make it so that you can add or remove ScaleFactors without having to change values inside the TWEAKSCALEEXPONENTS{} - you'd still have to have names for the scaleFActors and all, just one less step: SCALETYPE { name = KFScale freeScale = false scaleFactors = 0.75, 1.0, 1.25, 1.5 (or more) scaleNames = Small, Medium, Large, ExtraLarge (or more) defaultScale = 1.0 } TWEAKSCALEEXPONENTS { name = KFWheel [B] tweakScaleCorrector = 1[/B] } TWEAKSCALEEXPONENTS { name = KFModuleWheel [B] tweakScaleCorrector = 1[/B] } }

Use -force-opengl or ATM and/or reduce the size of cloud textures to do that.

Had an issue that NathanKell suggested was related to DeadlyReentry - my post (with log) here: http://forum.kerbalspaceprogram.com/threads/57988-0-25-x-Wenkel-Corporation-RealChute-Parachute-Systems-v1-2-6-16-11-14-paused?p=1584343&viewfull=1#post1584343 (Hopefully that link works)

Aha! Thanks, going to go figure out if I can fix what's going funny.

I'm getting an error from ModuleManager in the PartDisabler config, but couldn't track it down - anyone else have that?

Where are you all getting that different-looking sun from? Mine looks much less pointy and far more yellow...

Just to update previous post - perhaps this belongs in the EVE thread, I don't know - but there seems to be something going on when visiting other bodies and then returning to the KSC. Happened with both the Mun and Minmus; returning to KSC -> no clouds in the sky, can't click on any buildings. Have to restart KSP to get the buildings to be clickable again...

Seem to be getting a bunch of NREs and, occasionally, when I return to the KSC after a flight (just sent a satellite crashing into the Mun), I can't click on any buildings. I don't *know* that it has anything to do with your pack per se - if it doesn't, please let me know and I'll go post somewhere else! This happens a lot: NullReferenceException: Object reference not set to an instance of an object at Clouds.Clouds.Update () [0x00000] in <filename unknown>:0 In this log log: https://dl.dropboxusercontent.com/u/59567837/output_logClouds.txt

Dunno if this has already been mentioned, but with the latest RealChute, there's a certain moment during the ascent where "Warning: Chute deployment is unsafe!" is spammed and framerate drops considerably. *Seems* to happen at relatively high (300-400m/sish?) speeds, and seems to stop happening after a certain altitude (I think), or possibly some condition that I don't understand. Lots of mods running, don't know if it's an interaction thing. Log: https://dl.dropboxusercontent.com/u/59567837/output_logRealChute.txt

Don't know if it applies to Linux at all, but doing -force-opengl let me load a clean copy of KSP (dunno about a very modded one, about to find out!)

The method in your first post might work, but like I said, I don't think it will give you what you want, meaning it will not reduce your work. The way to reduce your work is to define a TWEAKSCALEEXPONENTS{} thing for the particular variables you want to scale with the size of the part - that's my point. Yes, most of the TWEAKSCALEEXPONENTS stuff is defined outside of a scaletype - which is fine for most cases, and you can do it, it won't harm anything and *might* be just as easy (or easier). But if (if!) you are going to define different values or different exponents for the same variable based on the type of part you're using, you can just define them in the scaletypes you apply to those parts and save yourself the step of also defining a generic set of values - and/or stop parts that don't have particular scaletypes applied from also scaling a given variable with size. This is assuming that's actually what you want to do, like I explained - sounds like it isn't, but even if it isn't, I can tell you what I said is not nuts. It is slightly more break-proof and easier than going back and doing stuff over in the event that a new part doesn't work well with those same values/exponents. Note that I did not say that you can't or really really shouldn't, as if it wouldn't work. A couple dozen TweakScale configs for a couple hundred parts and associated scaletypes suggest it's a decent way to do things - YMMV. I don't know anything about whether the examples given by Biotronic are up to date or not - all I know is that TWEAKSCALEEXPONENTS {} definitions do what you want to do, whence my attempted explanation of them, and you can define them either by exponent or by absolute value, and either globally (not in SCALETYPE or MODULE), for a given scaletype, and also for an individual part (once and only once, can't be called for other parts) by putting it inside a TweakScale MODULE. The way TWEAKSCALEEXPONENTS actually controls how variables scale is indeed not the clearest - if you put only one number after a variable's name (mass = 2 or maxThrust = 19485), it treats it as an exponent. If you put more than one, it treats them as individual values it tries to pair with individual scaleFactors, and the number of each has to be the same. Also, this: ... is not the way IR handles scales - not MODULE within MODULE: it's TWEAKSCALEEXPONENTS. Here's a copy & pasted snippet from an IR config: And the way IR handles scales is REALLY not what you want, it requires going into every single part config if you ever want to change how stuff scales.