Terensky

Really, I don't know as I've never tried this way, but I don't see why it shouldn't work either. Anyway, if you are releasing ships for public use, perhaps you'd like to ask someone to write down for you a modulemanager patch for modifying Squad stuff, otherwise your ship may not work if the ship's user doesn't modify the Squad's .cfg files.

I can try: it's a little bit tedious work, but perhaps if you can use an advanced text editor you could do it in a snap (for the record, I couldn't). Anyway: under PART { name = RadialDrill (or MiniDrill) for ships you have unpacked since 1.3 (i.e. used in game, those you haven't will work after setting displayActions = True) you should find the following section that read about like this: MODULE { name = ModuleAnimationGroup isEnabled = True _isActive = False isDeployed = False stagingEnabled = True EVENTS { } ACTIONS { DeployModuleAction { actionGroup = None active = False } RetractModuleAction { actionGroup = None active = False } ToggleModuleAction { actionGroup = Custom02 active = False } } In the example above I just assigned '2' to toggle the drill ('actionGroup = Custom02'), so your entries may vary if you used other keys and/or actions (or if your drills were already deployed and active, but in this case just ignore 'isDeployed = False and '_isActive = False' and leave them as they are). You should delete the lines with the following syntax: active = False (but only in the aforementioned 'ModuleAnimationGroup' section!) and your old ships should work as before, as mine did. As an example, the above code after the correction should look like this: MODULE { name = ModuleAnimationGroup isEnabled = True _isActive = False isDeployed = False stagingEnabled = True EVENTS { } ACTIONS { DeployModuleAction { actionGroup = None } RetractModuleAction { actionGroup = None } ToggleModuleAction { actionGroup = Custom02 } }

In Gamedata>Squad>Parts>Resources>Minidrill and Gamedata>Squad>Parts>Resources>Radialdrill, in MiniDrill.cfg and radialDrill.cfg respectively, the following code MODULE { name = ModuleAnimationGroup deployAnimationName = Deploy activeAnimationName = Drill moduleType = Drill } was substituted with: MODULE { name = ModuleAnimationGroup deployAnimationName = Deploy activeAnimationName = Drill deployActionName = #autoLOC_6002384 //#autoLOC_6002384 = Deploy <<1>> retractActionName = #autoLOC_6002385 //#autoLOC_6002385 = Retract <<1>> toggleActionName = #autoLOC_6002386 //#autoLOC_6002386 = Toggle <<1>> moduleType = #autoLOC_7001228 //#autoLOC_7001228 = Drill displayActions = false } If displayActions = false is deleted, things should be as before, BUT, if you have in your pre 1.3 savegames ships having drills to which you have assigned previously an action key, you have to manually remove from the savegame, in ModuleAnimationGroup/Actions every instance of Active = False You may find. Do this after you've deleted displayActions = false in the drill's config (perhaps it's better a modulemanager patch, waiting to know the reasons developers have added that line).

Perhaps you can have a look at this: memgraph at least until the devs fix it in stock.

Thanks, I will try for sure. Even with the current settings, the improvement is substantial: before I had stutter every 2 or 3 seconds, now it's almost unnoticeable. MemGraph has become one of my 'must have' mod (well, calling it a mod seems a little reductive). Not to sound apologetic (anyway I'm very ignorant on the subject), but Squad should look into this and eventually integrate it in the game.

@Padishar: thank you for making me enjoying the game MUCH more. In case you'd need them:

@TriggerAu : here is a save you requested: persistent.sfs please note that I've other mods installed, so maybe it's just a conflict; just to be sure I made a test removing them all and the crash persists. At the moment I've not a clean 1.2 installation, but I will check with this later today. I'm anyway posting the list: - KER - Distant Object - DropAManeuverNode - Raster Prop Monitor - Maneuver Queue - Planetshine - Precise Maneuver - Radar Altimeter - RCS build aid - Transfer window planner (the recompiled dll, but I installed it just recently, after the crashes) The save will load even without those mods installed. Steps to reproduce the crash: from space center jump to the first ship on the alarm clock list, then from this one to the next one: the game should crash consistently. Hope this helps. Edit: tested with a fresh, stock (besides KAC, obviously) ksp 1.2.1586 install, the crash persists.

Me too. Usually switching from a ship to another. It doesn't happen often, but when it does, it's usually 'persistent, meaning that if I reload the game after it has crashed and then try to 'jump to ship' from the same situation it caused the previous crash, it crashes again. To solve this, going back to Space Center before switching ship fixes it. If useful, I could provide a log of the crashes. Error.log says 'access violation': "Write to location 19930522 caused an access violation.": it's the same in all crashes. Output_log.txt says this (one from the many):

@panarchist: crew can alredy freeze/burn to death in Kerbalism if EC goes to zero/no radiators in inner planets: is this what you meant?

I've tested with the MX-4 Garnet and the MX-EXP Kerbopower. The good news is that, yes, they work in background: or so it seemed to me. But, after warping at Space Center for 10 days, I got back to the vessel that was mining on Minmus using the aforementioned reactors for power and I could no longer access the context menu of the two (that is, the buttons for starting/stopping the reacton and transferring waste/fuel were gone). Granted, I've a ton of other mods, but removing Kerbalism and starting another game with the same vessel seemed to solve the issue: the buttons were still there even after I warped first 10 days and then (always at Space Center) for another 20 days. So maybe it's a conflict with some other mod in Gamedata or it's an issue for Kerbalism: maybe someone else could test it. Then, the readouts in the VAB regarding these fission reactors seem off-scale by a factor of 100: I didn't have the time to test much else, and until confirmed I can't rule out that it could be a conflict with some other mod I have. When I get some more time I'll test again with just Kerbalism, KER, Hyperedit and NearFutureElectric.

I'm posting this here as maybe it can help someone with my same problem. A short while ago @Fraz86 posted this ModuleManager patch for CryoTanks mod to reduce EC requirements for zero boil off tanks: // Power requirements for ZBO (zero boil off) tanks cut to 25% @PART[*]:HAS[@MODULE[ModuleCryoTank]]:AFTER[CryoTanks]:NEEDS[CryoTanks] { @MODULE[ModuleCryoTank] { @CoolingCost *= 0.25 } } It won't work for me, ModuleManager won't patch the configs. I'm not ModuleManager expert, but in file CryoTanksFuelTankSwitcher.cfg in the directory Gamedata\CryoTanks\Patches which applies a patch for zero boil off tanks setting their EC consumption to 0,08 EC/second, there's this line: @PART[*]:HAS[@RESOURCE[LiquidFuel],@RESOURCE[Oxidizer],!MODULE[InterstellarFuelSwitch],!MODULE[ModuleEnginesFX],!MODULE[ModuleEngines],!MODULE[FSfuelSwitch]]:NEEDS[!modularFuelTanks&!RealFuels]:FOR[zzz_CryoTanks] that in my understanding applies the patch after practically anything else ( :FOR[zzz_CryoTanks] ). I solved substitutng the first line of code in @Fraz86's proposed patch with this one: @PART[*]:HAS[@MODULE[ModuleCryoTank]]:FOR[zzzzz_Kerbalism] This way the patch gets applied after CryoTanksFuelTankSwitcher.cfg and it works. But, as I said above, since I know about nothing about ModuleManager this may not be the correct syntax. Use at your own risk. Of course also something like this will work: @PART[*]:HAS[@MODULE[ModuleCryoTank]]:FINAL but perhaps the first solution is better.

@ShotgunNinja: the density of oxygen of 1,41 Kg/m^3 (kilograms for cubic meter) refers to the pressure of 1 atm at 0 degrees Celsius. In the industry a compressed oxygen cilinder of 40 liters (0,04 m^3), at a pressure of 200-220 bar (equivalent to about 200-220 atm), weights (gross) about 55-60 kilograms (valve included) and contains the equivalent of 8.5 m^3 (8500 liters) of gas at a pressure of 1 atm (that is about a net weight of 11 kg of oxygen). I hope this helps you to size your containers, though I have no idea how oxygen is stored in a spacecraft: being kerbals, maybe they just use the same cilinders welders use... P.S.: beautiful mod, btw

In 1.1.2 modulemanager doesn't initialize: no patch applied, mods break, included Kerbalism: wait for a module manager fix before updating to 1.1.2 EDIT> there's a new modulemanager for 1.1.2, version 2.6.24 http://forum.kerbalspaceprogram.com/index.php?/topic/50533-112-module-manager-2624-april-30th-where-the-singularity-started/&do=findComment&comment=2550514

My issue is mainly due to engaging SAS in prograde. De-select it and the problems disappear (though, well, I'm not such a good pilot I can do without SAS). The craft file I posted above has been rebuilt in 1.1.1 and the ship doesn't wobble as the 1.1 one, but the SAS strange behaviour persists (it didn't happen in 1.1 build 1230). Edit: http://forum.kerbalspaceprogram.com/index.php?/developerarticles.html/kerbal-space-program-patch-111-is-now-live-r190/&do=findComment&comment=1416 Well, maybe they're going to fix this too.

No. Good to know, thanks. Perhaps it would, if I exactly know what's wrong with it. Here's the craft file: https://www.dropbox.com/s/xu5xzlazdfijfve/Rescue MKIId.craft?dl=0 Try engage SAS at launch, set it to prograde after having started the gravity turn between 70-100 m/s and see how much the engine's bell wobble... After a while the whole rocket wobbles. This didn' happen in 1.1. And rebuilding a whole fleet of utility vehicles from scratch just to make them work again as they used to do before is a little irritating, to say the least. Especially if you had to restart a career game after 1.1 broke your 1.0.5 gameplay. True, rebuilding the same exact rocket in VAB mitigated the issue for me, though did not solve it completely. Anyway, lesson learned: backup KSP dir, so when a kew update come out (with Steam I can't opt out of auto-updates...) I will have something to revert to if things go wrong.

I may agree with you about Bloody_looser's rocket. But about the one I posted a picture of, it doesn't seem to me neither over-built, nor that it should need struts. You sure have all the reasons in this world in pointing out the design flaws of Bloody_looser's (and even mine), but the fact is that in 1.1 these worked and in 1.1.1 they don't, and in the 1.1.1 changelog there's no mention of any modification about rockets' behaviour: at least, I could not find any, though some entries might arise a suspect, but still, I'm not expert.

Infact. Someone already made a bug report that may be related to this, I posted the link up in this same thread. Since I could not find in the changelog of 1.1.1 something inherent to this behaviour, I can just assume it's a (accidentally) introduced bug or misbehaviour of some sort.

Don't want to sound harsh, and I apologize if so, but people here seem not to understand these designs worked perfectly fine in 1.1...

Probably they fixed something and broke something else! I've similar issues with some of my rockets which were rock (no pun intended...) solid in 1.1 and wobble a lot in 1.1.1, even simple designs as this: Perhaps they loosened the joints a little to fix the wheels, I don't know, I'm not expert. There's a bug report here: bug 9583 let's hope they investigate and fix it.

Tried reinstalling the game, deleting previous folders, stock: The issue is less pronounced building the ship anew, still the engine wobbles like crazy with SAS on. Thometheious, see if setting SAS on 'Pilot only' mitigates the problem: it does for me.

I have the exact same problem. I'm playing a modded game though, do people playing stock have the same issue? Edit: related to this: bug 9583

Arsonide explained somewhere that the landing legs behave as wheels (indeed they are) and this behaviour is to be expected. So it's not considered a bug (as now). So I guess it's also normal, though in my opinion not desiderable, that vessels on landing legs slide on slopes, even if I must admit that in the latest release the legs slide way less than before, usually coming to a stop after a short while. It's still possible though that a kerbal on EVA touching one will be launched in air (I did try with the LT-2 on the Mun, don't know if LT-1 and LT-05 have the same problem). And it's also possible to turn a landed vessel on legs easily using SAS with Q and E key: if I remember correctly this was not easy to do in 1.05. Edit: Found the relevant thread: http://forum.kerbalspaceprogram.com/index.php?/topic/137333-1228-lt-2-landing-strut-on-the-mun/