Lisias

No. It's something you "install" into the game.

Using a gamepad is like playing with radio controlled aircrafts. Nice for a few minutes, but... :-) I'm using this mod , and I suggest you to use something like it while you don't decide what to do. It will help *A LOT*.

Nope. But now it's too late, we already know they didn't planned 1.4.3 as they usually does (and should). This is the danger of open bug-tracks, they usually tells us more than they wanted us to know. =P It can be a problem, or a solution. Or both! :-) The "real" Squad's client, since 2016, is TTI. We are TTI's clients now, not Squad's. So, in order to help Squad, we need to deal with TTI's first. The cash cow is, usually, the best way to influence business decisions - but it's also the reason they use for shutdown products. It's tricky to reach the ideal balance. But it's also the way I'm adopting - I almost had bought the Mission Builder at launch. Yes, I'm very happy with KSP - besides the bugs - it's some time since a game give me so much fun as the last weeks (i bought it at 1.4.0 times). But then they launched 1.4.2, what disrupted (seriously) my way of editing crafts (man, how I hate when things "snaps" by itself even by the snap button being disabled!), and I decided that buying the DLC would be a bad strategical decision as a customer: So I'm also waiting the 1.4.3 version to see what happens. They are the man with the guns, I mean, money. There's not way to live without dealing with them. :-) I'm a technician. I'm a developer. I value the ending result, I work for the product. And yeah, I had my load on attracting some Management rage over me. Then I decided to learn about these guys, and took some PM lessons. Well, I'm still a technician, I still work for the product - but at least know how to deal with them: follow the money. It's always about the money. (Yeah. It <use your non-forum-policy-conformant-favorite-interjection-here>). Point taken. I agree with you. Too. :-) Some common ground between the internal management needs and the public communications needs must be worked out.

There's no 1.4.3 target of the filter (essentially what you are complaining). Dude, I'm not your enemy - drop your guns, please. You are forgetting one: "Paid bills". The *real* management problem is how to accomplish all of that and have the bills paid at the end of the month. Drop your guns, please. (Mainly because your sorting is far from being ideal from the Project Management point of view)

Oh, now I see. You have a point, indeed. I think we are getting close to the real issue. There's a problem on the "Expectation Management".

Something like this? :-) Except when it doesn't. I'm on the Open Source "biz" for 20 years now (not exclusively). I know uncountable cases of terrible situations made worst by a lapse of a developer. In almost all the occasions, the dev was right and did the right thing but didn't had the social skills to recognize and prevent falling in a trap, and the after math was a hell of a P/R nightmare for the project. Sometimes, a very costly nightmare.I had seen people loosing jobs on this. People don't hire developers by their social skills. People hire them due their development skills - and these skills are not mutually inclusive. (to tell you the true, they are almost mutually exclusive - I know, I'm one of them) You mean this? :-)

Neither they should. One best practice on Project Management is shielding the development from the stake holders (us). :-) You don't want "stalking" holders messing with your dev guys!

Hey, I managed to stabilize the design! Use a Standard Canard as Yaw Stabilizer (it's even bigger that the part I used before) with 150% authority. use SAS, set the spring/dumpers to 1 & 1.4 on the main gears and 0.7 & 1.2 on the tail wheel, and I managed to reach 134 m/s on a speedrun on the runway without crashing! That's more than enough for landing and take of!

Here, something like this: Tail wheels can be dangerous when just wounded. As you get speed, the tail looses friction and you will have to rely only in the yaw stabilizers to keep the plane on track, what usually demands a bigger yaw stabilizer. The faster you need to be on the runway, the bigger the tail. Give it more authority too, and use SAS on taking off (or an autopilot). You will, also, need to trim the wheel's spring and dumper. This also limits seriously the landing speed. Land too fast, and the plane will flip over hits side - exactly what happened on you, as it appears. Note the engine heat up - it will blow way before the landing gear, as it appears! :-) Oh, I forgot. :-) A nice way to testing landing gears is to take off and, as soon as you rise about 5 meters, cut the engine and let the plane fall off slowly (or not). User KER (as I do) and monitor the vertical speed. Touch down in many vertical speeds to figure out when the thing breaks, when it bounces and if you need to trim the springs and dumpers. :-)

Small, fast aircrafts are hard to fly using keyboards. Get yourself a Joystick, or use some autopilot to do the heavy lifting for you. Inclined landing gears are less stable, in my experience. I would attach the landing gears laterally on fuselage. You would have the same wheel span, but the aircraft would be lower. A setup que works for me is using the main gears under the wings (steering disabled), and then use a small, steering wheel on the tail - biplane style. That small landing gear hold well up to under Mach 2 - but heat up and explode above that.

Some mods use the Stupidity and Courage to cause some influence on what they do. Scientists with high Stupidity would fail a lot more on the experiments, and Pilots with high courage would endure more G's before blacking out. I agree with Mako, I don't think Squad would implement something on it in the foreseeable future - they already have their mouths full, and there're mods that already do something with it.

Well, so we have to use the troublesome troubleshooting after all. You will need to provide such information to Squad in order to allow them to diagnose the problem (assuming that we don't diagnose it ourselves) and fix it. I'll assume you know squat about command line and UNIX tools - forgive me if I'm too much verbose and/or patronizing. 1) Open Finder in the directory where KSP.app is. 2) Right click on the KSP.app, select "Show Package Contents" 3) Right click the "MacOS" folder, select "Services" and then "New Terminal at folder" 4) type: 4.1) "pwd" and hit ENTER 4.2) "ls -l" and hit ENTER 4.3) "./KSP" and hit ENTER Wait the program to crash and make a screenshot of the terminal window. With luck, this *can* lead us to the problem. I attached a screenshot of mine (that works) to example you what to expect: To tell you the true, I have WINE installed on my Mac. So, when I double click an .EXE file, it runs. :-) Or used to run, since my upgrade to Sierra, things don't work anymore. It's probably some glitch that can be fixed, but I didn't bored to diagnose yet.

What your are describing, sir, is the bad way of doing Software. Such small mistakes, exactly by be expected in normal day-to-day development, *MUST* be handled by the Q/A team (or by the devs doing Q/A), *not* by the Q/C team (and this is something that the development team should usually stay away). An "acceptable" bug on a software this level and size is caused by a dozen of spurious iterations not usually realized on development (usually focused on the problem under the nose). The Integration Tests, ideally, should detect these - but not everybody has the juice to fund such tests properly, if one at all. A huge, monstrous bug that crashes everything corrupting the savegame and that happens because you built a craft with vectorized thrust jet engine in the nose and fired it up in space on a radial out burn is something acceptable. A landing gear that explodes because someone typed an extra "0" on a single precision float on some source and caused an underflow that leaded to a DIVBYZERO exception, not that much. Small, common errors are unacceptable on the release. They are expected to be handled by the Development Process (Q/A), not by product testers/users (Q/C). And this is not due the "severity" of the consequences, but because such errors are already expected to happen and then are expected to be already dealt with when the current iteration goes gold.

When this happens to me, I jump before grabbing the stairs. Sometimes it works. But, at least in my cases, usually replacing the stair solves. Sometimes, the stair "invades" the invisible collision cube from another part, and then the Kerbal stumps on it.

Since the program started, this means that it crashed early before starting to log, and after initiating the graphics mode (what's a fail, since they missed the chance to log what happened now). I don't think that reinstalling the thing would fix anything - this happened twice in two computers. Or there's something different from what's expected on your two computers, of the package you have is corrupted and you have to redownload it. If you use Steam, there's something that you must remember: these guys, and I don't have a clue why, wrote the Steam tool dependent of a Case Insensitive file system, and there's a plugin on the KSP they provide that fire it up. So, even by Mac KSP itself working fine on a Case Sensitive HPS, the Steam plugin, perhaps, may be the reason your KSP is crashing. Check your two Mac's file system case configuration, before we start a more troublesome troubleshooting! By the way, I'm tested 1.4.2 on my Mac Mini mid 2011 running MacOS 10.12.6 without problems. (I running Steam, and created a disk image with a case insensitive file system just for it)

Besides being quite old, this was the first thread I got by searching Google, so I think the solution I figured out should be placed here: 1) Select the Kerbal you want first person view. 2) Right click him/her 3) Select "Activate Camera" Use "V" to go back to external view. If the selected Kerbal is the one piloting the vessel, you will have a pilot's view. No HUDs, however.

What says ksp.log? Delete the current one and fire the thing again to see if a new one appears.

*HOVER IT* ? All I had to do is hover the mouse pointer on it? Damn, I was trying to click (left and right) on it! =D I'm wasting too much time on touch-screens, as it appears...

I don't. :-) I hate every new bug as everybody else (some of them, deeply - even more when they came back from the death, I mean, closed/fixed status). =D At the 1.2 times everything works because almost everything was being written/rewritten for the 1.2 version. Just like that. ( I also acknowledge that the somewhat dramatic events that happened at that very time surely caused a lot of trouble - but this is another discussion for other time, elsewhere). When 1.3.1 came out, a lot of things broke because a lot of things changed. And this didn't prevent people to keep writing/maintaining/porting mods to it. It appears to me that 1.3.1 is, currently, the richest environment for mod enthusiasts. At least, for while. On 1.4, they changed the Unity version. Dude, let me tell you, this is a *huge* change - not always with desirable side effects. Unity lacks consistency even on releasing the *very same version* of the runtime for different platforms, how much between major releases. FXGroups changed, and so *A LOT* os mods that relies on it needs to have some parts rewritten. But the mod's developers and maintainers have a day job, so this will took some time. It's almost 8 years since the first KSP version, and about 4 since 1.2 - some people just moved on, others grew and now have less time to play with these things and a lot of guys just dropped by on parachutes and just don't know what to do yet. KSP is almost as complex as a vintage operating system. If you were a developer on the Win95 times as I was, you would had faced things *a lot* worse - damn, MS took 10 years to fix some serious and stupid bugs on MFC (and when they finally did, they broke everybody as we had workarounded the stupid mis-feature, and when the thing started to work as specified, we had to workaround the workaround). I agree that 1.4 was released some months before it should, but mainly due a lot of small mishaps on the code (and some regressions) that were published without being addressed first. Serious bugs, crashes et all I'm getting with different mods iterating with themselves - by removing one of the mods or creating specialized installments with just what I need in the moment, things works again. Or almost. =P About the KIS/KAS/et all features... I would have some reserves on spending human resources duplicating features that are already provided by the community (besides not tightly integrated) than... enhancing the game engine and fixing the bugs. At the present time, I think they have some other problems to solve (as keeping the game attractive to new, paying customers!)

Dude, what a piece of magnificent work! :-) Had you consider using UbioZurWeld ? It would reduce the part counting considerably - but you would need to provide a download link for the welded parts (and keep the original parts for reworking when necessary...)

No one? :-( Perhaps we should address Squad and/or TTI directly? But a public answer would be best, however...

I got a enervating issue on 1.4.2 , the only one that made me rollback for 1.4.1 - when building a vessel on editor and doing some clipping, the part jumps automatically for a snap position even with the snap button unselected. So, or you get that part in place at first try, or the thing jumps to a snap position when you try to fix. And, again, *even with the snap button unselected*. Never figured out a way out of this, so I rolled back to 1.4.1 for while.

I just fired up a 1.3.1 to see that. Well, it works on a vanilla install. But it works *slowly*. Very slowly - and the control indicator on the HUD moves. Try a clean install, then add your mods one by one. I can't think on anything else.

The easy way out, attaching a smaller control surface into another one, it's not allowed by the game. :-) I didn't thought on the AoA, nice catch. Currently, I'm trying to prototype the idea using a arbitrary control surface "marked" as a trim tab - I just clip a smaller control surface inside a bigger one on the same place and that's it. This working, I can proceed to the next step.

A lot of little things changed on 1.4 series. Some, obviously, are due the Unity version update. But some others, I wonder if the Mission Builder was the reason.