Wercho

I just tested with 1.6.2. When focused, I'm now only seeing boiloff when I timewarp fast enough to drain the batteries in the simulation, which is to be expected. When not focused, I now get boiloff regardless of cooling. I built a basic craft with a probe core, NFE reactor and radiators (for plenty of power), two Z-4k batteries, and a couple of cryotanks (H125-4) filled with LH2. I set one to cooling enabled, and one to disabled to compare. I went to the tracking station, and after a few days both had lost some LH2. The one with cooling disabled had lost more, but they both experienced boiloff. I now realize it is possible this issue is due to Kerbalism, though I disabled the Kerbalism patch of NFE reactors and Kerbalism shouldn't affect Cryotank boiloff. In fact, Kerbalism mods its own tanks to have your boiloff module if Cryotanks is installed. If it isn't Kerbalism, there's a chance its one of the other mods I have installed. If I get time, I'll try to test a clean install but right now I'd rather just play in my limited time. Thanks for looking into this! I appreciate it.

@RoverDudeFYI, the constellation 112.0.0 changes the file structure of this mod, but a few of the cfgs need to have the model filepaths updated. Specifically, the "/Parts" folder is added to the structure, and the two MassDriver and three Separator parts need the filepath updated. The current repositories that I could find didn't seem to have that change, so I wasn't sure where to file a bug report on github. Thanks for a fun mod!

FYI, panarchist's config has "hl10Type1Extension" in it twice. Delete one of them to avoid an error if you use it. Also, thanks for the config!

Has anyone tested the boiloff functionality of this recently? I'm wondering if others are getting what I'm seeing, or if I've got something wrong. Here's what I've seen happening: While focused on a craft, boiloff works correctly except for at the highest stock timewarp speed, where there is boiloff even with cooling on and plenty of EC. However, if I go to the tracking station no boiloff happens regardless of cooling setting, EC level, etc. I've let it run for 100 days before going back to the craft and it has the same level it had when I left. Do other people get boiloff while not focused on the vessel? This is with Cryotanks 1.6.1, and DBS 2.2.5.0. Thanks!

Has anyone tried to change the appearance of scrollbars? I can't get the "thumb" to change appearance, despite getting everything else to change. Buttons, labels, textfields, boxes, even the scrollbar background all work, but not the thumbs. I've tried setting all the different states :bg suffixes (eg. normal, normal_on, ... , focused_on) to no avail.

I just checked this out, and it really looks fantastic. Thanks so much for this!

From reading the Kerbalism wiki, it looks like NF is supported but the NF reactor stuff is basically stripped out, and replaced with Kerbalism modules, which means you don't get the heat production mechanics in NF. (The kerbalism patch says it makes the NF reactors OP as a result, but I can't say for sure). The other NF stuff seems to be well supported. This is getting off topic for this thread, though.

While I haven't yet played with kerbalism, I'm pretty sure you could do this by modifying the config to only start the science stuff, and not track EC. However, I'm pretty sure tracking EC will be needed to get any science experiment to work while not focused on the vessel, and a lot of the kerbalism science experiments take over 100 days to complete, so you probably won't want to just sit there watching it that whole time.

I was able to resolve that with this config: PQSCity_Groups { GROUP { name = KSCUpgrades body = Kerbin CENTER { CentralPQSCity = KSC } } GROUP { name = KSCUpgrades2 body = Kerbin MODS { PQSCity = KSCUpgrades_ksideradar3_0 } } I haven't had a chance to test the latest version of KKtoSD, to check on the spawn point changes yet.

Yep, worked like a charm Thanks!

Dang, I wish I'd known about that before I worked on the config I suggest adding a link to that in the OP under the PQS section. Everything seems to be working fine now. Second, is there a way to exclude a static from KKtoSD? There are a few that shouldn't be relocated (like the radar tower from KSCUpgrades) because they match specific geographical features.

First, this is a great mod and a big help for resizing things. Great work. Second, I've been having a go at creating PQSCity groups for KerbinSide. My config is attached below. I used the method of looking for the PQSCity names in Kittopia, and creating the config file from that. The good: The stuff around KSC (KSCUpgrades in KerbinSide) works great, and everything shows up where it should be, except the KSC VAB Helipad. The bad: all the other KerbinSide sites aren't being moved together as groups. (I've been trying on 3.2x rescale with buildings at 1x.) Also, on some of them the a spawned craft starts under the terrain, while on others it is on the pad like normal. Anyway, it seems like this feature is partially working, but not many people seem to be interested in it so it's probably a low priority. For others who are interested, for lauchsites and runways (and any other spawn point) Kerbal Konstructs seems to create a PQSCity name that matches the name of the Launchsite in the KK config file. For other things, it creates a PQSCity name of of [groupname]_[staticname]_[index] (without the brackets). Index starts from 0 and counts up for duplicate statics in a group. So, an example would be TheShelf_ksidelighthouse_0. Config File

I just wanted to confirm I'm also getting this same bug. I notice that the normal recovery screen (where it lists the parts and values), says recovered "at Untagged" where it normally says [distance from KSC]. I tried at two different KK launchsites and got that same text, with a % recovery that seemed to be based on distance to KSC. I've got KK 1.1.0 and KS 1.4 installed from CKAN.

FYI, Sigma Dimensions is mildly incompatible with Stock Visual Terrain. I'm going to drop a note on Sigma's thread too. Basically, because SVT's module manager configs act after SigDim's, the PQS sections get two "Mods" and two "Material" blocks, which seems to result in completely flat textures. i.e. the ground around KSC is visible, but it is a textureless green. I seem to have fixed the issue (have only tested around KSC) by removing the ":FOR[SVT] block from SVT's configs, which makes them happen first in the :LEGACY section of module manager's work. Then SigDim operates on them and everything seems fine. This problem stems from the fact that MM works in alphabetical order. I'll leave it to Sigma and Galileo to work out a permanent solution to this.

FYI, Sigma Dimensions is mildly incompatible with Stock Visual Terrain. I'm going to drop a note on that thread too. Basically, because SVT's module manager configs act after SigDim's, the PQS sections get two "Mods" and two "Material" blocks, which seems to result in completely flat textures. i.e. the ground around KSC is visible, but it is a textureless green. I seem to have fixed the issue (have only tested around KSC) by removing the ":FOR[SVT] block from SVT's configs, which makes them happen first in the :LEGACY section of module manager's work. Then SigDim operates on them and everything seems fine. This problem stems from the fact that MM works in alphabetical order. I'll leave it to Sigma and Galileo to work out a permanent solution to this.

In case anyone is having trouble making MM patches for version 1.2.1.1, the tags have to be capitalized unlike the example in the OP and the other examples that have been posted (which are for 1.2.0.1). I don't know if this has changed recently. Try it like below. I'm not sure about some of the other options (like "chanceWhenUnstable") but try with the first letter capitalized and not and see what works. Also, I haven't tried the ullage simulation in 1.2.1.1, so I assume that doesn't work as others have posted. MODULE { name = ModuleEngineIgnitor IgnitionsAvailable = 1 AutoIgnitionTemperature = 800 IgnitorType = Lower UseUllageSimulation = false }

This line could probably be worded better ;). Seriously though, you run so many wonderful mods.

No problem, I just wanted to know which version was the latest. I'll stick with the dev version for now.

The new dll seems to have fixed the problem. The fact that the problem dealt with launchpad reconditioning explains why I later discovered it didn't apply to the planes I was making. Thanks for the quick fix. Is that fix in 1.3.2?

New information: It's not Take Command, it just seems to happen anytime the vessel moves for the first time with a Kerbal in the command seat. Specifically, to further test this I created a vehicle with 2 EAS-1 command seats and a normal cockpit. Put only Jeb in the cockpit on launch. The vessel is fine if I first drive it somewhere, then move Jeb out to one of the seats. Then it works normally. However, if I move Jeb to a command seat first (not with a mod, just by EVA), and then start driving the vehicle goes bonkers as described in my first post. This is a pretty strange bug, I think.

Nope, that didn't fix it. If it helps, the 25 reputation shows up in the vessel recovery summary, under the crew page. It doesn't create the popup text that the other strategia bonuses do.

First, I LOOOOOVE this mod. Second, I seem to have found an incompatibility with KCT. Specifically, I find that when I Take Command spawns Kerbals in a seat, that craft has a problem. When it goes over about 2.5 m/s (across the ground, like a rover; up like a rocket, doesn't matter) the game resets it to the ground, rotated 90 degrees (so lying flat if a rocket) and then KCT spawns a ton of exceptions. Sometimes the game recovers (from the exceptions, and sometimes not). This only happens after KCT builds something over time. It does not happen if using KCT's simulation feature. It does not happen with normal command pods, unmanned craft. It does not happen if I spawn a kerbal in a normal pod then move him over to the seat. This is happening on an install with only KCT, Take Command, and GCMonitor. Logs: KSP.log, player.log Has anyone else encountered this? I've crossposted this on the Take Command thread also. Playing on Linux x64

First, this is a really valuable mod. Second, I seem to have found an incompatibility with KCT. Specifically, I find that when I Take Command spawns Kerbals in a seat, that craft has a problem. When it goes over about 2.5 m/s (across the ground, like a rover; up like a rocket, doesn't matter) the game resets it to the ground, rotated 90 degrees (so lying flat if a rocket) and then KCT spawns a ton of exceptions. Sometimes the game recovers (from the exceptions, and sometimes not). This only happens after KCT builds something over time. It does not happen if using KCT's simulation feature. It does not happen with normal command pods, unmanned craft. It does not happen if I spawn a kerbal in a normal pod then move him over to the seat. This is happening on an install with only KCT, Take Command, and GCMonitor. Logs: KSP.log, player.log Has anyone else encountered this? I'm gonna crosspost on the KCT thread also. Playing on Linux x64 EDIT: Turns out Take Command isn't the problem, Take Command just makes it easy to get command seat only vehicles that don't move at all before a Kerbal is in the command seat, which seems to trigger the problem. Carry on

I'm getting 25 reputation for each kerbal recovered, with no strategies active. I first noticed this on Strategia 1.0, but it is still happening with 1.1.0. Here's a log with just Strategia, its dependencies, and GCmonitor installed. KSP.log, player.log I can't find anything relevant, but this section seems odd: [WRN 08:20:28.117] [HighLogic]: =========================== Scene Change : From FLIGHT to SPACECENTER (Async) ===================== [LOG 08:20:28.658] Added -461.4915 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added -320.1254 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added -166.1564 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added -68.18783 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.658] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. [LOG 08:20:28.659] Added 0.1293579 (-500) reputation: 'Strategies'. Playing on Linux x64. Thanks for another great mod!

So, I've been doing some vague benchmarking to see how I can get the best performance from KSP. To that end, I have been using Kerbokatz' FPS Viewer and Physical Time ratio viewer to see how the game is running under different platforms. I've got KSP installed on Windows Vista and Linux (Ubuntu 15.04). I flew the Dynawing stock craft, and watched the reported Physical Time ration, and here are the results: Physical time ratio, using a physics time step of 0.02. (Higher is better). Windows Vista, DX9: ~58% Windows Vista, DX11: ~50% Linux x64, OpenGL: ~50% Windows Vista, OpenGL: ~35% So, with my hardware, DX9 gets the best performance (though at the cost of higher memory usage as others have discussed). DX11 and Linux OpenGL, and Windows OpenGL is significantly worse. Another thing I noticed: Under DX11 and OpenGL, the performance drops to about 25% at the default zoom, but if I zoom out just a bit (so the craft fills about 1/2 the screen vertically) the performance increases to the above values. This doesn't happen on DX9. It performed the same regardless. Lastly, Physical Time Ratio Viewer has an option to display the physics time-step. I noticed that if I increase the physical time-warp, the physics time step goes up proportionally, but then doesn't come back down when reducing the physics time warp. The effect on performance is noticeable, so I don't think it is just the mod not recording it correctly. It seems like the mod is getting it right, and the game isn't resetting the physics time-step when warping down. Computer specs, for the curious: Intel Core 2 Quad Q9550 overclocked to 3.78GHz; Nvidia GTX 960, playing at 1080p with a few graphics mods (EVE, scatterer, Real Plume). Anyway, these are just some observations I made. Maybe they'll help someone else figure out how they want to run their setup.