Starwaster

Not possible. KJR is partless therefore there is nothing to color blue.

No, this isn't the sort of thing you can cause by just enabling parts clipping. And you can do it with clipping off. I used to have it happen a lot and I never use clipping. Trust me if you run afoul of it you'll understand how screwed up it is. Several HOME parts have CoM issues and/or collision body issues. The models need some serious attention. Edit: not just CoM but CoG too.

I can, I'll post in an hour or so.

Has anyone been able to get reloading to work? I tried it and no MM patches were reloaded at all.

Nathan, I've been doing some experiments involving adding the thermometer module directly to radiators and fuel tanks (insert some KSP science joke about research values here) I need to play with it more but it's looking like it's a bad idea to actually increase the radiator temperature. It might be realistic but it's looking like it's doing bad things to tank temperature because of KSP's wonky heat system. On a big tank (KWR 3.75, the longest one) I stuck 24 radiators and played with them a bit in action groups so I can control how many are active. They rapidly accumulate enough heat to counteract the cooling effects. KSP wants to transfer that heat right back to the tank and it can do it faster than MFT can move it out again. just to give you an idea of just how screwed up KSP's model is: temperatures fluctuate wildly in orbit around a planet. the midnight position is worst because it suddenly and rapidly heats everything up. Noon actually gets pretty cold but only briefly. some of the radiators btw get up into the 200K range and they're all fighting to dump that back into the tanks.

Bottom is most recent and if they're too fast to read then that's a bad sign. Probably they are null object errors. In your install directory, look for a folder called ksp_data and find the file named output_log.txt in there. If you have a dropbox, put that file there and tell us the link. If you're not able to do that then paste just a part of it that has the errors. (go in vab, long enough for the errors to start then exit the game and grab the errors from the end) If you dont have that file at all (Mac or Linux) then get the ksp.log from the install directory but it's not as informative as an output_log.txt is

I know what he's talking about and it could even be a stock problem. I think it started in .21 but maybe .20 and it's intermittent. I've never been able to isolate it to any particular mod which is why I've grown skeptical that it's even mod-related. Other mods have been blamed for this same bug over the past few months and supposed repro steps provided that never can be reliably verified by others. My own thoughts as to cause revolve around unsuccessful symmetrical placement attempts that corrupt the placement process so that when you finally do get successful placement you end up with a corrupted craft. And if you save, a virtually irreparably corrupted craft file. That's why any time I try and fail to place a part in symmetry mode I delete the part and spawn another. But I might be just as wrong as everyone else to encounter this bug and my remedy might just be a placebo. tl;dr it's not your mod at all.

Post the MM codes you're using and let's take a look at it.

Oh the box was very much checked and the rocket was at terminal velocity so that part of the plugin was definitely behaving as it should have. And since apparently the UI is the very embodiment of perfection with no room for improvement then I guess Jean just has no excuse and should have known better. PEBCAK error; case closed.

what does the debug screen say? (or output_log.txt)

Actually, another 4GB would help even if KSP can't use it directly. If he has only 4GB, then KSP and his operating system are competing for resources. 4GB for KSP + 4GB for his OS gives him some breathing room.

MM doesn't care how many cfg files you have. It doesn't even look at the files, at least not literally. Check capitalization. It's case sensitive, both node names and their values.

http://lmgtfy.com/?q=term+factor

Ok so it's crashing because Mono had a problem and explicitly aborted. This is probably the Linux equivalent of the memory errors that Windows users of KSP keep seeing. I've thought for awhile now that Mono is just bad at managing memory. Not sure yet what the solution is yet.

if there was a dump then there's a dump file. It can be analyzed to see what the error was and where it happened. There was a time I could have told you exactly how to go about that in Linux. Those days are long past, back when dinosaurs roamed the world. My money's on a segmentation fault though.

term factor.

There is no cheating. It's your sandbox (even if you aren't in sandbox mode) If you go along with it then it's because you chose to, but that's ok too if that's what you want.

Yeah. Sorry.

This is the file that resulted in the sample error I posted. @PART[radiator1]:Final { @mass = 0.025 MODULE { name = ModuleHeatPump heatTransfer = 50 heatDissipation = 0.05 RESOURCE { name = ElectricCharge rate = 0.01666667 } } }

I wish them luck! Mars has been a rough place on probes statistically speaking. The Martians value their privacy.

He told him to clear the box that enables / disables the option and that is the correct solution and offered his opinion on why he (jean) might not have realized that the option was there, because for whatever reason the answer was staring him in the face and he wasn't seeing it. what more do you want from Galane? No you do not. See answers given on this subject a few posts back.

look at Sephlington's post above. Edit the part.cfg file (for the AR202) and remove all references to tech. You should be left with the following. MODULE { name = MechJebCore } If you use ModuleManager together with Sarbian's MM extensions you can make a config file like this that adds MJ to all commandpods MJ_for_all.cfg @PART[*]:HAS[@MODULE[ModuleCommand],!MODULE[MechJebCore]] { MODULE { name = MechJebCore } }

Not sure where he's got to this time. He's always stowing away on rockets. He was supposed to be back on Kerbin training for an upcoming Duna mission. He was supposed to be training to command one of the ships in the convoy. Next thing I know he's on the crew transfer shuttle as it's docking with Minmus Mining Station #1.

Happens on all :Final directives [ModuleManager] Exception while processing node : MyTweaks/radiator_patch/@PART[radiator1]:Final System.ArgumentOutOfRangeException: Cannot be negative. Parameter name: length at System.String.Substring (Int32 startIndex, Int32 length) [0x00000] in <filename unknown>:0 at ModuleManager.ConfigManager.applyPatch (System.Collections.Generic.List`1 excludePaths, Boolean final) [0x00000] in <filename unknown>:0

Your code weeds out nodes with blank names. Won't it weed out the above? Or for that matter, won't it also weed out the following? !MODULE[MechJebCore]{}