DaniDE

Thanks for clarifying this

Make sure you really deleted the correct thing, then go to the gamedata directory and remove all modulemanager cache files (everything starting with modulemanager *except* the ModuleManager.2.7.2.dll itself). Restart the game, and check in sandbox mode what is required to build rockets from an EL workshop.

@Padishar thank you for this wonderful mod. I have one simple question, do you have to apply the padding manually everytime you restart the game? I have noticed padding = false is set by default, and I am not sure if that is safe to turn on and if you still should manually invoke it by alt-end after a while even if that is set to true. (I am just assuming here that this setting does the auto-applying :-). Thanks

@Kielm looks very nice

I use this patch to do sort the smart parts into control, because I am to lazy to change all the configs again on updates: @PART[km_smart_alt_low,kb-fuel-breaker1,kb-fuel-breaker3,kb-fuel-breaker15,kb-fuel-breaker2,FuelController,km_smart_fuel,km_prox_sensor,km_valve2,km_valve,km_smart_time,km_smart_speed,km_smart_radio]:AFTER[SmartParts] { @category = Control } Maybe it saves one of you some time :-)

My 2 cents on the whole compatability thing: If you dont want compatability problems, you need to manually take care of it yourself. Mod Authors cannot foresee the combination of mods a user has. Its not as easy as using some mod manager software, but its also not so complicated you could not do it yourself. As for compatability, you need to be in control of what modules get applied to which parts. I delete the inclusion patches that come shipped with tweakscale and only apply tweakscale to certain parts like structural stock parts and Infernal Robotics with my own tweakscale MM patch. Sometimes Mods come with tweakscale configs included and you might want to check if you really like to keep those or not. I got rid of interstellar fuel switch which is way too invasive in its implementation - for some reason, the author decided it would be a good idea to apply it to @PART[*] instead of defining the parts that would receive it. I personally had IFS back then for Fuel Tanks Plus, which recently dropped IFS as a dependency and lets you use Firespitter instead, which does NOT include itself to all parts and is therefore a recommended alternative for all texture switching parts. (Nertea uses B9PartSwitcher for Near Future Tech, which also is not as invasive as IFS and should also not give you trouble controlling it). What I mean is - decide yourself what parts tweakscale and other Part changing mods apply its module to and check if you really need Interstellar Fuel Switch - If you do, you can basically not *prevent* it from getting applied to all qualified parts, instead you can only try to make a custom mm patch that should *remove* the applied IFS module from a tank/engine that you dont want or need it on by something like this (no guarantees, I bascially wrote that out of my memory, not tested :): @PART[FuelTank]:BEFORE[KRnD]:AFTER[InterstellarFuelSwitch]:NEEDS[InterstellarFuelSwitch,KRnD] { !MODULE[InterstellarFuelSwitch]{} } (What this does is telling Module Manager to remove the module [InterstellarFuelSwitch] from the part [FuelTank] before KRND is run, because it needs to do it beforehand so KRND has not already blacklisted the part, and after IFS so the IFS module applying has already happened. Otherwise IFS would be removed but KRND might not get applied anyway. Only run this Patch when both mods are actually installed.) If you have done the work once, you can place all your custom module manager configs in a separate folder that you can back up for reinstalls, so you dont have to do the same work twice. In the end, you should only have parts that have a part changing module on it, that you decided on beforehand. And if you ever see a part ingame that has two conflicting modules on it, you can patch it with a variant of the above example patch. Remember to delete the Module Manager cache files in your /gamedata/ folder (ModuleManager.ConfigCache, ModuleManager.ConfigSHA, ModuleManager.Physics, ModuleManager.TechTree) when you made changes, also delete "PartDatabase.cfg" in the Kerbal Space Program folder when you changed your partlist (at least when you delete a part or a mod with parts).

Would using the arithmetic function of modulemanager: PartStats { mass *= 0.99 } not prevent any negative mass problems? This example would reduce mass by 1%, not a plain number. Thanks, Dani PS: The quoting and code box function of this forum software is a crime against usability.

@Thomas P. Thank you for updating your essential mod

Thanks @linuxgurugamer This will become especially helpful when kopernicus has been updated :-)

Before there goes more hearsay into this, I would like to point you to a source. The default behavior of PartStatsUpgradeModule seems to be replace, there is an additive update function in there too though. Quote: " the "IsAdditiveUpgrade__" field. This field tells the PartModule Load to add the UPGRADE nodes additive. If it is false the nodes will overwrite each other this is only applicable to the PartStatsUpgradeModule. " Another Quote that is important: " The PartUpgradeManager ScenarioModule handles the Upgrading. Mods can Interface to this to modify the stock upgrade behaviour and extend" You can check this out for more info:

Thanks for updating - as always great job

Thanks for updating PS: Oh it works so nice

good catch mate Thanks for sharing!

Thanks for updating Sarbian :-)

Thanks for updating blizzy

Oh nice. I am hyped for 1.2 now

@-MM- Regarding compatibility, I always wondered if it would be possible to have a common layer for modifications so all the mods that modify parts at runtime would send their changes to that layer, and then the combined changes would be passed on to the runtime. Like a modular (as in, does not need all mods to function, but could work with all the part mods at once) API that sits between the part modifying mods and the game. Maybe storing everything in RAM even, now that we have x64 across the platforms that matter. In any case, thank you for keeping this essential mod updated

Hello I have installed this mod for quite a while now, because I think it looks absolutely great - however I only really tried to use it until now - and after countless attempts I just cannot figure out how to "fill" the large truss structures with something. There seems to be no attachment nodes inside that one could use, and there also seems to be no "end piece" that offers attachment points for the inside so you, for example, could build 2.5m stacks inside the trusses. Of course I might be overlooking a part (I really have too much stuff :). Any hints for this would be greatly appreciated. Thanks Maybe if you could make a structural end / or even also separator that has two sides and could go between two T404 trusses, that has some inline attachment points like this - I managed to simulate it a bit with a spacey thrust plate - of course its not spaced out properly inside the truss:

+Engine Lighting +Planetshine +Andromeda Sunflare (http://spacedock.info/mod/461/[Scatterer]%20Andromeda%20Sunflare%20by%20Bluesubstance) The skybox is Poodmunds calm nebula skybox Have fun

tillyd - please read the first post of this thread

Since 1.1.1 introduced some part related changes I suggest you delete the part database cfg in the KSP main directory as well as all the module manager generated cache files in the gamedata subdirectory. That might help, I do this anytime I change or update a mod or a KSP update happens since they can become corrupted or are not updated correctly under certain circumstances and since they get auto-generated upon gamestart it's a no brainer to be safe on that side of things. On a sidenote, I believe with unity 5 the colliders changed, maybe check with the KIS/KAS folks what they needed to change to get the ground pylons attachable in 1.1. ? (Since capsule hatches now need a box collider, maybe its the same thing here?) Thanks for maintaining this essential mod

Hullo It would be great if you could include a failsafe in the next version that resets camera to default on undocking, spontaneous disintegration and staging, basically everytime the integrity of the current craft changes somehow. Great mod, thanks so much!

"socket" or "base" or even "foundation" (fundament) should all work About that latin thing, its been like 20 years since school, but maybe this is a bit of inspiration - : Money - over/through - (kerbal-)rights -> pecunia per (or super) civitas Money over folk/populace -> pecunia per populus Kerbalized versions might be "pecunia per kerbulus / kivitas" or something like that. Just don't use "Kopulus" or it might get weird quickly. If you want literally "before" in the sense of time you can use "ante" instead of "per" but it does not make sense in this particular case imho. Thanks, hope to be able to use your great mod it in the current game version soonish

There seems to be a problem with the Universal Storage version of Orbital Science. In my case, the experiments seem to fire but no results are stored in the capsule. My observation might be wrong tho. Here is my log https://www.dropbox.com/s/tvjdmjybr5ji51u/output_log.rar?dl=0 Thanks!

Thank you Toadicus!