Wisq

Any way to increase the UI scaling? It's tiny on my 4k screen, and it doesn't respect the overall KSP UI scaling setting.

Installed the latest from CKAN (v1.0) and it caused my game to crash on startup — I couldn't find anything useful in the logs, it just died before it even reached the splash screen. v1.0.2 from the download link seems to work fine, though, so I'm assuming this is just the "Fix RCSBuildAidToolbar.dll dependency" change from v1.0.1?

Okay, turns out I can actually just edit the SMURFF rules that trigger on LiquidOxygen and Oxidizer, and set them to :BEFORE[ConfigurableContainers]. Once I do this, the FL-T200 has 31kg mass, which is the same as what it has when SMURFF is installed but Configurable Containers is not. What's a bit weird is, I can't seem to get the same effect if I go into ConfigurableContainers and set them to run :AFTER[SMURFF] or :AFTER[zzz_SMURFF]. Not sure what's going on there.

Actually, Configurable Containers works differently: It doesn't touch the dry mass for the default case, but some resources (I think e.g. xenon?) may add mass based on volume. As a test, I set up a 100% stock game with just ModuleManager, and added a .cfg file of my own that reduced the dry mass of the FL-T200 tank to 42kg instead of the default 125kg. Under ModularFuelTanks, you're correct, the mass was reset to 125kg. But under both stock and Configurable Containers, the dry mass remained 42kg. However, Configurable Containers also removes the default resources, meaning the tank no longer carries LFO by default. I'm thinking that may be what makes SMURFF not recognise it as a tank? Is there a flag I can set (other than adding a resource) to force SMURFF to adjust it?

Just so you're aware, there seems to be an incompatibility between SMURFF and both "Modular Fuel Tanks" and "Configurable Containers", the two mods that let you stick any sort of resource into your tanks. Any tank patched by either mod (i.e. all(?) tanks when these are installed) will not have its dry mass correctly adjusted by SMURFF. E.g. the FL-200T will have 0.125 dry mass with/without SMURFF. I suspect this may be because they don't come with any resources by default, so they don't trigger the mass reduction? (On top of that, there's a direct incompatibility between Procedural Parts + Configurable Containers — the procedural tank dry mass is always 1.0 tons, no matter what size or contents. But this is between those two mods and has nothing to do with SMURFF, so.)

I'm pretty sure the tank heat issue was also just a symptom of my botched way of running Kerbal in Steam. I'll be back here if that's not the case — but so far, all my tests seem to indicate everything is fine now, thanks.

Okay, I tracked it down! It's the weirdest thing ever, and it's 100% my fault, sorry. Basically: Since I don't want Steam doing anything stupid re: auto-updating my Kerbal — and because I want to have a fresh Kerbal to copy for mod testing — I don't actually run it out of the SteamApps directory. Instead, I copy it to a different directory — e.g. c:\games\ksp\1.2.2 — and run it there. BUT, I do like having Steam say that I'm playing it, and tracking my hours, and the in-game overlay, and etc etc. So I set the Steam app launch options to "c:\games\ksp\1.2.2\KSP_x64.exe" %command% which makes it run that instead. And everything seemed fine! However, it's clearly NOT fine, because if I run Kerbal via Steam, I get all these bugs, but if I run it via CKAN, I don't get the bugs. Oops. My hypothesis was that Steam was running the correct EXE file, but not changing the working directory before it ran it. (I'm frankly surprised this actually worked!) Presumably, most mods would read their data files based on the location of the EXE — probably using API functions provided by KSP? — but some would try to read and write directly to the working directory, and were thus using stock data (or no data) instead of correct data. The quick and dirty solution to test this (without moving anything and messing with the experiment) was to create a KSP..BAT file that would CD to the correct directory and run KSP, and see what happens when Steam runs that instead. Lo and behold, I was able to do reentry once I set that up! Anyway, sorry for the confusion here. I'm going to rebuild my install because it's probably been pretty pooched by this abuse on my part, but I should hopefully be able to keep using my campaign and .craft files. I'll have to go see if my cryogenic tanks issue is fixed too.

Well that's interesting! I can indeed land a Mk1 pod with an Mk16 parachute in a stock install with just RP-0 installed, perigee 50km, and only use 50/200 ablator. Furthermore, it's a lot faster to load and a lot more responsive, and also, the atmosphere effects (red glow etc.) don't start until much later — well below 70km, where my parachute was catching fire and exploding last time. There's definitely something messed up in my old install. Going to start fresh and install my old mod list slowly to figure out what's going on. Thanks.

Yeah, installed via CKAN, just asked for RP-0 and accepted all the recommendations, etc. RealHeat is definitely installed. Zero non-CKAN mods installed. Interesting note: TestFlight does not get installed by default, despite being in the Recommended list for RP-0. (Just tested with a fresh install.) I'll see if any other mods are missing. Edit: PersistentRotation is also Recommended by Realism Overhaul but missing. And by "missing" I mean "did not show up at all on the recommended list when I hit Apply Changes" — I didn't deselect anything. (However, I specifically installed it in my game.) It also doesn't install the recommended mods "Realism Overhaul Craft Files" and "RSS Date Time Formatter" (which I don't have installed). Are we looking at a bug in CKAN here … ? But I don't think any of those mods would have affected my heat issues.

Okay, it looks like the problem was either the Mk16 parachute itself, or how it was fitting on my craft. I replaced it with a RealChute Cone Chute, one size smaller than default (so it was flush with the capsule), and didn't have any problems any more. Looking at the thermal debug info, it looks like the problem was that the Mk16 was getting ridiculous external skin temperatures, in the 1000ºK+ range. (The cone chute never went above 600ºK skin temperature.) In every test I did — 60km, 50km, 40km, 30km — the Mk16 parachute would catch fire at 70km altitude and explode before 60km altitude, long before I was seeing even just 1G of deceleration, while my speed was still up in the region of 6000 m/s. So there was just no hope of using that one. Edit: Are the margins supposed to be this tight, though? I mean, with only a capsule and a parachute, at almost any reentry angle, from the bare minimum possible orbit (140.1km), I'm either coming out of reentry with only ~3 ablator left, or I'm just barely running out and blowing up, at almost any choice of perigee altitude — I've tried as high as 90km and as low as 30km.

So I'm having some serious heat issues: 1: If I have any cryogenic fuels on board, heat goes nuts as soon as I cross from 100x to 1000x time warp. I understand that this is when Kerbal goes from "simulation mode" to "analytical mode" as far as heat is concerned, so I'm assuming this is the cause. Now, I fully understand that there's boil-off of cryogenic fuels, but the tanks aren't actually the problem — what happens is, other components on my ship start overheating and exploding, almost always starting with my communication antennae (I think because they have the lowest heat tolerance?). 2: I can't survive reentry to save my life. I've tried what ought to be the absolute gentlest reentry possible — starting from a circular orbit just above the atmosphere (140.1km) and then dropping my perigee to some reasonable number (generally in the 90km to 110km range). Every time, what happens is, my parachute (Mk16) overheats and explodes first, and then my capsule next. If I put the lunar-rated 2m heat shield on it, then the capsule survives okay, but the parachute still burns up, so it's game over for the capsule anyway. Given that these bugs both involve heat (albeit different issues in different modes), I'm wondering if I've got some mess-up in that area? I've got RP-0 and all dependencies and recommendations installed, except TestFlight. I've also got a few extra mods on top of that, but none of them should be touching heat. If those are the suspected cause, I can try a fresh install plus RP-0, but I'm hoping this is a known issue and/or I'm just doing something wrong.

Yeah, lots of "Activator for DMagic.Part_Modules.DMModuleScienceAnimate" messages in my logs if I turn debugging on.

Love this mod so much. Thanks. One feature suggestion: Perhaps you could add a second threshold for single-use experiments? So I could set e.g. 0.01 threshold for repeatable ones, but maybe a threshold of 10 for single-use ones. (This could potentially replace the single-use checkbox, because setting it to something unobtainable like 9999 would be the equivalent of unchecking the checkbox.) Right now, if I want to pick up all the teeny tiny reports (especially on a high difficulty with science scaled down) I have to set the threshold very low — but since physical experiments tend to not fully collect on the first go, it ends up redoing a lot of physical experiments when it ought to be saving those for later in the flight (and rendering them unusable if I've got transfer enabled).

Oh, cool, that makes a lot of sense then. So it won't be a cure-all but it will mark the beginning of much easier bugfixing. Not as fast an outcome as my original "Unity 5 will solve our 64-bit problems" assumption, but not nearly as bad as my new "Unity 5 won't help much with 64-bit at all" worries. Good to hear, thanks!

(Sorry if this has been asked before, but searches were coming up empty.) I tend to run a pretty heavily modded Kerbal, to the extent that there's really no way for me to run it 32-bit. I also play on Windows, because that's what my gaming machine runs and that's where all my recording and editing tools are. (Also, I tried the Linux 64-bit build, and I was getting really annoying mouse lag.) Up until now, I've been assuming that Unity 5 would solve most of the Windows 64-bit bugs. After all, Kerbal works great on Linux 64-bit, and Windows 32-bit, but just not Windows 64-bit — and since Unity's supposed to be a cross-platform engine, that suggested to me that the problems were platform-specific low-level engine issues. So I've been patiently waiting for KSP 1.1 and figuring that would sort it all out. However, I recently (re?)read the KSP announcement regarding removing the 64-bit Windows build, and I was a bit worried about one passage that I evidently missed up until now: What I'm wondering at this point is, do we have any additional information on this? Was the above statement just a case of managing expectations, or do the devs really expect that some/most/all of the 64-bit Windows problems will remain? Has anyone been testing the Unity 5 KSP's 64-bit Windows build? Will the 1.1 release include a 64-bit Windows build, or is that still dependent on QA results? Will said build even be part of the QA process? I imagine a lot of people have their opinions and speculation on this, but I'd appreciate it if we could try to avoid guesswork here. Ideally, I'd love to hear directly from Squad — even if it's just a terse yes/no answer — or links to other Squad posts about the issue. Thanks.