Jacke

You can switch to KSC with the engines on at low power ?!? As in non-zero throttle ?!? Thought that wasn't possible? Part of the bug?

Obviously @Renegrade, you haven't made sufficient sacrifices to the BIg C if you have to 'ware the Kraken. Iä! Iä! Cthulhu fhtagn! Ph'nglui mglw'nfah Cthulhu R'lyeh wgah'nagl fhtagn! Less cultishly, does it act as if the ship is under thrust, not allowing you to switch away from it?

That's to be expected, based on the KAS.version file containing "1.1.0". You have to expect this for point updates of any mod. You could help by testing and seeing if KAS is behaving the same on 1.1.1 as you found it to do so on 1.1.0.

It's frustrating, but it indicates how premature releasing 1.1.0 was, to have even fixes to it break mods that were working with it. On the other hand, without that premature release, I don't think we'd have the features of @sarbian's Make It Small in stock by now. As for RPM, @MOARdV said he'd be on it when he has dealt with real life issues. I think he'll have it fixed right quick.

Well, if it's not showing a status of closed or otherwise indicating a fix has been pushed to the live version of KSP, I'd say its fix isn't included. Although that bug could be affected positively by some of the other changes. But with that high of a level of activity on a bug, I'd say Squad is close to getting a good fix tested and deployed. I'd expect it to come with either a hotfix or 1.1.2.

Better start getting a head of Steam up on da Hypetrain then....

You may want to go through and clean up your entire GameData folder, then, especially any mods that change stock parts. If there's a Module Manager script from somewhere fiddling with the part to cause that, it could be anywhere in GameData.

Wow, that's a lot of fixes. Kudos for getting them all out, Squad! (And hopefully not introducing any more.... ) ...so even in stock KSP, you can dress left or right.

Well, since I was planning to restart my career.... I have a copy of 1.1.0 stored and could play it. What say you, Harry? Damn, dude, it's a siege. Get off that horse and get a helmet on. You're just asking for a crossbowman to pick you off. Off to update my Steam KSP and copy it.

I think it may be better to leave the roll scale as is, to cut down on the information from the display you have to process. If you've rolled outside of the limits of its display, the pointer will be at one or the other of the extremes, telling you which way to roll to align. You never really roll at a fast rate, just start rolling and wait until the pointer starts shifting and then you slow it.

It would be very hard to use BTSM and Kerbalism together. Both change a lot of stock KSP and neither is designed with the other in mind. Conflicts are almost certain. The game would likely be unplayable. More details in the spoiler.

The logs are also generated as files which you can access after the game exits or crashes. From here: http://forum.kerbalspaceprogram.com/index.php?/topic/83213-please-read-before-posting-stock-support-bug-reporting-guide/

Problem is control technology in our world was equivalent to having custom actions groups even for original sounding rockets of the late 1940's to 1950's and and back into the earliest research and World War 2 weapon use. They controlled multiple things simultaneously, if that what was needed to control a particular rocket for a particular flight. Right-click menus and custom action groups are just two different methods of abstracting the complex control systems of real rockets. Stock custom action groups are in many ways a better abstraction, because you can only change them in the VAB/SPH, making them something you design when you build the rocket. You even still primarily act this way even with the mod Action Groups Extended, despite it allowing you to edit action groups in flight, because getting the control right may require changing the design of the rocket. You have to think about how you're going to fly the rocket and think ahead. And that's a good thing you have to do in so many ways in KSP. Even with 30-part rockets, you can still easily bury parts, and even if you haven't, some of them are tiny, making their right-click menus hard to find and operate. And with many rockets, especially spaceplanes, you have to access many changes in those right-click menus near simultaneously, often at crucial points of their flight, when you need your hands on the controls and your eyes on the crucial flight data numbers. Not fiddling with the mouse and peering at right-click menus. @FlowerChild, the author of the career total conversion mod Better Than Starting Manned, and a hardcore and good manual rocket designer (doesn't use delta-V) and manual pilot, thinks restricting the use of Custom Action Groups in career is just wrong. Here's his comment about it from the change notes on a past BTSM version, where he discusses another point in stock career, that you have to independently upgrade the launch pad and runway, as well the VAB and SPH, despite them being similar and in some way interchangeable. (Text bolding not in the original; done by me to focus on the action group comment.) http://forum.kerbalspaceprogram.com/index.php?/topic/56101-104better-than-starting-manned-career-mode-redefined-v1002-sep-21st/&do=findComment&comment=1953359 The concern about VAB/SPH and launchpad/runway is more debatable that custom action groups, in that these are different facilities and should have independent costs, despite their interchangeable use. Still, FC points to the gameplay concern and he's right about it too. Although in the real world control systems have to advance and each facility has to be built and improved independently, any game, even the most detailed simulation, is still a game and is here to be enjoyed. Having custom action groups doesn't prevent sole use of right-click menus. Having no custom action groups in early career just means you are forced to struggle with right-click menus in all the settings I've mentioned until you can scrap together 1,070,000 funds just for the VAB. And again for the SPH. Hard career games get 60% of standard game benefits. I know of a player who's decided to try stock career at the 20% level. Over a million funds can take a very long time to get.

The NASA audio clips, like all NASA media, aren't licenced. You'll have to read this page for their media usage guide. https://www.nasa.gov/multimedia/guidelines/index.html I think including them with or for Chatterer, if done respectfully, shouldn't be a problem.

BTSM is a total conversion mod designed to give a challenging career. Its author @FlowerChild want to provide a gameplay experience that he feels is right and interesting to him. He works a lot to achieve good balance and progression, often removing stock items because they can be a problem for his goals until he can find ways to work them in. Gameplay is its goal, realism not so much. FC also completely reworks the tech tree (including renaming and dropping nodes) and contracts to guide the gameplay over the length of a game. Because FC is going for a gameplay experience, he can keep many things simple so that it's easier for him to design and us to play, because a simple idea is sufficient to affect gameplay. For example, BTSM just has a simple singular Life Support resource, but its mass is significant and when a game advances to manned interplanetary missions, life support is a crucial planning issue for every mission. In that context, virtually any part mod and most other mods will sabotage BTSM's challenges (when they don't break because of how BTSM is different from stock), parts to a great extent, other mods to a varying lesser degree. Total conversion mods in any game are usually like this. Kerbalism is a bunch of features added to stock that are modeled on things in real world space travel, but in a Kerbal context. There's a lot in there. What it appeals to is something a lot of mods for sandbox and stock career do, giving something new and cool to game with. There's enough similarity between them (changing a lot of things in the stock game) that I can make some predictions about Kerbalism. What can be a problem with so many extras and changes thrown in is that they can interact in strange ways, not to mention break because of having so many interacting with the rest of the game. With the fine tuning on these extras, it's likely that Kerbalism in career or sandbox can quickly switch between being too easy to being impossible. I know many of the difficulties that FC has putting out many BTSM releases as KSP changed and he developed his mod. Kerbalism is likely to have similar ones.

With those shades, he really needs a black suit, white shirt, and black tie.

I do that a lot meself. Most of the times I catch it before I post (the comment above about checking, checking again, and again...). Not always though.

Kerbin is downscaled from Earth a little more than 10 times, but still has the same surface gravity. So the mass has to be downscaled a little more than 100. https://en.wikipedia.org/wiki/Earth MEarth = 5.97237×1024 kg http://wiki.kerbalspaceprogram.com/wiki/Kerbin MKerbin = 5.2915793×1022 kg MEarth / MKerbin = 5.97237×1024 kg / 5.2915793×1022 kg = 112.8657 QED.

Because then KSP would still be on Unity 4 (4.2.4 I think to be exact) and Squad would still have to deal with issues in Unity 4 that had been resolved in Unity 5. Like no reliable 64-bit executables for Windows. And other Unity 4 issues, resolved in Unity 5, that would keep consuming Squad's efforts and resources and good will with their customers. Us. As @Curveball Anders put it in his comment on the latest Devnote Tuesday. Squad knew they'd have to sink a lot of effort into the transition from Unity 4 to Unity 5. They put it off for KSP 1.0. They couldn't put it off much longer. As Unity 5 kept releasing versions, it's likely the work to do that transition would only just grow in scale and complexity. It's not the transition from Unity 4 to Unity 5 that most of us don't like about KSP 1.1. It's that major critical bugs were still present in KSP 1.1, some from its Unity 5 version, that KSP didn't fix or workaround. Besides fixing those bugs that can be fixed and improving the workarounds (which KSP 1.1.1 should do), Squad should be looking at its process for KSP 1.1 to see what they can do better. It's the first time they've had an extensive prerelease test with community members. They'll likely aim to improve that and other steps to prevent the shear number of critical bugs in a release that happened with KSP 1.1. (Many of those bugs are not consistent and constant in their behaviour, the hardest bugs to deal with.)

What matters is what you're trying to do in this Brave New Scaled-up Universe. I take as a design point that in the scaled up system, Kerbin's surface gravity is wanted to be kept the same as it is on stock Kerbin as it is on Earth: acceleration due to gravity is 9.81m/s2. To have that if you increase the distances by 6.4, you have to increase the masses by 6.42. g = μ / r2 Different design goals for the scaled up system lead to different changes beyond increasing the distances 6.4 times.

EVE is currently separated from its config files, if you take a look on the EVE topic and on its Github page, there's EVE itself, the .dll's and the .shader's (under EnvironmentalVisualEnhancements) in one .zip and its stock config (under BoulderCo) in another .zip. @rbray89 did that just for alternate configs like SVE.

There is a mod that already handled background processing of Electric Charge including solar panels, as well as allowing mod writers to use it for their own background processing needs. Although the title says KSP 1.0.2, I know @FlowerChild was using it to handle background processing in the latest Better Than Starting Manned for KSP 1.0.4 for charge and BTSM life support. Apparently @jamespicone hasn't been on the forums since February, but there's a couple of other modders discussing forking and carrying on the mod in the latest entries in the topic.

It's definitely changed, but it appears you can still split up parts from symmetry groups between stages. In 1.1, when you click on a symmetry group in the staging display, it opens up to a list of all the parts, each one outlined in green. When you hover the mouse pointer over a part in the staging list, whether outlined in green or nothing, the staging list part becomes outlined in white and the respective part(s) on the spacecraft becomes outlined in green. What you do now is click on the ones you *don't* want to move out of the current stage, which toggles off their green outline in the staging list, until just the ones you want to move are outlined in green, Then you click-and-hold on one of the green outlined parts and drag them to a different stage. If you want to get more fancy with symmetry groups, the mod Part Wizard can break and remake symmetry groups.

Was skimming this thread and noticed this 3 posts and the ones around them. And did a little checking. Then I checked my checking. Then I checked it again. Checked references. Long ramble about what Mun's period would be and what you can pick for Kerbin's rotational period. Anyhoo, if Mun's SMA is scaled up by 6.4 and Kerbin's μ by 6.42, then Mun's period of revolution should be scaled up by 6.43/4, or 4.023787. From the KSP wiki, It's currently 138 984 s, or in Earth time 38 h 36m 24s. Scaled up, it would be 559,242s, or Earth time 6 d 11 h 20 m 42s. So, that's going to be a lot longer than any selected Kerbin rotation period. I'd say go for same as Earth, solar day is 24 hours, or 86,400 s.

Good to hear. I hope this is truly a few steps forward without one or more back. I sort of agree with @XrayLima, but in retrospect I think it would have been better if, in the parlance of a much graver historical misdecision, they'd put their "engineer hats" on and mulled it over, even went for a Flight Controller's "GO or NOGO" to their staff, as well as the most senior of the Prerelease testers. I think that engineering decision would have had them go 1 or 2 more Prerelease versions farther, perhaps a week or two, and done what I think they need to do for 1.1.1 (see below). Because engineers know management and business too, and nothing rots management and business like failure. I agree, as the underlying issue is from Unity 5.2.4, only with a Unity upgrade (a grave decision that has to be vetted thoroughly) will the final fix on wheels and legs be possible. Hopefully with the feedback from 1.1, Squad can improve the quality of their workarounds so those beasties behave. That (and some other fixes) are my hopes for KSP 1.1.1.