YoD

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

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.

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

Does it even make sense in real life ?

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

Here is a variant:

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

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

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

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

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

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

It is a mobile base

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

Ah indeed, here it is !

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:

An example of one tree flying and one borrowed:

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:

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.

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):

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

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.

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:

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

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)