BudgetHedgehog

Yeah, the first is one of the most common causes for crashes. x86 KSP will always meet its limit before x64 OS will stop limiting it. I force OpenGL for my x86 KSP and still use about 2Gb - without it, using DX9, I run about about 3.4 odd Gb. Doing pretty much anything crashes it. And yeah, as I mentioned in mine, the x86 OS-enforced limit can be changed by allocating more VRAM. I agree with you on that, yes

Slightly wrong there - KSP on a 32bit OS can only use about 2Gb, due to the OS limitations (that can be changed as above). 32bit KSP can actually access about 3.5Gb before it crashes and to do that, you need to either have a 64bit OS or tell it it can use more (if you have a 32bit OS). I think you're confusing 32bit KSP and 32bit OS. You can't switch between x86 and x64 OS, but you can change how much RAM 32bit KSP is allowed to use (provided you have an x86 OS. x64 OS will always allow more RAM usage than x86 KSP can actually use).

No EVE overhaul and I assume DX9 is the standard default launch option used when none is specified? If so, then yes, real reflections work, hurray! But I use about 3.3Gb of RAM then and screenshotting crashes the game. So it seems I either use OGL and have to make do with static reflections or have real reflections and crash after 5 minutes. What, remove some mods? Preposterous idea..

Shouldn't, but it is. Humour us, copy and paste your KSP install somewhere other than Program Files and see if that works or not.

KCT aside, that is known problem of the x64 version and also happens on x86 if you use an outdated version of KK. Redownload KK and reinstall and try on x86. Also unless you have intentionally disabled it, there will be an output_log.txt. It's in KSP_Data.

Voylent Green is made of Kerbals! EDIT: squadpls..

Have I mentioned how much I like this mod? Because it's a lot.

Same Can I ask why they're getting removed?

No errors reported yet, so a hesitant yes. Still no real reflections though.. I'd post a picture, but every time I screenshot, the 'real' reflections (a light blue emissive reflecting Kerbin and its clouds as if I was in high orbit facing towards it) disappear from the visor and my Mk1 pods windows and am left with the same result as what happens when I select None on reflections.. I don't know if it's related to resolution (1366x768, OpenGL borderless window, with a SCREENSHOT_SUPERSIZE of 2) or what, but yeah.. thanks for the dll though, that appears to have stopped the errors (or at least, the logging of them).

I have 2 problems: 1, real reflections still aren't working for me and 2, I'm getting this spammed in my output log: [TR.TextureReplacer] System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[TextureReplacer.Reflections+Script].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at TextureReplacer.Reflections+Script.updateScripts () [0x00000] in <filename unknown>:0 at TextureReplacer.TextureReplacer.LateUpdate () [0x00000] in <filename unknown>:0 I do have Vens Revamp 1.7 installed which has the following TR MM config applied to several parts: @PART[rcsTankRadialLong]:NEEDS[TextureReplacer] { %MODULE[TRReflection] { %colour = 0.2 0.2 0.2 %meshes = obj_base tank } } EnvMap, Heads and Suits are emtpy Is anything amiss? Want me to post the full output log (though I did a quick search and everything related to TR was nominal before the above errors)? Pls help, I has a sad

Ferram explained it very well on reddit the other day:

I suffer the crashes until ATM gets updated to compress moar memory, so I add more mods in. My 0.24 save was really bad, I had a boatload of mods for that. Crashes almost every hour. Most of those haven't been updated for 0.90 so I don't mind leaving them behind and I'm running at a very stable 2.5Gb or so now and can play for hours without (memory-related) crashes. Also, I approve of this thread title.

NEAR doesn't model skin drag and mach tuck - both help slow down vessels as high speed. FAR models both and I'd recommend using that (and disabling the disassembly option) but if you'd rather stick with NEAR, you'll need a much shallower re-entry patch so you stay longer in the atmosphere, as thin as it is. But yeah, 5km isn't that high at all.

It's the sticky at the top of this forum. Has a boatload of other useful stock bug fixes as well.

Are you using the 64bit version of KSP? Have you tried installing Claws Radial Decoupler Bug fix? Because it sounds like something's messing with the decoupling module and those are the first things that spring to mind.

So I was building a Shuttle yesterday and realised something - the Mk3 cargo bays have two end nodes in the same place, one size 3 (presumably for attaching the cargo bay to other parts) and one size 2 (presumably for the payload) - the comment "// 2nd nodes are for the inside" confirms this. Trouble is, whenever I put the cargo bay on, it attaches via the weaker size 2 node instead of the size 3 node and lets my MP tank and cockpit wobble around like a wet fish in space and in extreme cases, just fall apart when I release the launch tower. The only way I can see around this is attaching the cargo bay radially (via EditorExtensions), attaching something to the end node (as it defaults to the cargo bay node), attaching the cargo bay inline using the free size 3 node, removing the temporary part and then building the payload. I haven't tried that, but if that doesn't work then I'm out of ideas. How can I make make the cargo bays attach via the size 3 node without a time-consuming and annoying workaround? Am I missing something here? Probably, but I'd love to know what - this is frustrating. The SP+ parts had a similar issue, but the nodes were in slightly different positions, you could tell if you'd attached it correctly because the fuselage would line up. The Mk3 though, the nodes are in the same place so.. yeah. (also, I found that the Mk3 parts do have the same lifting body hack that the Mk2 parts use, but it's commented out. Anyone know why?)

OutOfMemoryException: Out of memory at (wrapper managed-to-native) object:__icall_wrapper_mono_array_new_3 (intptr,intptr,intptr,intptr) at LibNoise.Unity.Generator.VoronoiCached.ConstructCubeArray () [0x00000] in <filename unknown>:0 at LibNoise.Unity.Generator.VoronoiCached..ctor (Double frequency, Double displacement, Int32 seed, Boolean distance) [0x00000] in <filename unknown>:0 at PQSMod_VoronoiCraters.OnSetup () [0x00000] in <filename unknown>:0 at PQS.Mod_OnSetup () [0x00000] in <filename unknown>:0 at PQS.SetupMods () [0x00000] in <filename unknown>:0 at PQS.StartSphere (Boolean force) [0x00000] in <filename unknown>:0 at PQS+ .MoveNext () [0x00000] in <filename unknown>:0 Well, I've never seen that one before. Have you tried verifying the game cache?

From the FAQ:

Regarding GUI sizes - they can be changed in the KER settings in the editors. Also, I've noticed that KER doesn't clear it's input lock cleanly. In the below picture, my cursor is roughly where the red dot is and after expanding and compacting the KER window, it's still registering the input lock from the expanded window, as can be seen in the debug menu. Just a little report for whenever cybutek comes back.

I could then argue that it is the mod authors duty to provide a not so unreasonably large icon size. 51kb is plenty large enough, as can be seen by the clear icons that weren't compressed. Trying to make a one-size-fits-all exclusion config won't work if some sizes are just way too large. Either that or you just put up with slightly fuzzy icons, I guess. EDIT: Though, there's nothing stopping you resizing the icon yourself. Just sayin'.

Just a quick question for people using these - is TweakScale stable enough for it? Literally the only reason I haven't installed IR or these parts is because TweakScale was causing too many problems and breaking apart vessels. So I uninstalled it for now while I wait for those bugs to be fixed, but of course, now I can't rescale these robotic parts. Am I being overly cautious? Is it ok to have TS and remove all configs except ones for these (it's been so long though, that I can't remember if these come with their own configs or one is supplied by TS)?

I think it's more of a problem with TweakableEverything as I have that exact problem and don't have TweakScale installed. It usually fixes if I delete the part and grab a new one though.

.. I'm a moron. Found it - Stock Rebalance was hiding in my SurfaceLights folder. Thanks for the help!

Is there a way to see what cfg did what patch? For example: my OX solar panels (the uncovered ones) are non-retractable and I'm pretty sure that's not stock behaviour, but I don't know which of my mods changes this, or where the cfg itself is. AFAIK, the only mod that changed this was Stock Rebalance Project but I don't have it installed. I opened the ConfigCache in Notepad++ and all I have is: UrlConfig { name = solarPanels3 type = PART parentUrl = Squad/Parts/Electrical/2x3SolarPanels/2x3SolarPanels url = Squad/Parts/Electrical/2x3SolarPanels/2x3SolarPanels/solarPanels3 PART { name = solarPanels3 module = Part author = NovaSilisko rescaleFactor = 1 node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0 TechRequired = advElectrics entryCost = 4100 cost = 600 category = Utility subcategory = 0 title = OX-4W 3x1 Photovoltaic Panels manufacturer = Probodobodyne Inc description = The OX-4 is similar in design to the SP series solar panels, [B]but without the ability to retract once deployed,[/B] nor the heavy casing. attachRules = 0,1,0,0,1 mass = 0.02 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 1 crashTolerance = 8 maxTemp = 3200 MODULE { name = ModuleDeployableSolarPanel animationName = altsolarpanelbase resourceName = ElectricCharge raycastTransformName = suncatcher chargeRate = 1.4 [B]retractable = false[/B] powerCurve { key = 0 10 0 0 key = 13599840256 1 0 0 key = 27199680512 0.25 0 0 key = 40799520768 0.1111 0 0 key = 54399361024 0.0625 0 0 key = 67999201280 0.04 0 0 key = 81599041536 0.0278 0 0 key = 95198881792 0 0 0 } } MODULE { name = BBModule } MODULE { name = CollisionFX scrapeSparks = true collisionSound = CollisionFX/Sounds/Bang1 scrapeSound = CollisionFX/Sounds/GroundSkid sparkSound = CollisionFX/Sounds/SparkSqueal } MODEL { model = VenStockRevamp/Squad/Parts/Electrical/SolarSmall/model2x3 } MODULE { name = TRReflection colour = 0.6 0.6 0.6 meshes = Panel1_002 Panel1_001 Panel1_000 } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.00, -0.22) evaPartDir = (0,0,-1) storable = true storedSize = 10 attachOnPart = True attachOnEva = False attachOnStatic = False attachSendMsgOnly = False } MODULE { name = ModuleTweakableSolarPanel } } } I'd like to find the cfg that changed that (bolded text). Is it possible?

That. Above nominal, but below absolute limit. The original suggestion, and what was eventually implemented in 1.3 was: