Search the Community

My game is crashing to desktop before even beginning to load the game files (splash screen, loading hints and the yellow progress bar do not appear.) This is happening in an unmodded KSP 1.1.3 build. KSP.log: Kerbal Space Program - 1.1.3.1289 (LinuxPlayer) OS: Linux 3.16 Debian 8.5 64bit CPU: AMD FX(tm)-4300 Quad-Core Processor (4) RAM: 16065 GPU: AMD Radeon R9 200 Series (1630MB) SM: 30 (OpenGL 4.5 [4.5.13399 Compatibility Profile Context 14.201.1006.1002]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8 Log started: Tue, Jun 28, 2016 11:34:28 Player.log: http://hastebin.com/apovawodok.vhdl Neither are very helpful. Mono version: Mono JIT compiler version 4.4.0 (tarball Tue Jun 14 13:41:51 UTC 2016) My WM is Openbox, running AMD fglrx drivers, waterlubber@GamingPC:/mnt/main/home/waterlubber$ fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: AMD Radeon R9 200 Series OpenGL version string: 4.5.13399 Compatibility Profile Context 14.201.1006.1002 Any help would be appreciated, thank you. I was able to solve this issue by running -force-gfx-direct on the terminal when starting the game. Leaving this post up for other people.

So I just built and shipped a large tanker in my career game. Unfortunately, when I try steering, the wheels will not turn or rotate or anything. It doesn't roll down hills either. This is on windows in 64x KSP.

On my ladder the kerbal slowly slides down it is the same on the airlock the kerbal bumps up and down the B to bord also flashes it is really odd. I know you guys are good thanks EDIT: It terns out that the error was just the scale in blender not unity now to problem is solved I can update my pod now.

Download link for output log, saved games and craft files. Didn't experienced such heavy memory leak for a while. Playing with this mods for a month, usually game is stable enough for one hour or two, but this time crash in less than 2-3 minutes. As you can see on pictures(memory usage shown on left side), memory usage increase every few seconds until game crash. There is persistent save game and quicksave with plane in flight that need to land near contract spot. Spoiler section contains list of installed mods. On top of that is also latest FAR development release from github. Output log file didn't gave me a clue for possible reasons behind CTD. Does someone have idea what can be reason behind this, so I can avoid it somehow ? EDIT: Nevermind. Figured out. It was terrain detail set to max. Too many trees comes to vison range. Each time some tree become visible it consume small chunk of memory. It would not be much of issue if trees that goes outside of vision range release used memory. That never happens and RAM is filled up too quick in some areas of planets. I have set terrain detail to low and same save game is playable again without memory leak.

Hi all, During the course of my modding adventures, I have found a need to create a custom heat shield module for use specifically to be integrated into other existing parts (such as command modules). I have it functioning reasonably well though a bit of trial/error/process of deduction regarding how the stock shield seems to function. However, I would like to improve its functionality to eliminate some of the quirks the stock mechanics have, such as the part skin temperature still hitting insane levels when the heat-shield is in-fact the part with the high temps (as such the entire parts starts to glow with the thermal-overheat-emissive). (E.G the stock heat-shield does not start ablating much until ~1500k, at which point the overheat-glow is already triggered; unacceptable for an entire command pod to appear to be 'overheating' when the heat shield is in fact functioning properly and keeping things from exploding/overheating). The main question I'm having is: What does one unit of flux represent? While interfacing with the API/methods, it has it listed as KiloWatts. Okay, I know what a KW is (assuming 1 flux == 1 KW). But it seems there is missing something from the equation. One KW does not equal one degree for every part (logically anyhow, higher-mass parts should take more energy input to heat up). Background: I know little about thermodynamics, it is not anything that I have studied nor have any particular knowledge base regarding it. If one 'thermal flux' unit = 1 KW of thermal energy -- It seems that I need to know how much one KW of energy will increase the temperature of a part, which I believe will be different based upon mass (and in real life, material composition/specific heat capacity). Also, how does KSP treat the 'specific heat capacity' of different materials? Is this simulated at all? (e.g. concrete, steel, and insulation foam all have different thermal absorption/storage properties for the same mass). Thanks in advance for any answers and information, is much appreciated Updated with proper information: Thermal equations: To change part temperature X degrees (instantly): flux = X * part.thermalMass * (1 / TimeWarp.FixedDeltaTime) degrees kelvin temp increase = (flux input / part.thermalMass) / ?? (there is a time factor involved that I have not figured out yet) flux stored in a part = part temperature * part.thermalMass * ?? (there is a time factor involved that I have not figured out yet) one degree kelvin increase requires (part.thermalMass) flux input for (?? time factor, ignoring part conduction/convection/radiation that happens during that time). Edit/Update: One thing I still have not been able to figure out -- how to disable the part glow effect? (not the aero-thermal effects, nor the debug-thermal glow effects, but the standard glow effect?) I've got the heat shield functioning effectively; but the entire command pod starts to glow whenever skin temp > 800 (not sure of the threshold, first noticeable around there). (and if I try to clamp the skin temp at ~600, the incoming flux to keep the temp there is insane; the simulated heat-shield ends up with ~10x the heat intake that it -should- have, due to improper simulation of the skin->ambient delta and how it attempts to equalize them) Apparently this is the black-body radiation glow, as messing with the blackbody min temp in Physics.cfg will make it go away / change the start point. Any known way to disable this feature for a specific part? And a bit more investigation has revealed that this function is hardcoded somewhere within the part.Update() function(s), using what must be private methods and members (as there is nothing visible to interact with). Is my only option to change the BlackBodyRadiationMin value? And will this have any non-visual side effects? (that glow is purely annoying to me, and I have no problem removing it entirely from my games, as long as it doesn't mess with anything else).

Hi all, I have a concept for a decoupler part that can automatically activate a secondary engine on a part when it decouples. This would be, for example, for an SRB with integrated jettison motors. The 'main' engine would be the SRB, using SolidFuel, the 'secondary' engine would be the jettison motors, using a second custom fuel type (JettisonFuel/etc). The decoupler would trigger upon depletion of the main-engines resource (or whatever is specified in the decoupler config), which would then trigger the activation of the MultiModeEngine and the secondary jettison motors. Normally when interacting with stock modules in this manner, I would call their publicly exposed GUI interaction methods, to trigger the action as if it was triggered by the player (seems to save a lot of headache / makes sure you are interfacing with the code in the right place/manner). Now, the problem with this approach with MultiModeEngine is that everything appears to be private? I was under the impression that things flagged with [KSPEvent] and [KSPAction] had to manditorily be public methods, but apparently this is not the case as I cannot locate any externally accessible methods that correspond with its actions/events. So, the question is -- how to properly interface with MultiModeEngine module through a secondary module to trigger MultiModeEngine to switch from primary to secondary engine? Can I get a reference to its Events["eventName"] or Actions["ActionName"] and trigger them from there? Any other ideas on how to get this working? Solution: Yes, interacting with the methods through their Events[].Invoke() method works fine. You just need to know the name of the method to trigger.