PumaX

It happened again today. I didn't even unplug anything. Just rebooted my compy and after the reboot KSP was of the opinion that what used to be Joystick3 is now Joystick4 and vice versa. setting.cfg still defines the T16000 and FGT Rumble correctly, but the game thinks the T16000 is Joystick4 and FGT Rumble is Joystick3. INPUT_DEVICES { FGT Rumble 3-in-1 = 4 T.16000M = 3 Control Manager ID #00 = 0 } Having to constantly babysit the joystick keybinds is infuriating.

I have a CH Throttle, which is mapped to create two virtual controllers to overcome the 20 button limitation of KSP, using the CH Control Manager. CH Control Manager Device 1 and 2 respectively. When I mapped the throttle axis in KSP, I moved the controller and KSP recognized and bound it just fine. It was saying "Control Manager ID #00 Axis 2". But when I went into the game the game throttle was completely unresponsive. I had the throttle mapped to the Control Manager Device 1 Z-axis, but the game was listening for the Z-axis on the Control Manager Device 2, because in the games internal logic the secondary vitual controller was the primary of the two, and it couldn't tell that they were two different controllers. I finally fixed it by switching the mapped Z-axis on the secondary virtual controller. But it seems that if two control devices have similiar names, KSP can't always tell them apart. Maybe has something to do with the hash symbol in the name. Also every time I plug in a new (or old) game controller to the computer, the next time I start KSP it seems to think that this new controller is now Joystick1. This messes up all the keybinds, on all the joysticks, as the controller that userd to be 1 is now 2, 2 is now 3, and so forth. Hey developers, listen up: all the game controller axis and buttons need to be bound to unique identifiers, not names, and definitely not numbers of order. The game needs a surefire way of telling one controller from another. Good joystick support is paramount in a game that is mainly about flying in various environments.

Damsels in distress. Sarkeesian was right all along.

I may have encountered a bug. 1. Make vessel that has Mk16 parachute as it's root part 2. Focus away from said vessel so that it unloads. 3. Re-focus/re-load into vessel. 4. Undeployed parachute now has same drag as fully deployed one. Can anybody reproduce this? I'm running a game with a frackton of mods. But I was able to reproduce this using nothing but vanilla parts.

I just came here to ask how to disable the "warp to" button in the map view. Luckily for me the answer was right here at the last page. Not in a million years would have I figured it out on my own. As feedback "Set alarm type:" seems like a option for setting the alarm type, not a way of selecting between different setting pages/tabs. To make this even worse the other page selectors: "General", "Specifics", "Audio", etc. are completely different looking, thus breaking the UI design consistency. Having the the alarm type specific setting page selector appear as the same kind of buttons underneath the main page selectors (General, etc.) would present the options to the user in a consistent way. But as a stop gap measure even substituting the text "Set alarm type:" with the text "Settings page:" would reduce the number of people asking how to disable the "warp to". And in this ones humble opinion, now that the vanilla "warp here" has been implemented, the warp to map view buttons should be disabled by default. Especially considering how prone they are to accidental clicking.

I appreciate the +60% capacity increase in both liquid fuel and oxidizer tanks. And while this is a definitely a step in the right direction, I'm going to argue that it's not quite enough. The fact that there was a +60% increase in the latest update implies that some if not all of what I'm about to say, have already occurred to you, but I'm going to say it anyway. Prior to the new aerodynamic model the drag of a part was directly proportionate to it's mass. This had the effect of making it so that the density of the part did not effect its aerodynamic properties, and that the overall center of drag would normally be exactly at the same place as center of mass. So storing liquid fuel and oxidizer in separate tanks was never something I fancied myself doing. There was simply no practical benefit to it. However, none of these is the case anymore. Now it is possible to shift stuff around to move the center of mass relative to the center of drag (or external geometry in general), and the density of parts plays a big role in this. There are now reasons to put the more dense oxidizer either on top or bottom of the liquid fuel tank depending on what you are trying to do. But currently player is getting an approximate 15% density penalty for storing liquid fuel and oxidizer in separate tanks compared to storing them in a mixed tank. And according to my calculations in a lot of situations that penalty will be more than enough negate the benefits gained. I have come to think that 15% density penalty is non-trivial, un-justified and un-realistic. Not to mention that gameplay wise it needlessly limits the engineering optimizations available to the player. I understand that the liquid fuel tanks need to be balanced against the stock liquid fuel tanks, at least approximately. But the oxidizer is not subject to any such constraints. And if anything, the lack of stock oxidizer only containers explicitly implies that within the game world physics, oxidizer is denser than how it's currently being modeled by Procedural Parts. So my, hopefully well argued, suggestion is that the capacity of oxidizer tanks be further increased to a level where storing it in a separate tanks would not result in an unreasonable increase in the container volume. Approx 50% further increase to oxidizer capacity compared to current values, would completely eliminate the disparity. Don't agree? I would love to hear arguments against.

I like the idea of the floaters. And the 3D models look very nice and fit perfectly to the rest of the game. However, I have noticed a couple of issues with them. First of all the drag model on them is broke as duck. It makes no difference whether they are deployed or not, drag stays the same. But biggest issue I have with them is... the biggest issue... is that they don't float. (You had one job!) Just like the drag geometry doesn't change when you deploy them, neither does the buoyancy geometry. I would not consider myself stretching the truth at all, if I were to say that the floaters do absolutely nothing. For the purposes of floating, they are infact non-functional and broken. Steps to reproduce: 1. Put floaters on a ship. 2. Put ship in water. 3. Inflate and deflate floaters. --- 1. Build ship four (4) Radial inflatable float (Med) 2. Put it on water. 3. Go back to assembly and replace them with empty FL-T400 fuel tanks. 4. Put it in water and observe the difference.

I assume this is where you report bugs. There is a bug in the mechjeb code that corrupts "Current acceleration" and "Current thrust" output when engines have been throttled using the thrust limiter. Lets say you have a craft with 90kN of thrust and a max acceleration of 90m/s^2. If you limit the engine on your craft to one third using the "thrust limiter", then the mechjeceb "Max thrust" and "Max acceleration" field will display correctly that your new max preformance will now be 30kN and 30m/s^2 respectively. But when when you actually throttle up to 100% the engine thrust limiter is being taken into calculations incorrectly for the second time, and the output fields will read 10kN and 10m/s^2 respectively, even when the actual values are 30kN and 30m/s^2. Steps to reproduce: 1. Make mechjeb window with following fields -Max thrust -Max acceleration -Current thrust -Current acceleration 2. Make ship with engine, fuel tank and mechjeb 3. Mess around with engine "thrust limiter" slider 4. Activate engine and throttle up

I have been waiting for somebody to make this for so long. I hate being stuck to a stupid set of lego blocks for no good reason. Thanks to this mod, I'm never using the standard fuel tanks again! But that being said, the liquid fuel and oxidizer modes on the tanks seem to be bugged. For example the KI-1000 tank in its default configuration contains 126 units of liquid fuel and 154 units of oxidizer. But when you take the liquid fuel out, to make more room for the oxidizer (or vice versa) now it only holds 131.25 units of oxidizer. Which is actually less oxidizer than before (-22,74 units).