[Oversized icons in map view]

I fully agree as it should not take long to correct: icons should not be so big they can hide planets making them no longer clickable or targetable

[Burn start and end indicator lights are confusing]

It was more or less working at patch 1, and now it barely makes any sense at patch 2. Additional bugs arrived as well on the same topic.

I wonder if they performed any tests before releasing the patch 2.

[Lots of problems since last patch]

Since last patch, I have seen things no one should see, hoping for a new patch any soon 

[Yet Another Showstopper / CTD]

Does it even make sense in real life ?

[Invisible wall in Kerbin Atmosphere 3]

Thank you, it is exactly what I have started to read for a couple of days 

[specific altitude off surface kraken attack]

Here is a variant: 

 

[Not able to read planted flag]

I can confirm, which is a bit a shame as the only job of a flag is to be read

[[v0.1.1.0.21572] Symetry in VAB has HUGE problems]

I wanted to create a topic on it as it is making me crazy: it is not only that symmetry currently does not make any sense, it is that the behaviour is not reliable: with the same 2 pieces and using the same symmetry button, you can obtain 2 totally different results 

[FPS drop inside VAB when other vehicle is on launchpad]

I guess it does not unload the kerbal space center everytime we go in the VAB, to facilitate the switch between the two. Best way to optimise is to not let a craft on the launchpad I guess 

[Massive Instability / Performance Loss after opening Parts Manager during a Burn.]

Part Manager is always quite slow to open, when it is just a list of text and buttons: the corresponding information should be calculated when the vessel is in the scene, and not when we open the Part Manager

[Staging with space bar stopped working]

What is strange is that spacebar should literally be linked to the launch green button, so having the spacebar not working half of the time while the green button does is definitely an improper conception

[Minor bug/gripe: Renaming craft from Tracking Station is not ‘durable’]

Indeed, it should not cost too much to save properly the craft name after renaming... Currently, retrieving the proper craft when we have a dozen is quite a mess

[Rumor: Adding LOTS of TR-4 Wheels will allow a Rover to Climb Hills.]

It is a mobile base 

[Flying tree on Kerbin]

I feel like removing these underground layers of terrain which should not be visible would incredibly improve rendering performance

[Where is the park break ?]

Ah indeed, here it is ! 

[Where is the park break ?]

I have just realised there is no park break available (or if you have found it, please indicate it to me), which is quite a no-go for any kind of serious rover 

One of the result can be your rover finishing in a lake: 

[Flying tree on Kerbin]

An example of one tree flying and one borrowed: 

[Flying tree on Kerbin]

Maybe I am pushing the bug report a bit far, but some trees seem to be flying, other borrowed in the ground, as I guess ground calculation was incorrect when the tree is generated.

However, if ground is not properly managed during tree placement, I fear the worse when real collision happens.

Here I have put my kerbal under a flying tree:

 

[Standard rover wheel does not seem to handle more than 21m/s]

It is actually worse than I thought: I tried to maintain a speed of 10-11m/s, and the same drift continue to happen (with no info or log displayed in anyway).

Drift behaviour seems to be based on an amount time passed driving, no matter the speed, which is even more unexpected as there is no way to avoid it.

[Standard rover wheel does not seem to handle more than 21m/s]

Pushing the testing, I changed for bigger wheels

At 21m/s, they behave better:

 

And then at 24m/s, the drift happens again (for litteral no reason):

 

 

[[v0.1.1.0.21572] dancing rover =) Upon loading wheeled craft has its physics wheels in jerky motion]

If the wheels were gently dancing without making the rover jump/drift/salto, it would be "ok".

However I am pretty sure it has already at minimum two side effects:

- when rolling straight forward, a rover will drift for no reason after a certain amount of time, independently of its speed

- when leaving Kerbin, rocket with wheels attached to it in a way or another will become incontrolable most of the time at mid atmosphere 3, independently of the acceleration, making rover launching impossible or at minimum particularly tricky

[Standard rover wheel does not seem to handle more than 21m/s]

When performing rover testing in the KSC, the wheel behaviour seems unexpected.

At 20m/s, everything is rather ok: 

 

However reaching 21m/s (approx.) makes the rover drift/bump/salto, and changing the wheel traction level does not seem to have any impact:

If rover behavior is not predictable on full flat ground, it can hardly be used in other situations.

Maybe one of the reason is that the runaway is not actually flat, but slightly inclined, and going over a specific speed limit creates a collision detection between wheel and ground. However, it should not produce that behaviour. 

That type of behaviour might also happens with planes, complicating a normal take off.

[Camera looping between orbital mode and ground mode at low altitude]

When orbiting at very low altitude around Mun (or any other planetoid), the camera cannot distinguish if it must be in Orbital mode or in Ground mode, and switches between modes 5 times per second. 

Clicking on the interface (surface/orbit) or (ground/sea) does not stop the mode from auto switching continuously.

Although it is not hard blocking, it definitely prevents a proper view of low altitude situations:

 

[Invisible wall in Kerbin Atmosphere 3]

I have continued the testing:

- it happens when any type of wheels is attached to the rocket - removing the wheels removes the issue

- it happens starting at mid atmosphere 3, creating regular bump of the wheels with no evident physical reasons, usually leading to the vessel getting wrecked or at minimum becoming incontrollable

- it is independent of the speed

- it is independent of the acceleration, meaning that it happens even with no engine on

- it is independent of the weight/shape: stacking multiple other parts instead of wheels do not reproduce the issue

- it is independent of covering the rover or not: having just the rover stacked at the rocket top, or protected by a cargo bay, does not change the behaviour

As a conclusion, I will check video of people who succeeds in launching rovers, because anything with wheels in my testing will never properly leaves kerbin atmosphere 

[Invisible wall in Kerbin Atmosphere 3]

Trying to send a rover to Mun, I always encounter unexpected behaviour in the Kerbin third level of atmosphere.

In the first level of atmosphere, no issue:

 

In the second level of atmosphere, no issue:

 

In the early third level of atmosphere, no issue:

In the mid 3rd level, explosion with no log or any kind of information: the rupture is happening everywhere at the same time with no info log at all:

 

It definitely looks like a bug in the game, like an invisible wall, or:

- atmosphere 3 should be divided into 2 different atmospheres

- log regarding the vessel breaking origin should be displayed, indicating where the first rupture happens (as of now, the explosion is so massive no log is available at all)