AccidentalDisassembly

Gotcha! Good to know, just making sure it was as it was meant to be!

MM_AddResources (one of them) is what adds MFT to the command pods - have to edit the other resource adding config and remove the check for NOT having MFT, then you can get the resources in the pods.

FYI - This may be intentional, but right now, your configs make it so that greater commitment results in LESS favorable outcomes - for example, 90% commitment in Outsourced Research makes each point of research MORE expensive than 10% commitment. It's the opposite of how stock does it (better gains per unit spent with higher commitment) - is this what you were going for?

Hi Taranis - I posted this in the MFT thread too since the problem is related to the combination of TAC and MFT, but I wanted to alert you to a problem with the existing TAC MFT configs. It's possible that there's some interaction going on with yet another mod, I really don't know, I'm running a lot. I think it's clear-ish what's happening though: - Right now, applying the TAC MFT TANK types to command pods (in the MM_AddResources config under TacLifeSupportMFT) will result in deletion of ElectricCharge and AblativeShielding (and MonoPropellant, and any other RESOURCE{}) that was in those command pods. I don't remember this happening in the past, so maybe this is new behavior for MFT or something. - One possible solution seems to be to either add ElectricCharge to the TANK type that you have defined and add another TANK type with an appropriate amount of ablative shielding to apply to pods that should have it as per DRE, - or possibly just to ditch the MFT config for the moment and apply the other, non-MFT MM_AddResources.cfg to all parts by removing the NEEDS[!modularFuelTanks&!RealFuels] from the patches. Verified that the MFT config (or really, the application of an MFT tank) was overwriting other resources in the parts by just removing it from GameData and loading without it once. The life support resources were gone (of course), but AblativeShielding, ElectricCharge, and MonoPropellant returned to parts like the Mark 1 command pod.

Quick question - I'm trying to figure out what mod has deleted all the electric charge from my command pods, and I *think* it might be the combination of MFT and TAC, my working theory being that TAC, by adding its own LifeSupport TANK type (which has no ElectricCharge) to all command pods, is somehow doing this. In the current version of MFT, if you add a tank type to a part, will it delete all the RESOURCE{} bits in the part when it does this? Or somehow overwrite them? When TAC is adding these tank types, it does NOT MFT-ize command pods that already have the Food resource present - and, *maybe* not coincidentally, the DERP lifeboat module (which does already have Food) is the only command module I can find that retains its AblativeShielding and ElectricCharge resources. Actually, come to think of it, the AblativeShielding resource that DRE usually adds seems to be gone, too... EDIT: OK, I think I figured it out. Removing the config TAC uses to add MFT to command pods solved the missing ElectricCharge and AblativeShielding mystery. Here's what I believe is happening: 1. Multiple command pods' configs, which originally contain a given resource (like ElectricCharge or MonoPropellant) are first modified by something like DRE. 2. DRE adds to them AblativeShielding in a RESOURCE{} thing, I think. 3. TAC life support later comes along (I'm assuming this is because the MM patch happens after DRE's MM patch) and applies an MFT TANK type to those same parts, overwriting the ElectricCharge and AblativeShielding (and everything else inside RESOURCE{}) in those parts, and adds in the resouces defined in the TAC MFT TANK type. Is there any way to have MFT not overwrite certain resources contained within a part - maybe specific exceptions for ElectricCharge and AblativeShielding?

Had this pop up in my log - is it meaningful? Was tracking down bad texture stuff (isolated loader exceptions, or whatever they are) by searching the word "exception" and noticed it. If it's meaningful, I'll see if I can get it to show up again in another log: ScienceAlert, Creating experiment window (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at ScienceAlert.Windows.Implementations.DraggableExperimentList.OnVisibilityChanged (Boolean visible) [0x00000] in <filename unknown>:0 at (wrapper delegate-invoke) ReeperCommon.Window.WindowDelegate:invoke_void__this___bool (bool) at ReeperCommon.Window.DraggableWindow.OnEnable () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) UnityEngine.GameObject:AddComponent() ScienceAlert.Windows.WindowEventLogic:Awake() UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) UnityEngine.GameObject:AddComponent() ScienceAlert.<Start>d__0:MoveNext() (Filename: Line: -1) ScienceAlert, Creating debug window

Please remove the modulemanager .dll from the directory in which your mod resides and instead place it in the base directory of your ZIP file - this is where it should be located! EDIT: Also, I'm getting this in the ol' logs. Is it meaningful enough to dropbox an output_log? AddonLoader: Instantiating addon 'RMMModule' from assembly 'CommercialOfferings' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) NullReferenceException: Object reference not set to an instance of an object at CommercialOfferings.RMMModule.OnAwake () [0x00000] in <filename unknown>:0 at PartModule.Awake () [0x00000] in <filename unknown>:0 UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelWasLoaded(Int32)

The log is linked in my post. The word "log" is even in bold. I don't have too many mods - I start at 2.3GB used, and it simply goes up from there without installing any more mods - just by playing, and especially by loading craft in the VAB/SPH. Nothing gets unloaded, maybe. I don't know. Man, I hope Squad will look at memory use in KSP, if that's the case. EDIT: Unless it's a Unity thing, in which case I hope they'll write many angry letters. It seems rather important to address memory leaks and memory usage more generally in a game that derives most of its lasting interest (and its proselytizing fans) from the ability to mod it, which takes memory, of course.

Quick suggestion re: control surfaces config - add: FILTER { CHECK { type = moduleName value = FSairBrake } } Happy New Year!

I wonder if this is similar to what I was experiencing here: http://forum.kerbalspaceprogram.com/threads/105094-0-90-Better-Buoyancy-v1-0-Simple-Water-Fixes-12-27-14?p=1639055#post1639055. No clue if they're related. Was using KJR and EPL, but not US. Now that I think about it, it was as if the decouplers on the rear of the plane were being treated as launch clamps... or something.

Hmm, that does make sense. Maybe best just to stick with the near-flat ones, then... those are still pretty darn cool. Also, maybe one comment about SpaceY - I can't remember the name of the engine for the life of me, but there's one 2.5m engine with that multi-node system that will only do 3.75m or 5m shrouds - would it be possible to add a straight 2.5m one on that one?

Another crazy idea re: the shrouds/fairings might be to somehow mimic what SpaceY does with a couple of its heavy lift engines - it creates two stack nodes below them, and stacking something on either of them produces a different-size shroud/fairing/whatever. I wonder if it would be possible to add a node floating out from the ends of fuel tanks where, if you attach something to that node, a slanted fairing is produced, but if you attach something to the node on the surface of the ends of the tanks, either a flat fairing (as you have) or nothing (presuming you'd only put the same size tank on that lower node) would be created. Just a thought...

Don't know if this will be helpful, but I do remember in another thread someone mentioned a bug about the center of mass moving backward from certain parts. I want to say it was RealChute (maybe) - are you using that? Do you have the latest version if so? Just one possible place to look.

It sure seems like a great idea, aside from (apparently) being incapable of determining which version of a mod is actually installed. "autodetected dll" is not a great way of telling me if my version is out of date or not.

Let me preface this by saying I don't *know* it has to do with Better Buoyancy, but BB did come up in the log with a NullRef, so... maybe? Lots of mods running. Can provide list if it will help. Weird thing happened when I was attempting to reproduce a memory leak (?) I seem to be having. KSP Win32 on Win8.1 x64, 0.90, etc. - loaded Stearwing stock craft, launched to runway. However, the plane seems glued in place: nose gear touches runway, nothing else does. Physics don't seem to apply. See picture below. The plane won't settle onto the rear gear, and applying thrust doesn't make it move: Log: https://dl.dropboxusercontent.com/u/59567837/output_logRunwayGlue.txt What the heck is going on there? EDIT: Did fix the ISolatedWhateverExceptions related to some .png files being DDS-ified. Also, I can even raise the gear and lower it again and the craft just stays pinned where it is in space. It will wobble a little when the engines vector, but that's all. EDIT AGAIN: Decoupling the rear engines will cause it to "unstick" and move again as normal...

I'm still having the problem where, if you remove the Hangar folder from GameData, it will corrupt your career save and produce the can't-click-on-the-VAB, can't exit the admin building etc. bug as described here: http://steamcommunity.com/app/220200/discussions/0/626329187149000855/. Replacing the Hangar folder fixes it. Sorry, no log, because the most recent was from the one that worked. It may be interaction with another mod, who knows, but it's still there.

FYI - you have bundled an old version of ModuleManager.dll inside your mod's directory. It should be in the GameData directory of your download if it's required (and the most recent is 2.5.6, I think).

I don't know much about programming, but it sounds plausible - however, I can't stay inside the VAB and load/create/destroy ad infinitum, or at least I am pretty sure I can't. The more I load/new/load/new etc., the more ram is used. Usage does vary, but it trends upward. Is there any way to figure out what's going on? I am at my wits' end, I just want to play (with the mods I have chosen and which don't push me anywhere near the memory limit initially). =(

Dunno about the TGAs, but for the PNGs that are actually included in the various downloadable versions, you can follow those steps (save PNG over PNG or change bit depth or whatever) and it will then batch successfully with DDS4KSP (mostly)

bac9, I posted this in the DDS4KSP thread, but it occurs to me that that's not a thread you'll probably check often, so RE: various .png files not converting to DDS, here's what I've found: I had luck by converting the B9 textures either to: - NOT grayscale -> convert them to 8-bit color instead (I used Photoshop) - NOT palettized (same) - Simply opening in photoshop and re-saving/overwriting: they were in a specific PNG format that DDS4KSP apparently can't read. Whereas, I guess, Photoshop's standard .png output is readable...

Getting a 403 forbidden on your download link =(

I had luck by converting the B9 textures either to: - NOT grayscale -> convert them to 8-bit color (in Photoshop) - NOT palettized (same) - Simply opening in photoshop and re-saving/overwriting: they were in a specific PNG format that DDS4KSP apparently can't read

FYI - unless you changed them, there's an error in the Solar Panels config (missing FILTER) and a typo in the air intakes config ("Ait" for air, I think). EDIT: Maybe in Kolago's configs, not the ones bundled with 1.8.0, I've lost track!

On my heavily-modded install of KSP: 0.90, Win 32 version OS: Win 8.1 Enterprise x64 Install location: C:\Games\KSPNew\ Mods installed: see picture below *I believe* all mods are up to date, but this has happened for a while and has not changed as I have updated mods as they're released. ...when I load the game, I use about 2.3GB of RAM when first arriving at the KSC screen. However, after a while playing, invariably I run out of memory. No, I am not using ATM - instead, I converted basically every texture in GameData to DDS using DDS4KSP (except for ones whose conversion caused problems/crashes, such as a couple in NearFutureSolar), resizing them to 0.5x dimensions (or smaller). I found this gave me more RAM savings than ATM. I would assume that different scenes, different numbers of parts in view, more or less flights, and all that sort of thing would make memory vary - and it does vary, but the trend is always upward. I would also assume that starting the game using 2.3GB is not really dangerous territory for running out of memory because of the number of parts I've loaded. Number of scene switches (in and out of VAB, reverts, switching to different craft on the Mun or Minmus or whatever) *seems* to affect RAM usage, where switching scenes more = pushing the "baseline" of RAM usage higher and higher. Likewise, loading a craft in the VAB (for example) will make RAM jump maybe 200MB or so, and then closing the VAB or hitting "new craft" will not result in that RAM usage going back down - it fluctuates, certainly, and sometimes by a lot, but the trend is upward. If I load a craft when 2800MB of RAM is in use (for instance), usage will jump to 3.0GB and never go back under 2900MB or so even when I leave the VAB and change scenes a bunch of times. Loading craft in VAB/SPH *seems* to be the single biggest contributor, since I noticed large jumps in memory use when doing so. Is there any way to pin down what (or which mod) is causing this phenomenon? I would like to be able to actually play for more than 30 mins or so without running out of memory on an install that really seems like it shouldn't. Here's a log: https://dl.dropboxusercontent.com/u/59567837/output_logMemoryLeak.txt In that log, I was able to crash the game due to being out of memory by doing nothing but switching between scenes / vessels (on the Mun and Minmus), returning to the KSC, loading vehicles in the VAB and SPH. Did not launch anything, did not do any science, etc. And here's a screenshot of my GameData folder (EriksParts contains random, one-off parts from certain mods I liked but didn't want every part from - no DLLs in there): Note that I have deleted many, many parts from the larger parts packs (like KW, B9, NovaPunch) in order to save RAM, so I'm not actually trying to run all of those mods at the same time, really.

That sounds like a lot of trouble. Maybe the easiest would just be to have an "all" subcategory; if the mod doesn't have many parts in many categories, just click on that and see everything on one page...?