Arsonide

Ah, sorry I was talking about the resolution of the map, not of each pixel. Yes the level of detail goes up, but the scope of your view goes down a bit.

Yep, there are two plane parts with KerbNet access: the Mk2 Drone Core, and the avionics hub, which isn't technically a probe core, but we wanted a low level plane part with KerbNet access. The RoveMate even has KerbNet access. Of course, your scan resolution gets lower as your point of view gets lower. The RoveMate for example sees a radius of about ten kilometers.

The waypoints are not saved on the craft, they are uploaded to Kerbal Space Center, so they are available everywhere once placed. They persist in your save file until deleted. They also function in every game mode, including sandbox, and have all of the features of normal contract waypoints, like navigation mode.

As of now, if you disable communications networks, KerbNet will be available in sandbox mode, but not career. Of course, that might change before release based on feedback.

It is an option, one that is off by default. If you do not think the game needs it, then do not enable the option. It also isn't very similar to Kerbal Joint Reinforcement. That stiffens joints, and adds new types of joints. Autostruts add more joints. The concept has been in the game for a while already - it is used by fairings to keep the nose of a payload from swinging around, and it is used by wheels to stabilize some instabilities in PhysX. Due to the positive response it received, we expanded it a bit, but it is still off by default in most places.

No, the orientation and configuration of a strut affects the stability of the craft. Depending on what mode you use, autostruts will always go to either the root part on the vessel, or the heaviest part on the vessel. Unlike a normal strut, you have no control over where they are going..

You can look up practically any word on Urban Dictionary and find it being used in a derogatory or perverse manner.

I always saw it as a fun shorthand term, rather than an insult.

We decided to keep the autostruts in as an option after the positive reactions we were getting in that stream and elsewhere. @NathanKell expanded my initial implementation of the wheel autostruts to be a tweakable on every part, and we have added multiple modes to customize how they behave. We did lock them away behind the "advanced tweakables" option though, so the player has to explicitly enable them.

In Unity, if you change the color or texture of a material, for example...it will instantiate another material in memory and change the color of that, so you end up with two materials in memory. Sometimes we only need this second material for a moment, and suddenly it becomes garbage. Material Property Blocks allow us to state that "Hey Unity, we only want one material in memory please, but this renderer is going to use the color blue, and this other renderer is going to use the color red."

You're right, the slider gives you more control than chains.

You've never heard of people putting chains on their tires to drive through the snow? No laws of physics are being broken, it's just an abstraction for various things an engineer can do to the tire tread. As for the tweakables, we want the player to have as much control over the behavior of the wheels as they need because their behavior largely depends on the configuration and weight distribution of the craft that the player has made. Taking those away would just be taking options away from the player.

This can generally happen if there is some sort of exception while the game is loading your contracts. It will be difficult to diagnose without a log. What sort of mods do you have installed?

Part of removing wheel blocking was ensuring that wheels properly ignore same vessel parts, they behave like any other part now in that regard. The sliding you are witnessing and the vibration are two separate unrelated issues, but we are aware of them, and are looking into them.

No, most of our issues were indeed issues with Unity 5.2, which many other games were also experiencing at that time. We are pulling out the workarounds that 1.1 needed to use to bypass those issues now that we are no longer using that version. Updating VPP is more of a tangentially related maintenance task.

It was not on a pure whim though, we enlarged them so that they would not be buried underground at lower terrain detail settings.

This is something we have noticed, and no there isn't anything wrong with it. Kerbal Space Program is ultimately a game about player freedom. We give the player the tools, and he is free to do whatever he likes with them. With contract objectives I try to gently encourage people to go interplanetary, but still cater to people that do hang around Kerbin and its moons. With planetary weighting that will be even more pronounced, as people that do things in that area will get contracts targeting that area.

I think people are connecting dots on different pages of the coloring book here. A few developers moving on to other opportunities does not mean the sky is falling at all. In fact, over the last year or so the team has been growing. Also, I literally cannot read through this thread without hearing this.

Sure you have. Most of us have been here for quite a while, just at the edges of the frame. Oh it's not so bad.

Soon as in it is next on my hit list. Do not worry.

We are focusing on optimization and clean up right now, rather than bug squashing. However, that's not to say that we aren't catching any while we optimize. Wheels (and legs by extension) will be getting a pass soon.

Ideally one that was confirmed on the latest version, and one that mentions the error that you are receiving. The only one of those issues that does mention the error is eight months old, and appears to be a fairing specific issue. We like the issue to be as specific as possible, so that if we do read it eight months down the road, it is obvious that it is not an unrelated physics and/or aero issue. Only one of these issues has reproduction steps, and none of them have logs or save files attached. The craft files do help, but we generally want as much information as we can get. The wiki has information on how to find all of these things. As for if the issue is feedback about an intentional mechanic, or an actual bug, I would classify it as a bug for sure, but a "normal" priority one. The mechanic is not crashing the game, but is also clearly not intended to occlude parts outside of the cargo bay. Normal priority does not mean it is not important, but we reserve high and critical for things like "the game cannot run". This does affect gameplay, so we want it as high as we can get it without dipping into crash territory. I understand that the issue is frustrating for you, which is why I want to make sure that we get it cataloged. We like to keep a detailed written paper trail of these issues, because it allows our QA team to follow up on them in an organized manner. If there is enough information on the issue, they will be able to reproduce it. If they can reproduce it, we can fix it. Once we fix it, they can double check it, and hopefully resolve it on the tracker. Even after it is resolved, it remains on the tracker for future reference.

http://bugs.kerbalspaceprogram.com/projects/ksp/wiki

Another quick search of the public issue tracker shows that this issue has still not been properly reported. Doing so will ensure that the issue gets some visibility when the team is done with the optimization pass that we are currently working on.

A quick search of the public issue tracker does not appear to result in any specific issues of this nature. Please report the issue with logs, save files, reproduction steps, and craft files if necessary. Thanks!