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.

Having trouble in my current game. In flight, this ship can't assign any actions to the numbered action groups, only to the "other" groups. The KSP.log is spamming this non-stop: [LOG 17:41:39.445] AGX Update error: 24f System.IndexOutOfRangeException: Array index is out of range. at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 17:41:39.481] AGX Update error: 24f System.IndexOutOfRangeException: Array index is out of range. at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 [LOG 17:41:39.509] AGX Update error: 24f System.IndexOutOfRangeException: Array index is out of range. at ActionGroupsExtended.AGXFlight.Update () [0x00000] in <filename unknown>:0 I had originally assigned some Karbonite drill & converter actions to action groups 1 and 2 in the VAB, but they didn't look right at the time (improperly labelled). I suspect that's the cause  they seemed to change their action lists between the VAB and in-flight. Savefile: https://dl.dropboxusercontent.com/u/32378574/agx-save.sfs … ship is "Exploitation", landed on Minmus.

FYI, got this bug in the latest EPL. I built a ship at a station, docked it to the station, undocked. Until I left the render radius of the station, everything was fine, but once I did, hitting F2 would no longer hide all the UI elements, and pressing it again wouldn't bring them back; I had to press F3 to get my UI back. [EXC 00:57:21.684] NullReferenceException UnityEngine.Transform.FindChild (System.String name) Part.FindModelComponents[Renderer] () Part.highlight (Color highlightColor) Part.SetHighlight (Boolean active, Boolean recursive) Part.SetHighlightDefault () ExLP.ExLaunchPad.Highlight (Boolean on) ExLP.ExBuildWindow.UpdateGUIState () ExLP.ExBuildWindow.onHideUI () EventVoid.Fire () ScreenShot.Update () [EXC 00:57:22.284] NullReferenceException UnityEngine.Transform.FindChild (System.String name) Part.FindModelComponents[Renderer] () Part.highlight (Color highlightColor) Part.SetHighlight (Boolean active, Boolean recursive) Part.SetHighlightDefault () ExLP.ExLaunchPad.Highlight (Boolean on) ExLP.ExBuildWindow.UpdateGUIState () ExLP.ExBuildWindow.onShowUI () EventVoid.Fire () FlightDriver.SetPause (Boolean pauseState) FlightResultsDialog.Display (System.String outcomeMsg) FlightResultsDialog.OnGUI () Exiting to the KSC and returning to the ship resolved it.

Are there any known mod incompatibilities between ShipManifest and other mods? I run a lot of mods (80+) and I find that Manifest sometimes work, but sometimes just produces weird results. Science and crew work fine, but resources tend to be weird. In the past, I've tried to transfer resources from a full tank to an empty tank, and ended up with it transferring -1 instead: the full tank becomes over-full and the empty tank becomes negative. In my current game, I just tried to transfer fuel from my station's large (14k) Multipurpose Resource Tank XL (Hangar mod) to a Rockomax X200-16 tank on a ship docked to the station. The "Xfer" interface goes away, like it normally does when a transfer is in progress, but there's no sound and it never transfers anything, and aside from the Settings and Roster buttons, the entire Manifest UI is now unusable until I exit and reload. Nothing in the KSP.log that I can see. Certainly nothing that appeared when the problem happened. I have seen successful resource transfers in the past, so this isn't a case of being totally broken at all times, but it's definitely broken for this situation.

FYI, I just tested with 1.8.4 installed manually, and EPL seemed to work okay. It's been a while since that one where I reported it broken, so maybe something else has changed, or maybe the CKAN version is borked somehow, or maybe I ended up with bad state data somehow. I'm going to nuke my manually-installed one, bring back the CKAN 1.8.4, and wait to see if the problem comes back. Edit: Uhhh, and lol, I just used the "EVA report" button while in a rover, and it cloned my Kerbal. He appeared back at the ship airlock, not the rover, and when I got back to the rover, his double is still sitting there in the seat.

Couple questions: 1. Is exercising in space the same as exercising back at the KSC on Kerbin? 2. Aside from the minimum g-force required for the "exercising" state, does exercising get more effective under heavier gravities? Basically, I've got an OKS station with the rotating hab rings, and they're considered "exercising", but I've managed to reduce several of them to zero fitness (oops) and I'm wondering if they would recover faster back on Kerbin. Edit: Answered my questions by looking at the source code. Best I can tell, #1 is "yes" and #2 is "no".

Ugh. Either CKAN is installing the wrong version of ScienceAlert (it says 1.8.4), or the ExtraPlanetaryLaunchpads bug is back. [LOG 21:39:23.920] <name of ship> loaded! [LOG 21:39:23.921] []: Ready to Launch - waiting to start physics... [EXC 21:39:23.922] NullReferenceException: Object reference not set to an instance of an object ScienceAlert.ScienceAlertProfileManager.OnVesselCreate (.Vessel newVessel) EventData`1[Vessel].Fire (.Vessel data) Vessel.Initialize (Boolean fromShipAssembly) ExLP.ExBuildControl.getBuildCost (.ConfigNode craft) ExLP.ExBuildControl.LoadCraft (System.String filename, System.String flagname) ExLP.ExBuildWindow.craftSelectComplete (System.String filename, System.String flagname) CraftBrowser.drawList (Int32 id) UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style) This is using the Orbital Shipyard provided by MKS, which uses the ExtraPlanetaryLaunchpads code to spawn ships. I'm going to try again with ScienceAlert uninstalled (via CKAN), and then try manually downloading and installing 1.8.4 and see if it still happens. Edit: Works fine with it uninstalled, which at least rules out the possibility that I had an old version installed in a non-CKAN-managed way.

Okay, yes, I have MKS, so that explains it, thanks. So if I'm using MKS, I'm just supposed to use the EPL→Regolith parts (the rocket workshop etc.)? Or does MKS come with rocket-building parts now?

Okay, weird problem. Before I start trying to track it down, just wondering if anyone might have any insight. I've got EPL 5.0.0 installed via CKAN, but all the parts (that I've checked) seem to be missing. No orbital dock, no launchpad. They're not in my Sandbox game, and they're not in the tech tree where they should be in my Science game. I *do* have the EPL build resources box. And I do have all the files that I should have, and I can watch it load the orbital dock, the launchpad, etc. in the KSP.log. I don't see any EPL-related exceptions. I installed the EPL→Regolith conversion (also via CKAN) and I can see all those parts, so I have the Orbital Rocket Workshop etc. I realise there's plenty more diagnosis to be done here, but I'm just wondering if anyone has seen anything similar to this and has any idea what went wrong here. I've got a ridiculous number of mods installed (80+) so I'm obviously a bit hesitant to start ripping stuff out to figure out where the incompatibility might be.

Ah, awesome, thanks. Funny that I've had antennae in science bays before and they didn't seem to get FAR-disassembled, but maybe I just wasn't going as fast or something, I dunno.

Yeah, there wasn't much flexing that I could see; I'm using Kerbal Joint Reinforcement and that seems to keep it pretty stable. At least part of my problem was that I misunderstood the new FAR control surface sliders. My pitch-only surfaces for example were +100% pitch and -100% yaw and roll, when they should've been 0% yaw and roll. Enabling DCA assist helped, as did reducing the max deflection down from 15º to ~5º. Part of the problem I was having was that, at this stage in the game, I've got crap for SAS  just the command pod (5 strength) and the 0.625m SAS module (also 5 strength). I realise that SAS doesn't do a lot for FAR once you reach speed, but my problem was that I couldn't tip over to the desired ascent angle before I reached an airspeed that would lock me to my current course. I think the "can't tip over early" problem was a mix of not having enough control at low speed (SAS+vectoring) and also really having too high a TWR. I started out with a crazy 3.61 TWR which meant that I reached the aerodynamically stable speed way too fast before I could tip over at all. If anyone's interested, all this is documented in yesterday's post in my modded Kerbal playthrough blog series: http://wisq.net/2015/01/04/kadet-3/ I don't know what made the final design so incredibly stable yet controllable, but my guess is that a) the much longer length (and more gradual fattening with length) contributed to stability; the centre of mass was moved even lower, such that those control fins at the top had even more direction authority at the start; and, c) the TWR was much more controlled, due to the extra weight and due to delaying the liquid main engine burn.