Alshain

Well, that's the thing though, the only way to change the grip would be to change the wheel. It would be a different part. Tire pressure may effect traction, but rover wheels don't have air in their tires. Often airplane wheels are solid rubber too, though this is dependent on the tire (the little ones would probably be solid rubber). So you would have to replace the wheels with other parts, which still wouldn't allow you to have 0 friction. Ok, you know what. You are just trying to stir up a fight rather than coherently discuss this issue, so I'm just going to put you on the good ol' ignore list, because I like discussion, but not baiting.

The friction control. That is the main one that I know of. I haven't spent a lot of time playing 1.1, but being able to alter the friction is being able to alter the physics which is fine that you can do that, but it should be something you do in Alt-F12 or in the physics config file by modding. It was only added as a stop gap measure because the wheels are so awful anyway. When the wheels are fixed it should be isolated or removed out of the main gameplay.

But that's what I'm telling you, it's not imposing my way of gameplay, it's imposing a 'physical world' gameplay that KSP was designed to be. Being able to wave your magic wand and alter the friction of a particular set of tires is not something physically possible in a real world scenario. It's magic, and KSP is supposed to be science, not magic. I can't alter the friction on my cars tires. I can alter the spring and damper by inserting spring rubbers and tightening the suspension, those aren't the issue here. Without replacing the wheels I can not alter their friction. But now Squad has added a way to alter the friction of the same set of wheels to be several different settings. More over, it's too fluid, even if it were simply changing the tires, there are set standards of rubber compositions and tread to choose from, you can't just turn a slider from 0 to 1 and go. This goes against the design of KSP, in a rather major way, it's no different from the Hack Gravity option that allows you to completely ignore the physical laws of gravity.

What you actually said was that you have the right to express your opinion, but if I express mine, you feel the need to clarify that my opinion is an opinion. So either you feel I am not entitled to my opinion or for some reason you feel that no one else of the forums can discern what is an opinion and it must be called out (even though nobody actually called out your opinion as such). You also assume that everyone on the forum agrees with your opinion because you said "but you don't actually speak for us all." So why exactly do you suppose it is that you are somehow superior in this regard? The truth is, you disagreed with my opinion so you tried to dismiss it as an opinion, even though every post in this thread is an opinion and there is nothing wrong with opinions.

" I speak for nobody but myself" "why it matters to you, why you wouldn't use it. This is not a convincing reason" So what you are saying is it's ok for you to speak for yourself but not ok for me to speak for myself?

I could say the same, and I will... You are welcome to your opinion, but you don't actually speak for all of us. This isn't a case of me wanting everyone to play the game like I do, it's a case of wanting the game to have a consistent rule set. Otherwise, why not just make HyperEdit a stock function? A game has to have a rule set to play by, even in single player, otherwise there is no point to it. If I can just alter physics, then I can do everything in the game in a matter of minutes and then KSP suffers from that. I can be at Jool in the amount of time it takes to type in the HyperEdit window, but then it isn't really much of a game. All I am saying is the cheats belong behind the cheat menu. They don't have to remove them, just put them where they belong. That's why the cheat menu is there. (Note: I'm using the word "Cheat" because that is what the menu is called, this isn't a debate over cheating)

Because it alters the laws of physics and goes against the gameplay. It's no different than Hack Gravity, and that is where it belongs. When you start sharing craft it becomes an issue if one person is using it and another is not, in one case the craft works just fine because it is altering the laws of physics and in the other case it no loner works. Then there is the Multiplayer functionality that we know is coming, if a server ends up configured to block cheats in the Alt-F12 menu that should include any ability to alter the way physics behave. It is best to correct this now, rather than allow it to continue and become the 'norm'. Really it should have never been put in the game to begin with.

Well then it shouldn't appear until enabled by an alt-f12 option. Any persistence of the options should be removed if the alt-f12 option is disabled. If you are going to add cheats, be consistent about it.

No cutscenes. Never, ever, Abso-freaking-lutely no! Nothing but annoyances.

If they could be scrapped, I would say yes. However I know they can not be scrapped while using Unity 5 and I know we aren't going backward. I agree they are absolutely terrible and I just want the wheels to behave more like they did in 1.0.5 so I can finally use a Unity 5 version of KSP. However, the only option is to look forward and hope Unity 5.4 fixes them adequately, and then try to forget 1.1 ever existed. Hopefully they remove the cheats with it as well. It makes no sense to be able to alter the laws of physics on a tweakable.

For the SSTO, I would suggest... don't use SSTO. You aren't saving anything. SSTO's are way overrated, and they aren't very cost effective. As for the VTOL, it won't work that way, you will never get it to be so precise. I really don't care if they add it or not, I just don't see the need for the effort and I doubt they will add such a thing anyway. There is no precedent for it in game and the system of configuring it that you propose is very complicated and goes against the simplicity that Squad tries to maintain with the UI. I wouldn't get your hopes up at this happening.

I don't really get the need for this. I mean, why would you carry dead weight like that? In space, it is irrelevant because you typically have plenty of time to adjust manually. When launching in atmosphere, having an engine that isn't performing at it's maximum is dead weight and should be designed better or discarded via decoupler. It makes absolutely no sense to change the thrust limit as you ascend, if your TWR is too high then the rocket should be designed with a lower TWR or designed to stage away the extra mass. In fact, I don't recommend thrust limiting liquid engines on launch at all, that is what the throttle is for. As for VTOL, in theory it could be useful but in practice, it won't be fast enough or versatile enough to be able to balance out the engines even with action groups so... well I'm positive it won't work the way you want in the end. Regardless this would take a UI overhaul. Action Groups are inherently boolean and I wouldn't count on that changing any time soon.

But why? The 1.25m fairing works just fine for 0.625m probes and it's not like you are going to put that probe on a 0.625m launcher. Again, there is no need for this, and it would be very limited and serve almost no use at all. We have enough useless parts already in the game, we don't need more.

That would be way too big for a 0.625m fairing.

So they would add an entire fairing for one probe core which can't even have fuel or propulsion, or batteries? Sorry, but that would be a wasted effort and a waste of RAM space.

There is nothing in the game that would fit inside it. Your fairing is supposed to be one size larger than the parts you are using for the payload. For 0.625m probes, you use a 1.25m fairing.

Yes, on "rocket parts". It's currently unclear what that encompasses though. One would hope all the lower quality textured parts would be included, however that may take several versions to complete.

Not in any memory managed language (C#, Java, etc). Modern languages do many things for you, including tracking memory locations (this eliminates the necessity of pointers, though you can still use them if you must) and they also track threads for you. There is just no need to run a management thread anymore, you only have to designate a task to be run in a new thread, in some cases you don't even have to do that and it threads automatically, though that is usually the framework or engine components only. Windows Forms for example will automatically multi-thread it's components through the .NET Framework. Of course KSP doesn't use the .NET Framework, but I'm sure Unity does the same.

Umm, all Kerbals are imperfect. Their eyes are different sizes, the right eye is always larger than the left. Did you not know this? I may not be doing you any favors by telling you rofl

Well presumably KSP (and Unity) is developed in a thread safe manner, however failure to observe thread safety can cause issues, like race conditions. Often a simple bug can break thread safety but that doesn't mean they intend it to be that way, it's just a mistake. As far as controlling thread execution, the KSP developers don't go that low level. That is handled by the operating system and the Framework, Runtime, and/or Game Engine. You seem to be suggesting that hyper-threading and multi-threading are two different things when in fact hyper-threading is multi-threading. I presume you are referring to multi-core processing where threads are split among physical cores rather than among virtual cores. In both cases, this is still multi-threading. Hyper threading is a very interesting topic, but to oversimplify, sometimes threads have to stop and wait on some external input before it can continue. This can be a user input, from the mouse or keyboard, or another thread, or timer. Normally that core would just sit there and wait for that input, but with hyper-threading, while that core would have been inactive, it switches out to process an unrelated lower priority thread. When the external input it was waiting on returns, it switches back. There are some pitfalls to this with multi-core processing. The most notable pitfall is that switching threads does cause a slowdown because memory in the CPU cache must be relocated to RAM for the first thread, while bringing in new data for the second. This may or may not be noticeable, but technologies in today's CPUs can mitigate this to some degree. Now, as for bugged drivers, that has nothing to do with KSP at all. There simply is no correlation between your webcam and KSP. I don't know what would cause your boot to be slower, that sounds a bit strange to me.

You are assuming it is broken and not how it was intended. It's very Kerbal for things to be imperfect.

I see, well on the list of important things that need doing. I would say this falls below adding (other) alien species rofl. I mean, really?

I find it incredibly doubtful Squad is going to implement a Scripting language at this point.

Finally? Lights have had color for a very long time.