blorgon

So turns out I actually am still experiencing this in 1.4.5. I'm running a modded install though so I'm gonna go through my mods first.

I may have launched the wrong version of KSP... I'll see myself out.

Huh, guess it doesn't default to HD... 8{

Been working intermittently on a complete rewrite of my kOS Apollo-style mun-and-back mission. Finally have the first half up to the precision landing down. Just gotta finish the second half of the mission.

Happens when loading a craft. Drives me batexcrements crazy.

Is TRR still around? I've switched to using DiRT, but it doesn't do navball texture switching.

I wanna take that navball behind the school and get it pregnant.

I've been going through my old Apollo-style Mun-and-back kOS script and completely overhauling it. I've spent the last two weeks on the precision landing phase of the mission because I was never totally happy with how it ended up, so I rewrote the landing from scratch and finally have it working as of tonight. Just as accurate, but a much smoother transition between braking phase and terminal descent. Unfortunately not as fuel efficient as my old script, which was a full throttle braking phase *and* a suicide burn terminal descent. This terminal descent is throttle-controlled, and I need to do some more tweaking to get it closer to the old efficiency. Super duper happy with this iteration. Lots more work to do though!

Yep. Having an actual reason to land on planets other than planting flags and pressing a "do science" button is not conducive to replayability.

The open doors have always bothered me too, especially because the outside is just a painting and doesn't even reflect the time of day... also the clouds I do think there's something to be said for how Kerbal it is to build rockets in what is essentially an oversized garage... But yeah, the ability to close the door would be nice.

I mean sure, aesthetically speaking nobody cares. But if it affects performance even a little bit, it should be removed because it adds literally nothing to the game.

PC specs: i7-8700 (non-K) 16 GB RAM GTX 1070 Game installed on PCIe SSD Set up: Running KSP (1.4.3) 64-bit in borderless windowed mode. Issues: Firstly, I want to mention that setting KSP to high priority in the task manager actually bombs the performance (~80 fps drop when sitting on the launchpad). So that's... weird. After returning KSP's priority back to normal, I've noticed some really bizarre behavior: if the game window is focused (i.e., I click anywhere on the screen in KSP) for a little while (less than a minute), performance will drop to around 15 fps. Once I click away to my second monitor on another application, or just win+D to the desktop, KSP goes back up to around 120 fps. If I click back to the game, performance immediately drops to around 80 fps, and then again, after a while drops all the way back down to 15 fps. Nothing is spamming the console. The craft I'm flying is 84 parts. Here's what the performance tab looks like when the game slows down: Mods installed: All of these mods are updated (or have forks) for 1.4.3. Any ideas?

This.... https://i.imgur.com/sXej5b4.gifv ...is ridiculous. I don't know how computationally expensive it is to continually pulse these lights but no matter what it costs, it's 100% unnecessary, looks stupid, and makes absolutely no sense. Please either make these lights static, allow us to turn them off, or remove them altogether and use a lower-impact lighting scheme in the VAB.

Lol, well too late. I need to learn how to use github anyway.

Ha! Fair enough. Would you like me to head over there and open an issue?

@jrbudda I requested this a while back but I think it might have gotten buried, so I figured it'd be okay to bring it up again. Can we get a line break separator in addition to the line separator that exists in miscellaneous currently? My intent is to get this effect with my HUD, but without having to use separate HUD elements and having to position them all perfectly in order to get this nice clean look: ...as opposed to this: Alternatively, depending on what would be easier, perhaps just adding an alpha slider for the separator so we can just turn them transparent?

That's a fair point to make for many mods, but things like scatterer, skybox and sunflare replacements, Stock Visual Terrain, and RemoteTech (of course, SQUAD already added their own comms, which blows in comparison to RT, but that's another discussion) don't need to evolve that often, if ever. I'm only talking about mods like that. I honestly don't see why not. I really don't think the two are mutually exclusive. I'm talking in general, of course. A game like that would need to built from the ground up with modding in mind. That's a fair point, but how many of those methods are changed in any given update to a different return type, or changed to require different arguments, or have their names themselves changed? And how many of those are actually things mods commonly require access to? This is all for the sake of discussion, by the way. I know SQUAD will never make a modder's paradise.

That's a fair point, but if you think about it, if they kept mod compatibility in mind while developing new updates, the community would get to play the new update sooner, because mods would most likely be ready to go at release or at least would take a lot less time to fix anything that breaks. Right now, the community has to wait for however long because the modders are unpaid volunteers that have their own lives. Some mods don't even get updated anymore. I'd much rather wait longer for a release with a guarantee that mods will be compatible than risk my favorite mods being broken for months, or even abandoned. We already wait a long time for KSP updates anyway. Just my opinion, of course. I'm also of the (probably unpopular) opinion that SQUAD (or Take Two, or whoever is in charge these days) should integrate the more ubiquitous/popular mods like scatterer and SVT, and convert all the tank/structural/utility/engine parts to procedural generation.

Fair enough. I hope I don't sound like "why doesn't SQUAD stop messing with modders?" I'm honestly just curious about the limitations with the game, and what makes a game conducive to modding. I honestly believe that mods keep this game alive, so it is frustrating having to wait for mods to get updated, and I can't imagine the frustration of the modders constantly having to recompile and edit their mods. I just wish there was a more symbiotic relationship between SQUAD and the community.

Right, that's kinda what I'm asking about. Why is it that the devs make changes like this in the first place? I'm just curious about the workflow and why the framework on which the mods are based is so volatile. You'd think by now we'd have a really stable system to work with. Is this par for the course for games with big modding communities?

It strikes me as rather odd that updates to the base game are so major that they break existing mods. What is it that they're changing so drastically that mods need to be updated as well?

Agreed. Also stoked to see some pixel art.

So wait, you need pivotName or secondaryTransformName? Or both? And suncatcher is the value it needs? Because this is what I put into the command pod's .cfg and it didn't work (also the extend and toggle context menu buttons didn't appear): MODULE { name = ModuleDeployableSolarPanel isTracking = false secondaryTransformName = suncatcher pivotName = suncatcher isBreakable = false resourceName = ElectricCharge chargeRate = 0 extendActionName = #autoLOC_6001805 //#autoLOC_6001805 = Extend <<1>> retractActionName = #autoLOC_6001806 //#autoLOC_6001806 = Retract <<1>> extendpanelsActionName = #autoLOC_6001807 //#autoLOC_6001807 = Toggle <<1>> }

I did try using the module from the stock fixed solar panel that doesn't extend, retract, or track, and even though the module showed up in the context menu, it wasn't registering any sun exposure.

I've bolded the part in one of the stock solar panels' .cfg that looks like it may pertain to the part's ability to gauge its light exposure level. Can I just add these to a command pod's .cfg and be able get its sun exposure? Or is that function hidden somewhere inside the module itself?