Starwaster

They need to have the same MODULE's added that an MKS/OKS part would use to provide the same functionality that you need. Ask in the MKS mod what you need added. Don't edit part files directly, make a module manager patch to do it. (i.e.) @PART[inflato1] { MODULE { name = <INSERT THE NAME OF THE MKS MODULE THAT YOU NEED) whatever else the module needs. } }

Create a new save game for this or backup your existing ones because these troubleshooting steps can cause loss of ships and lives. Delete Orbit Manipulator, Real Solar System and Procedural Parts. Reinstall them one at a time, starting KSP and loading into your game saves after each reinstallation and check to see if problem persists. Post results

If you're using RealFuels (or possibly Realism Overhaul) and the engine has any spoolup time then that could be throwing MJ off....

Loading, saving and reloading existing craft with those modules can also help. (after updating) That's also good generic advice anytime you're dealing with altered PartModules

Yes though I find the ring and the larger inflatables a little unwieldy for anything but orbital use because of their size. (and the ring because of its rotation) Regarding the ring habitat, there is an animation issue that renders it uninhabitable if both rotation and inflation animations are activated. Bug affects both stock and Firespitter animator modules. See my link below. Download the plugin mentioned there and the config file. Install the plugin and put the config file anywhere in your GameData folder. Preferably in a folder that you keep for such patches or in the Habitat's folder. http://forum.kerbalspaceprogram.com/threads/64442-0-23-5-Habitat-Pack-v0-4?p=1448802&viewfull=1#post1448802

I didn't know he had one... I hope it has nothing to do with that movie....

WRONG. The game always generates logs whether it crashed or not. Whether it throws exceptions or not. Unless you disabled logging you have log files. Always. Click the link below for instructions on finding your log files http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-%28READ-FIRST%29 (obligatory to make people think that my CAPS above doesn't mean I am angry)

So much this. See above! Instead of literally thinking of them as the same engine, just think of it as redesigned or retooled at worst. At best it's a totally new engine that just happens to look the same.

Well it's a big boy's (girl's) solar system. Stock KSP is the 'kid's table'

Just remember that if you go adding ablative and you're using any sort of aerodynamic correction (FAR, NEAR or SDF) then that added mass is going to make it harder to brake. Inertia's a <female dog perjorative> sometimes. And she's having puppies.

Worked for me. But then I was doing it to address a specific problem area in my large rockets with certain lightweight decouplers. It's not a magic bullet.

Not unless you're talking about writing your own plugin. If that's the case then just use vessel.geeForce_immediate But I thought you were talking about what was already available in MechJeb's existing windows or windows you create with the MJ windows editor.

You need to post logs (output_log.txt. player.log if mac/linux) You're getting errors, either when the craft loads in or continuously spamming the log. Depending on where the error occurs it can have different strange results, including a craft gradually picking up heat that it can't shed.

Sure, for parts that are heat shields. Most spaceplane parts are so equipped as are the heat shield parts in the mod and in other mods that have DRE configured heat shields. The Mk1 command pod already has a heat shield. The Mk1-2 has to have one attached to its bottom.

Additionally Line 23472: [ModuleManager] ModuleManager: 721 patches applied, found 4 errors Line 23473: 4 errors in GameData/RealFuels/KSPI_RF.cfg and [ModuleManager] Applying node RealFuels/KSPI_RF/@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:FOR[RealFuels] to WarpPlugin/Parts/FuelTank/fnmethaneTank/part/FNMethaneTank3-1 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [ModuleManager] Cannot parse variable search when editing key volume = #$../MODULE[ModuleFuelTanks]/temp$ (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [ModuleManager] Cannot parse variable search when editing key volume = #$../MODULE[ModuleFuelTanks]/temp$ (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [ModuleManager] Applying node RealFuels/KSPI_RF/@PART[FNMethaneTank*]:HAS[@RESOURCE[LqdMethane]&@RESOURCE[Oxidizer]&!MODULE[ModuleFuelTanks]]:FOR[RealFuels] to WarpPlugin/Parts/FuelTank/fnmethaneTank/part2/FNMethaneTank3-2 (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [ModuleManager] Cannot parse variable search when editing key volume = #$../MODULE[ModuleFuelTanks]/temp$ (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) [ModuleManager] Cannot parse variable search when editing key volume = #$../MODULE[ModuleFuelTanks]/temp$ Not being familiar with KSPI or the parts that have the exceptions, I don't know if they're linked, but there's something wrong in that config before KSPI or RF get involved. (those are Module Manager errors)

That problem is sort of on my radar already though I'm seeing something in your log file that's new. Namely that there's errors while initializing the chute warning message. I trapped those errors to prevent them from breaking other things but it does beg the question how you're seeing the chute warning messages if it couldn't initialize them. Obviously I'm going to have to rethink how I'm handling messages. I should only be initializing them once as a static field is what I should be doing....

Couldn't find the profit... If you only need reentry g-forces then you can use drag. For the landing window there's also projected max drag forces. That's good enough unless you explicitly need non-drag g-forces.

PhysicsSignificance = 1 You could make a ModuleManager patch that blanket adds it to anything with ModuleDecouple but that might well catch something it doesn't need to. The only place I really feel the need to use (large decouplers w/ low mass) it is the KWR parts so I do this: @PART [*]:HAS[@MODULE[ModuleDecouple]]:HAS[#manufacturer[KW*Rocketry]]:FINAL { %PhysicsSignificance = 1 } Also added it to my docking ports.

Hypothesis: Something is throwing exceptions in a bad spot and it's preventing parts from dissipating heat. So they keep taking in heat but not shedding it. Impossible to confirm or dispel this hypothesis due to a noticeable lack of output_log.txt file (or player.log file if Linux or Mac)

Actually I've been having some luck with dephysicalizing all decouplers. It occurred to me that having them as physical objects doesn't contribute significantly to the game at all. They stay attached to jettisoned tanks and are typically never seen again so why bother? My KWR rockets are rigid now without resorting to a metric **** ton of struts instead of looking like an experiment in ragdoll physics. (non sequitur but did you know that it is illegal in Germany for FPS games to incorporate ragdoll physics into corpses? True story. Crytek had to disable corpse ragdoll physics in its Cryengine based games because it was the law)

http://well-of-souls.com/tower/plague.wav

It is normal but you can change it if you want a wimpier reentry. The altitude at which heating occurs is linked to densityExponent. Small numbers of densityExponent mean that reentry heating will start at higher altitudes during descent. Conversely, it also means that it starts at slower velocities during ascent. Larger numbers mean reentry heating doesn't start until deeper into the atmosphere. If using the beta, the values for densityExponent per difficulty are: Easy = 0.9 Normal = 0.8 Hard = 0.5

Actually, the base cause is either Unity's event system or KSP's implementation of it. Null references in events are common place. Every modder needs to assume that an event they've tied into will be called multiple times with invalid data for each valid event firing*. Either the EventData parameters need to be checked for nullrefs or the entire thing encapsulated in try/catch. I used to think the error itself was ignored on event calls but that's not the case. Such errors can have cascading effects by breaking further code execution in the method responsible for firing the event. * i.e. when Part.decouple fired the OnVesselWasModified event, it spawned one event with valid Vessel data alongside of multiple event calls with a null reference for Vessel.

Try Orbit Manipulator: http://forum.kerbalspaceprogram.com/threads/70881 It does what you need.

You alt-tabbed away from the game. It can't render the screen if it was in fullscreen mode and you alt-tabbed away so it reports an error about it. It doesn't hurt anything. (I alt-Enter to switch out of fullscreen mode if I need to tab out) Some tga textures do that randomly.