south pole problems

[swjr-swis]

5 minutes ago, Wayneo said:

Should also not that building a rover that doubles as a lander in the SPH means the controls are all messed up when flying it, having to point at anti-normal to do a retrograde burn and control radial manually with QE, as apposed to building a rover in VAB where the markers are not needed for driving but you can track retrograde all the way down.

If you want a rover to also be controllable as a lander, you need to add a second probe core (or a docking port, or a lander can) oriented the way a lander needs. During landing, rightclick and 'control from here' on the 'up' core; during driving, do the same with the 'forward' core. Switching between differently oriented control parts is the only way the game offers to flip the orientation of controls, by design.

 

9 minutes ago, Wayneo said:

there is a string of 5 stock Rover+Skycrane rovers

No disrespect meant by snipping the rest of your text, but this here is the key of the issue. Those rovers, stock as they may be, are built wrong for rover use: the OKTO probe core is oriented up instead of forward relative to the wheels (and they may be suffering from the problem I suspect of rovers built in the VAB instead of the SPH).

If the point you are trying to make is that the stock rovers are designed wrong, then we can stop right here because I agree. But don't use them as examples of a correctly designed rover; they are not. Hint: most stock craft in KSP have in fact, on purpose, been built with one or more design flaws. The idea behind this was said to be that the player will learn from correcting those mistakes. Personally, I think that only confuses new players, but I have no say on it.

[Wayneo]

Just tested a lander/rover built in the SPA, to solve the controls being all mess up when flying it you have to build it on its side wheels pointing backwards like the engines instead of at the floor witch means when you land on the wheels using the motors to slow your decent the prob core ends up on its side, witch means its effected buy the south pole problem and its undrivable.

 

What's your subjected fix for a lander/rover so the controls are correct in flight and its able to drive at the south pole?

21 minutes ago, swjr-swis said:

If you want a rover to also be controllable as a lander, you need to add a second probe core (or a docking port, or a lander can) oriented the way a lander needs. During landing, rightclick and 'control from here' on the 'up' core; during driving, do the same with the 'forward' core. Switching between differently oriented control parts is the only way the game offers to flip the orientation of controls, by design.

 

 

I think the problem is your designing things wrong, adding a extra probe core or docking port just add extra dead weight to workarond a problem that did not exist befor, if probe cores work the same in the north as the south like they did in previous game versions then there would not be any problem with a probe core on its side, hence why the stock rover is like that, and allot of people designs are, a core on its side has never been a problem before, have been to south poles with rovers with there probe core on there side numerous times before this version of the game.

[Wayneo]

Duna sstv pyramid near south pole rovers with probe cores on there side driving, try doing that now.

https://www.youtube.com/watch?v=sUf2OiEAkcU

https://www.youtube.com/watch?v=4258Rx-Fj5A

[sal_vager]

Did you know, in KSP down isn't really down, even though it looks like down, unlike most other games where down is down in KSP down is sideways while you're at the KSC.

Gravitationally down of course, in the scene constructed by Unity you're on your side on the side of a ball, or at least that part of it that exists in memory at that time.

And the wheels use the current direction of gravity to know where down is, and your command part to know where the front and bottom of your rover is, and which way you stuck your wheels on, so they can guess which way to go.

This works everywhere, except right at the south poles, where you're upside down and your control point is pointing down and gravity is pulling you up on upside down wheels onto the bottom of a ball that's the other way up to you.

Except down isn't quite up. it's off a tiny bit, and as you drive around down moves a bit under you, it's more accurate in the center of a quad (what planets are made of), and off to the side a bit on the edges, but it's such a small difference you can't see it, except at the KSC where the flat runway acts like a really squashed skateboard half-pipe and you roll to the center.

In other words, the vector of gravity changes, it's a floating point number (actually a bunch of floats together), and sometimes the numbers are wrong, that's normal for floats though, and when you're using floats you don't check for accurate values, you check for a range and if it's in that range it's 'right', or accurate enough to say it's right.

And when on the poles the numbers can be wrong, just wrong enough that your upside down rover doesn't know where forwards is anymore, and you can't drive.

Having your control point facing the horizon can help, so at least it knows where forwards is, and you can always add a front and rear mini docking port so you can select them as your control point (but make sure they are the right way up, which is to say sideways).

Maybe it can be fixed, it's hard to say, Unity wheels aren't designed for the abuse KSP is putting them through, and Vehicle Physics Pro is only designed to make Unity wheels act like wheels instead of like greasy balloons on sticks, neither of which are designed with a constantly changing gravity in mind, or with individual wheels the player can stick on in any direction, or with a control point that could be any way up.

It's not the desired behaviour, it certainly wasn't programmed by Squad developers to forget which way was the front when upside down on a ball, most people would call it a bug.

I think it's doing okay for something that's not supported by Unity or by VPP, not great of course, it could be better, that might take some fundamental changes in how wheels work though, to take into account the things we're doing with them, to properly support stick-on wheels, to support more than 20 wheels without them going crazy, and to not be forced to use gravity to know where down is.

Luckily it's just the south poles, and if your command point is sideways instead of down (even though it looks up) it hardly happens at all.

[swjr-swis]

2 hours ago, Wayneo said:

I think the problem is your designing things wrong, adding a extra probe core or docking port just add extra dead weight to workarond a problem that did not exist befor, if probe cores work the same in the north as the south like they did in previous game versions then there would not be any problem with a probe core on its side, hence why the stock rover is like that, and allot of people designs are, a core on its side has never been a problem before, have been to south poles with rovers with there probe core on there side numerous times before this version of the game.

Wayneo... I don't have a problem with my rovers (*). You are the one posting here with a problem with your rovers. We can argue about how we feel that KSP should work, but that's an entirely different discussion. If you wish to know how to get a rover that works correctly in KSP, see my previous suggestions. I've spent a good number of hours now testing this for your benefit, not mine... my rovers already worked, everywhere, even when doubling as a lander.

Btw: I started with KSP a long time and many versions ago. In my experience, building a rover with its controlling part pointing anywhere but forward has always shown problems with control; this is not new to 1.2.x. If you do a search in this very forum (try 'rover controls core', then go to the last page of results), you'll find people posting about this all the way back to 2013, and getting the same suggestions I am giving you here about the orientation of the probe core. If you won't take my word for it, at least check what others in the forum are and have been saying, from long before 1.2 came out.

Anyway, no hard feelings if you consider my way 'wrong', but I hope you understand I can't keep wasting time on this. We can spend this time much better spent driving around Vall at high speeds - that was fun!

(*: other than wheels still being a bit finicky about friction/traction/springs, but that is much better now than it was in 1.1.x, and not the topic of your thread.)

[Wayneo]

Your rover has control problems when flying, so the workaround you suggested is to stick a second control point on, my rover and squads has control issues when landed in the southern hemisphere, perfectly fine in the northern hemisphere, perfectly fine when flying, a flying design control problem that exist 100% of the time is allot more fatal then a squad gravity problem that exist only on 50% of the ground. A problem that was not present as the evident shows before.

 

Feel free to come up with another straw man argument.

 

 

Dose your design of rover with one control point have control issues when flying, navball markers not correctly orientated: yes/no

 

With your design and only one control point is the only way to fix the navball markers problem to build the rover on its side, then coursing a flat probe core when landed coursing a control problem in the southern hemisphere: yes/no

 

Dose the control issue with a probe core flat happen in the northern hemisphere: yes/no

 

AS demonstrated buy YouTube videos has it previously been possible to control a rover in the southern hemisphere with a flat probe core: yes/no

 

Is adding a second control point a workaround for all these problems: yes/no

 

Is there a difference between how the game is handling a probe core in the northern hemisphere to the southern hemisphere: yes/no

Edited November 7, 2016 by Wayneo

[Wayneo]

Now this is just for anyone from squad that is listening. There are two thing that need to be looked at.

 

1: A flat probe core works in the northern hemisphere so there is no reason it should not work in the southern, there both just a 90 degrees turn for the equator, just in opposite directions. Flat probe cores have previously worked in both the northern and southern hemisphere, this demonstrates that there is a bug in your code. This is a critical fix that is needed. Lots of players are going to be building rovers with flat probe cores and will not work out why its not drivable.

 

2:In the VAB SPH probe cores should have a clear marker showing witch side is up and front. The same as decuples have a red arrow indicating direction, linked to this inflight the pop up menu for a probe core should have a toggle to switch form “up” to “front”, that way the navball level indicator can be pointing up for flight then when landed toggled to pointing at the horizon for driving then toggled back for lift-off. This is not critical but it would be nice.

[sal_vager]

Actually I'm going to have to stop you there, and I'll ask you not to turn this into an argument thread with swjr-swis.

 

8 hours ago, Wayneo said:

Now this is just for anyone from squad that is listening. There are two thing that need to be looked at.

1: A flat probe core works in the northern hemisphere so there is no reason it should not work in the southern, there both just a 90 degrees turn for the equator, just in opposite directions.

The south poles are rather different as I thought I'd explained, as are our wheels in Unity 5 which are very different to those in Unity 4.

 

Quote

Flat probe cores have previously worked in both the northern and southern hemisphere,

See above.

 

Quote

this demonstrates that there is a bug in your code.

Oh don't worry, lots of things do that

 

Quote

This is a critical fix that is needed.

Actually no, I'm sorry you are being inconvenienced by this but this is trivially avoided by using the command part the right way up, making it a craft design issue, I've been testing this as well and my rovers are fine on the south poles.

An example of a critical issue would be one that prevents the game from running, or which breaks large portions of the game, if the VAB didn't open and just caused KSP to crash that would be a critical issue, this issue would be at most a Low, as it is a gameplay issue that can be avoided.

Here, see the bug tracker priority table.

Priority	Description	Example Case
Critical	A large portion of the game is unplayable.	SPH is non-functional.
High	Game Breaking	Game crashes when transitioning SoI
Normal	Game Affecting, but not Game Breaking.	SAS is draining electricCharge incorrectly.
Low	Visual issue that occurs often, or Gameplay issue that can be avoided.	Landing Strip has texture artifacts.
Very Low	A visual issue that appears rarely and doesn’t affect gameplay.	Audio-related error appears in log on occasion.
Unworthy	An issue that is slightly bothersome, occurs rarely, is not easily discovered, or is a matter of preference.	Collision mesh of some parts are slightly off.

Quote

Lots of players are going to be building rovers with flat probe cores and will not work out why its not drivable.

They are perfectly drivable everywhere else on 15 bodies (except maybe the water or on very steep inclines), and luckily we're here to help them when they get stuck.

 

Quote

 

2:In the VAB SPH probe cores should have a clear marker showing witch side is up and front. The same as decuples have a red arrow indicating direction, linked to this inflight the pop up menu for a probe core should have a toggle to switch form “up” to “front”, that way the navball level indicator can be pointing up for flight then when landed toggled to pointing at the horizon for driving then toggled back for lift-off. This is not critical but it would be nice.

Yes it would be nice, feel free to suggest that in the Suggestions forum.

 

And again, arguing with other members isn't going to prove your point, and can result in you falling foul of the forum rules, so I suggest you post with a little more decorum, thank you.

 

[Wayneo]

Your correct this is a Low priority issued that can be avoided buy paying other companies to play there games instead.