swjr-swis

Using the exact same rover I linked before, the one I also used before to test on the poles, launched as is and edited to the Vall surface at the coordinates you mention above, I see no anomalies at all in its steering or controls. Just in case, I also went and tested it around 90, 180, and -90 degrees longitude on the equator... no problems at all in steering at any of those locations, just as the poles before. (*) Please try that rover in the same situations. I'm pretty sure you will not see any control problems with that one, in any of the locations. BUT. I have a sneak suspicion of what might be causing your issue, and this may in fact be considered a game bug: from your save file and your rover craft file, I take it that you are building your rovers in the VAB instead of in the SPH, true? And is it also true that you are building them with the wheels pointed at the VAB floor, instead of pointed to the VAB north wall (which would be the default 'down' direction for craft built in the VAB)? An additional test I did by building a rover from scratch in the VAB showed control/steering anomalies when placed in certain situations/locations. It would appear that the control logic is somehow also affected by the orientation differences of VAB and SPH, leading to similar problems as when the probe core is not oriented in the same plane as the wheels. You should be able to test this by building your rover in the SPH. Don't simply reload the one you already built in the VAB: I tried that too, and it did not solve the issue. Build a new rover in the SPH, with the probe core oriented the way it loads by default (pointing forward to the door, or 'on the side' as you say), and the wheels pointing at the SPH floor. Don't use the rovermate - as said before, that one is oriented wrong for rover use (something I consider a bug). Then try your new rover on the poles and the equator. It should not show any of the issues you have experienced so far. (*: irrelevant to the issue discussed here, but worth a mention - some of those coordinates place the rover on a steep incline several km up. I had an absolute blast driving my rover down the incline at top speed and doing the 'yeeehaw' thing every time a dip in the surface made the rover experience several seconds of airtime. Driving on Vall is fun! )

I don't think drag is related to the issue mentioned: there is no atmosphere at the Kerbin/Mun SoI transition, or when landing on the Mun. The new SAS logic in 1.2.x, while definitely improved in some ways compared to before, still has some glitches to work out. The worst is a new and very distinct tendency of the 'hold prograde' mode to start an intense and sometimes amplifying swing in pitch angle, that I've only been able to counter by quickly switching to Stabilize and manually pitching closer to prograde before switching to hold prograde again. I can avoid it to some degree by strongly limiting the pitch authority of control surfaces and/or reaction wheels, but then it limits maneuverability more than it should need to. This is a behaviour I had not seen before 1.2.x. There is also still a spontaneous roll while holding prograde, but this is not new, this is a pre-existing problem. I've not seen a similar problem with yaw though. @Scarecrow, when you say 'spin', around what axis do you mean?

The control logic expects the controlling part to be oriented to face forwards towards the horizon. This is a fact. Doing it any other way will inevitably lead to control/steering 'errors' that are only errors due to an incorrect design. Those errors happen everywhere, not just the south pole. Wheels will appear to work, but if you observe closely you will notice there is always one or more wheels either turning or accelerating or both in a wrong direction. Proof 1: load the savefile from the dropbox link. Load the 'rover 1' from that save and launch onto the pad. Drive it off the pad. PAY ATTENTION. When you steer left while driving forward, the wheels make the rover turn RIGHT. When you steer right, it goes left. This is already happening at the KSC. Proof 2: back in the VAB, load the 'rover 1' again. Attach two launch clamps to the sides of the reaction wheel to lift the rover off the ground. Select the probe core with the rotate tool and rotate it 45 degrees as if it's climbing a hill. Launch and without staging, steer left/right and watch the wheels. Notice that now, front and back wheels no longer steer in unison to be able to make a turn. The incorrect probe core orientation confuses the control logic when on an incline, and the steering input to the wheels becomes 'incorrect'. This is not a game error, this is a design error. Were the probe core oriented correctly, this would not happen (try it to convince yourself). We haven't even left the launch pad yet, this is all happening at the KSC. Proof 3: put a rover with the probe core correctly oriented forward to the horizon on the south pole, any south pole, and drive it around the same area you saw these problems. None of this weird behaviour you're seeing with your current rover will happen (*). Feel free to believe what you will. It's not my problem and I've already wasted too much of my free time on this trying to help. I have no interest in arguing. Good luck getting your rovers to work reliably, both of you. (* with the sole exception of standing/driving over the exact pole where the singularity will flip the camera around or may even put the camera underground, which is a game engine limitation - when on the exact pole, by definition, all directions point north, 'heading' no longer works, and the camera view is apparently clamped to some sort of default to prevent a code exception).

This is not surprising: the rovermate is, for reasons unknown, oriented 'upwards' instead of forward, which due to the effects I explained before on wheel control/steering, makes it inadequate for rover control. Maybe whomever designed it that way was thinking more of VTOL craft than rovers, but the name makes it a bit misleading in that case. I have nothing invested in giving you bad advice. I even wasted some time downloading and testing both your save and rover, and one of my own rovers, on several south poles, which confirmed what I told you. My rover, with the probe core properly oriented, works fine, even in the vicinity of the south poles. You are of course free to ignore that.

*sharpens the pitch fork*

Anything can be removed (even the boot.ini *): http://winaero.com/blog/how-to-uninstall-and-remove-the-xbox-app-in-windows-10/ (*: don't try this at home, folks. seriously.)

I have tried one of my own rovers at a couple south poles now... I don't see this issue you mention, except when the rover is directly on top of the exact south pole or driving right over it. Wheels steering reacts exactly as one would expect. It is, actually, a rover design problem. If you build your rover with the probe core oriented like a rocket (forward = up into the sky), like your rover1 is, you will have problems with the wheels and controls at one point or another, and mixed with the heading singularity at the south pole it is made especially obvious. If you keep the probe core oriented like a plane (forward = towards the horizon, parallel to the surface), those problems go away.

If you go to the North Poles, you'll notice the same issues. Unfortunately there isn't much to do about this: due to the way the navball tracks a 'heading', the poles are singularities - places where the heading is undefined. Which means that the closer you get to the poles, the more and faster the navball heading swings around. Which is what affects the camera and your controls.

@sal_vager May I suggest the thread is allowed in the tech support forum anyway, even if only ... 'circumstantially' relevant on KSP? In The Lounge it's pretty much doomed to never be found by anyone that may benefit from it. With more console users among the forum visitors, and thus more people that may have the XBox thingamajig installed on their Windows computers, it is also likely that there will be more people encountering this same thing. It would head off the same question being asked again if there is already a topic in a more likely place where people may come look for it. Questions/topics that are really more about Steam/storefront/graphics cards/joysticks than about KSP have been allowed to stay in the tech forum too, after all. Just a suggestion.

Those messages and the shortcut are from the Windows 10 'Game Bar': https://support.microsoft.com/en-us/help/17188/windows-10-record-clips-of-pc-games And the screenshots are saved by default under C:\Users\<yourusername>\Pictures\Screenshots

Why not instead solving this in the localization effort, something that KSP Weekly stated has been going on for weeks now? If you're going to wipe/exclude words for their potential offensiveness (including vulgarisms, slang and not-entirely-spelled-the-same variations, like in this particular case) when read in any other language than the one they were written in/targeted for, I bid you good luck with any localization...

I had the same thought. A little cutesy personal touch killed. Oh well. Yet meanwhile, much more annoying and outright confusing/unhelpful texture errors remain (like the Mk1-2/Mk2 Inline/Mk3 cockpit asymmetric fake RCS ports, misaligned arrows on decouplers, 90 degree misaligned texture on the Mk0 LF tank, etc). You'd think those would've merited an edit by now more urgently than a touch of humour. Anyway. At least they finally did something about the Mammoth collider. Yay!

Sneak patch!!

Ahh yes, the 'Bird Trap'. We had to install that last friday, after the umpteenth supersonic jet blasted the eardrums out of our entire air controller staff by trying to land on the roof of the tower....

There's a thread marked as 'answered' in the prerelease modding forum: I may have misunderstood this. Apparently it's only for the Difficulty window in the in-game Settings. not sure if that would still be a workable place.

The type of survey doesn't matter, so use any of them that seem appropriate or offer the best percentage/field of view. The question marks indicating the anomalies will appear on the KerbNet map used at the time.

Add a toggle to the KSP Settings window? It's a New Thing of v1.2...

Psst... don't tell anyone I said this, but uhm... ..if you look in the game save files, you will notice this new parameter has appeared since 1.2: Also, some of us have discovered that the newly added 'green monolith' anomalies do not appear in the same places from save to save; which may be related to that new parameter, as there doesn't seem to be any other method by which the location of those monoliths is recorded in a save. Mum's the word...

You are missing the Spread Angle in this table. Makes a significant difference.

High warp while relatively close to a planetary size body is a risk in KSP, because the game starts taking liberties and calculating positions and triggers in bigger steps apart. Viewed from a Kerbol perspective, planetary bodies and their moons are zooming at very high speeds through space, and every physics calculation represents big distances. You may have just had the misfortune that the collision routines were triggered before the game could reposition the craft to the equivalent position the surface had moved to, or vice versa, and for that split second both were in the same place at the same time. This can happen sometimes faster than the screen is redrawn, so it still looks like they're nowhere near each other. It used to be a frequent thing once upon a time, I've not had it happen in recent versions though.

It's always risky to move saves between major versions of KSP, so keep a copy of them archived just in case. That said, and although I don't move saves myself between versions (it's easy enough to keep a different version installed to 'finish' those): I have gone into the Difficulty section of the in-game settings plenty of times now to switch most of the settings on and off back and forth in different combinations, and so far I've seen no ill effects. It appears the game copes with it well. Given that, I would expect that loading an older save and resaving it should make it good to go, and then in-game you can go into the Esc menu, settings, Difficulty, and tweak the new options to your liking, to then continue the save. Just keep in mind that some settings can have very intended adverse effects if you enable them: probes could lose control, or parts in deep sea/Eve's atmosphere may explode from pressure, etc etc. Nothing a reload of the previous save can't resolve though.

The kerbal CommNet works on vibration rather than electromagnetism, first invented by one of the female ancestors of Valentina, when she discovered 'tapping the foot' was a very efficient way of communicating her displeasure with any of the males within local range. The 'antennae' on kerbal space craft are actually rail guns (explains the ridiculously high EC discharge they require, as well as range being an issue) that fire quantum-scaled pellets at any empty surface area on the home planet, from where the vibrationally coded message is received by highly tuned seismic sensors. The pellets are made of captured gravioli, charged super-massive particles that are several orders of magnitude smaller than other elemental particles, thus suffering almost no interaction with the atmosphere up until hitting the super-dense water or rock of the home planet. So you see, the lines are a pretty accurate representation of how kerbals use the home planet to transmit communications. All a matter (heh) of physics, really.

The Kerbal Game Simulator Kerbals Go Boom seems fitting in this collection.

On the website itself, go to the craft page, click Edit Craft at the top, then again at the top click on the small version of the thumbnail, and it will offer you the option to replace it with one of the other pics you uploaded - including any individual pics from imgur albums.