paulprogart

Already acknowledged as a stock bug, and there is a workaround part .cfg file change: http://bugs.kerbalspaceprogram.com/issues/13403

@eberkain If you're OK with writing simple scripts you could try AutoHotkey. It's ideal for the situation you describe, i.e. using controller buttons to click things on screen.

I had one of these... when I discovered it was a bug I hand-edited my save file to turn it into another part... I think a fuel tank. (No I did not take the fuel from it.) If you are comfortable doing that kind of thing, it's a fairly easy fix.

This is getting pedantic, but it's actually not officially called the Cheat Menu, it's called the Debug Toolbar. (Citation: the API docs, and also if you watch closely "Debug Toolbar" is what it says when it first opens, before the tab title quickly overwrites it.) The Cheat Menu is an informal name. Now there is a Cheats Tab in the Debug Toolbar, so is that name justified? Well let's see... Set Orbit and Object Thrower are easy, because they're clearly cheating physics. The Difficulty tab is really just a bunch of aliases for Difficulty Settings so I'm not sure why that's under Cheats.... historical reasons maybe. The main tab is interesting as it has a bunch of different options... some are clearly other physics cheats. Some are odd options that actually seem more like debugging options, so perhaps those don't belong there. But the rest I would classify as economics cheats. The game does have a fixed set of economic rules, and while you can argue about how much sense those rules make, these options clearly subvert those rules. So they're cheats. However, you'll be happy to know that the portion of the Debug Toolbar dealing with Contracts does not fall under the Cheat tab. So, you can mark contracts complete at will and rest assured that, according to the game, you are not "cheating", you are merely "debugging".

I'm no rover expert but I have done a lot of driving on Minmus. My rover (more like a big trash can on wheels actually) had a big reaction wheel bound to a toggle group... so going over a cliff, I'd activate the wheel and SAS so I could line it up with terrain, almost like a plane. After landing, I'd wait for it to stabilize, then turn that off. In Minmus' gravity there's tonnes of time to react. I've saved some pretty spectacular flips. Got good enough where I could fly over edges at 10 m/s or more and routinely stick the running landing, though I only tended to do that when I was goofing around and didn't mind F9'ing. Rarely had to though. (But on the Mun, much different story...) Even did a route not unlike the one shown, though I wasn't trying to collect science all the way down... just at the flats. Collecting on the way would make it trickier. Pulse the brakes and apply reverse motors at the same time for faster stopping. Though that still only works up to a point... e.g. going 20 m/s down the slope shown it's not going to do much. In the flats it'll work fine though. Not arguing with this, I'm just saying that one can actually do quite a lot with a land vehicle on Minmus.

They'll produce double, but only if you provide double the science. So you have to run every experiment twice. Thankfully, when reviewing stored data the game is smart enough to send experiments to a lab that a) hasn't run it yet and b) isn't full. Of course if you're bringing them to the labs from elsewhere it also means storing everything twice en route, which means two separate science containers (or RGUs). If you can do that, though, it definitely works. I did it in my career game around both Kerbin and the Mun to really help extend my tech. It probably shouldn't work the way it does as it makes it too cheaty, but since it does, may as well use it.

@DStaal is correct that ARR is the default pretty much anywhere in the world. If you really want to get into the legalese read https://en.wikipedia.org/wiki/Berne_Convention but if not here's a relevant quote from the summary:

Or maybe just use TweakScale: As to OP's suggestion of doing this in stock, I'm no expert, but hard experience in the game taught me the corollary of the real-life statement above: If you're trying to do things with massive amounts of ion power, you're not using ion engines "correctly". There are other, better alternatives. (Though they may require unlocking other areas of the tech tree in career mode).

But It's KSP! Heck I pulled two all-nighters on KSP when I was full into my first game. Hadn't done once of those since my early 20s (in my 40s now).

Persistent Trails caught my eye as an upgrade candidate, but it turns out it's already 1.2.0 compatible officially, and I tried the installer with 1.2.2 and it seemed to work fine. The thread OP and Title aren't updated for it and the original author is AWOL, but on the last page @JPLRepo posted updated releases for 1.1 then 1.2, so I'd say that qualifies as official.

Ehhh just make something like this mandatory for KSP: Problem solved.

The fomula is proprietary, but Wired went and did a spectrographic analysis some years ago: https://web.archive.org/web/20140119014037/http://www.wired.com/science/discoveries/magazine/17-05/st_whatsinside Heavier stuff than I thought it'd be.

New version v1.10 released! LSM now features an in-game configuration UI courtesy of @linuxgurugamer! So no more messing about with a .cfg file, unless you really want to. Also note that I have tested LSM with the KSP 1.2.9 prerelease and it DOES NOT WORK. I will update for KSP 1.3 once that is released.

Definitely modded. There are no "docking" vs. "construction" ports, port "hatches", or "passable nodes" in stock game. P.S. Amusing TLA conflict on CoT, I never noticed that before.

Diggin' the new format! I know it's still WIP but... Based on my casual observations, yes. Can't speak to the other types though.

It is possible to use normal Unity animations with the Unity 5 UI.Button class. I don't know how that plays with the toolbar specifically, but since 1.2.x is using UI 5 throughout it can definitely be done in some way. If you've not got into UI 5 in KSP yet, the UI Canvases are in KSP.UI.UIMasterControlller... And yeah I get the potential UI nightmares, but any feature can be misused, and I would rather this developed with clear visibility by responsible people than pushed into the shadows. (I could go on into certain relevant political topics but that's not allowed on this forum. )

Personally I don't like the idea of installing an extra dependency mod just for logging. I just add a debugLogging configuration setting and do extra logging when it's enabled... even in Update()/FixedUpdate() these checks aren't going to take enough extra time to matter. (But you shouldn't log repeatedly in there anyhow... aggregate it and log once at the end instead.) I also send everything through my own methods which tack on the mod prefix in square brackets. Not only does this make the messages easier to find, but in the Alt+F12 display KSP will do colouring based on that.

You know the answer, OP. You are just asking for our validation to do what you already want to do, because you are not fully comfortable with that desire. We can give validation to you, or not, but either way you will find that in the end it does not actually help resolve your internal conflict.

^^^ as am I. As someone who may at some point grab something off this list to try reviving on as a break from other projects (because of course the only break from development for us Real Developers is more development!) I'd wanted to voice my support on the original thread but it was a busy weekend for me, and you moved too quick! However I don't understand why you not only included mods with known active authors, but put them at the top?!? That almost seems like shaming. I know that certainly wasn't the intent, but it just doesn't sit right with me TBH. I thought the main purpose was to highlight known or suspected inactive mods for developers, so I'm not sure why including mods that are just not updated yet is needed? For ordinary mod users I would think the CML (also excellent job BTW!) would already be sufficient for seeing what's available for current KSP and what's not. At the very least I'd like to suggest reversing the section order. Also rather than going by mod author status, perhaps likelihood would be better... e.g. "known abandoned", "probably abandoned", "possibly abandoned". Some of that may be subjective but since there are always uncertainties with this type of thing it's hard not to be.

If you click the "View History" on the top-right of any wiki page you can see when the last edit was. For that page it's June 20th, 2015. So I would say, in general, very probably not.

When there's a major announcement like today's, do the mods and staff all work together ahead of time to develop a game plan with specific responsibilities? Asking because I'm exhausted just browsing today... can't imagine having to read and moderate it all. (I've moderated communities before but none near this big.)

If you have Steam you can (at least on Windows) get there if you right click on the KSP Library entry, pick Properties, go to the Local Files tab, and click Browse Local Files. The aforementioned "saves" folder will be in there. Though after that I suggest making a shortcut because if you play with any regularity you will be going there often!

Actually, it's a maximum time (Unity doc reference), so lower will in theory mean less physics calculations and thus a higher visual FPS (but also more GPU usage). Raising it will lower the FPS but make the physics calculations better (more CPU/less GPU). But the rest of your post is spot on. That setting is for fine-tuning on systems running normally. (e.g. I run it raised to 0.12 because it helps keep my big stations stable.) On a system is running slow, lowering this setting is indeed going to make the problem worse, because a) it will push the (possibly already overloaded) GPU more and b) KSP won't likely have enough time to simulate vessel physics properly. In the absense of more info, all I can suggest is to go to the Graphics tab of Settings and slide the Terrain Detail, Render Quality, and Texture Quality sliders all to the left, and turn off Terrain Scatters and all the FX buttons if any of them are green. But that's blind advice... as has already been said, way more info is needed to properly diagnose the problem.

Looks like it does, but only if you don't log in for over a week, as that's the expiry date I see on my browser cookies. Presumably they get extended each time you login, as I've never had to relogin either. I only use one device/browser though.

This. If you are interested in learning all the basics (rocketry/aero/orbital stuff), play until you get to the point where something gets tedious or frustrating and you don't want to (or don't have time to) figure out a way to do it with stock. Then and only then find mods for it... whether it's informational tools, assistance, extra parts, whatever. At least then you will not only know that you want/need them but also why. It's the best way to learn and provides the most long-term benefit. I played 700 hours unmodded stock career because I had time (unemployed) and wanted the challenge of figuring it all out. But for my next KSP game (once I have time) I will mod quite a bit because now I know what I like doing, and what I don't like. If however you want to do something specific (spaceplanes, mining, realism, etc.) then you will probably need mods for that from the start. Not my area though.