St4rdust

KSP Loading... Preview: Grip Pads

Recommended Posts

Posted (edited)
34 minutes ago, steve_v said:

I know, I know, and I don't disagree. I've just been watching KSP accumulate quick not-really-fixes for a long time, and they never seem to get sorted out properly, just plastered over with more quick-fixes and buried under a mountain of "shiny new stuff" hype.
I'm not claiming to know better than anyone, and I sure don't know how to fix this stuff myself or I would have done so already. It's just frustrating the number of years I've been waiting and hoping for this game to loose it's early-access jank and stop shipping new bugs with every release.

Yeah I know the feel.

Though I'm quite sure I have a rough idea of how to fix it from the code PoV and a good idea of how to fix it from the UX PoV (or at least I sat in a uni room and listened to someone talk about UX for several years).
The odds of things changing are incredibly slim sadly. Especially so because there is no incentive to give us something for free. Something which becomes even more obvious when you consider the 'fix' of actually using a proper PhysicMaterial is what they sold us with the grippy pad.

Maybe I'm being overly cynical though and Squad will do a polish-run over base KSP for 1.8. We'll see.

Edited by Jognt

Share this post


Link to post
Share on other sites
Posted (edited)
36 minutes ago, steve_v said:

stop shipping new bugs with every release.

A bugless release is a near impossibility for any software product.  There are entire YouTube channels devoted to finding and exploiting bugs and glitches in AAA titles by top tier studios.  I'm not saying we haven't seen some slipshod shenanigans in the past, I'm just saying don't set the bar too high on your expectations, there.

Edited by MaxPeck

Share this post


Link to post
Share on other sites
23 minutes ago, Jognt said:

Maybe I'm being overly cynical though and Squad will do a polish-run over base KSP for 1.8. We'll see.

I'm definitely being cynical, but I'm not convinced on the "overly". If history is any guide 1.8 will be more part revamps, fixes for the DLC, or more DLC. I'd love to be proven wrong, but it's not-happened time and time again.
 

Just now, MaxPeck said:

I'm just saying don't set the bar too high on your expectations

I'm not asking for a bug-free game (though I can think of a good number of software products that are effectively bug-free), I'm asking that regressions get fixed before release, and if they can't be for some reason, at least not left to rot for years under a pile of DLC hype.
My expectation isn't perfection, it's "Don't break existing systems, and if by some unavoidable scenario you do, please make fixing them a priority. If an old bug in a core system has been annoying players for years, deal with it before introducing more stuff."

Input devices on GNU/Linux haven't worked at all since 1.4:  Regression, unfixed.
The brokenness of wheels has been a thing since 1.1: Regression, unfixed.
Surface bases have been sliding around, or sinking into terrain, or jumping off the ground forever: Longstanding oft complained about bugs, still not properly fixed.
Need I continue? I have plenty more...

Share this post


Link to post
Share on other sites
38 minutes ago, MaxPeck said:

A bugless release is a near impossibility for any software product.  There are entire YouTube channels devoted to finding and exploiting bugs and glitches in AAA titles by top tier studios.  I'm not saying we haven't seen some slipshod shenanigans in the past, I'm just saying don't set the bar too high on your expectations, there.

You are right of course. 

But (yes, there’s a but ;)), some of these problems are very low hanging fruit. 

Let me turn it around: The new BG grip pads use custom set PhysicMaterial settings. That’s 2-4 numbers (bounciness, grip while moving, grip while stopped) and 2 variables (whether to add, average, or use the min/max value between two objects that touch). 

This has been in the code for quite a while but was just never given a custom value for parts. 

How cynical would you become when you learn that you can get a part with these few lines added to their CFG for x dollars when the wheels and landing legs already in the game would function much better with the same few extra lines?

Remember: the underlying ‘module’ code is standard Unity engine stuff. It’s in the stock game where it gives every part the same value. The only thing between proper legs/wheels and you, are those few CFG lines. 

It makes me very cynical :/

Since Squad has access to the models themselves, they could even just select the ‘feet’ on the legs and give those a custom physicmaterial.

Is it asking for perfection to want them to do this for the parts they already sold us?

Share this post


Link to post
Share on other sites

Don't forget that increasing the grip of the landing legs would also mean increasing the chance of tipping over if you attempt to land without perfectly cancelling all your horizontal velocity first. 

These things almost always involve trade offs between realistic physics, fun gameplay (different people will have different expectations here), performance (simulating physics in one millisecond timesteps would probably improve realism even without other other changes, but would probably be much too cpu intensive for more than a tiny part count rocket/lander) and developer time.

Share this post


Link to post
Share on other sites
Posted (edited)
10 hours ago, AVaughan said:

Don't forget that increasing the grip of the landing legs would also mean increasing the chance of tipping over if you attempt to land without perfectly cancelling all your horizontal velocity first. 

These things almost always involve trade offs between realistic physics, fun gameplay (different people will have different expectations here), performance (simulating physics in one millisecond timesteps would probably improve realism even without other other changes, but would probably be much too cpu intensive for more than a tiny part count rocket/lander) and developer time.

 

This is false. The PhysicMaterial module specifically has two values for friction: Dynamic and Static. 

The Dynamic value determines grip while moving. 

The Static value determines grip while stationary. 

This makes it quite easy to keep the dynamic value at its default 0,4 but increase the Static value to something like 0,8. 

And presto. Once stopped, it’s a LOT less likely to slide. But while moving, it’s not going to tip over because a leg slightly touched the surface. 

Again: the code already exists. It’s literally just the values for the part CFG that are missing custom values. (Which means they all get the default 0,4 value.)

Here’s the API docs from KSP itself: https://www.kerbalspaceprogram.com/api/class_physic_material_definition.html

Its not a difficult compromise or hard to code. It’s right there. 

Edit: and here’s the official Unity documentation about what the PhysicMaterial class is for: https://docs.unity3d.com/Manual/class-PhysicMaterial.html

Edit2: the only thing preventing me from releasing a mod that fixes the stock landing legs friction is legal access to the model to tick the PhysicMaterial box for the ‘feet’. 

Do you still think it’s a matter of ‘too complex to solve in a game’?

Edited by Jognt

Share this post


Link to post
Share on other sites
7 minutes ago, Jognt said:

Its not a difficult compromise or hard to code. It’s right there.

Is it also easy to Module Manager config in? Or is it not in the part config?

Share this post


Link to post
Share on other sites
Posted (edited)
18 minutes ago, 5thHorseman said:

Is it also easy to Module Manager config in? Or is it not in the part config?

It should be easy to MM patch. Just check the Breaking Ground grip pads. 

Doing it this way applies it to the whole part though which isn’t a problem for small dedicated parts like those pads.

In order to give a specific part of a model a different grippiness ( like the feet on landing legs) you have to select the ‘feet’ and add it during import into unity afaik. So only Squad can (legally) do/distribute that. 

Edited by Jognt

Share this post


Link to post
Share on other sites
12 minutes ago, Jognt said:

Doing it this way applies it to the whole part though which isn’t a problem for small dedicated parts like those pads.

I don't really see an issue with the entire landing leg having high friction. If they're touching the ground it doesn't really matter if I'm sliding or not :)

Sadly, I looked in both landing leg and grip pad configs, and don't see anything related to friction. Drag? Yes. Friction? No. :/

Share this post


Link to post
Share on other sites
Posted (edited)
3 minutes ago, 5thHorseman said:

I don't really see an issue with the entire landing leg having high friction. If they're touching the ground it doesn't really matter if I'm sliding or not :)

Fair enough. If you give it a try, could you let me know the results?

I’m strangely hoping it doesn’t work this easily. Because it’d mean cynical me was wrong and I prefer being wrong over losing hope in humanity :(.

edit: if you’re running Kopernicus... You could give all planets a PhysicMaterial Static friction of 1. Any kerbal left on there would be stuck like a fly on .. fly tape. 

Or turn the moon into an ice skating ring. (Oh wait, that’s almost just the default setting)

Edited by Jognt

Share this post


Link to post
Share on other sites
1 hour ago, Jognt said:

The Dynamic value determines grip while moving. 

The Static value determines grip while stationary. 

So in that case, depending on how slow something needs to be moving before Unity/PhysX decides it is stationary, dynamic friction might not apply to cases where something lands on a slope and spends the next 20 minutes sliding to the bottom at 0.2 m/s.  

Share this post


Link to post
Share on other sites
11 minutes ago, AVaughan said:

So in that case, depending on how slow something needs to be moving before Unity/PhysX decides it is stationary, dynamic friction might not apply to cases where something lands on a slope and spends the next 20 minutes sliding to the bottom at 0.2 m/s.  

Don't forget: The surface of the planet you're on also has it's own PhysicMaterial.

How PhysicMaterials interact is also tweakable by a built-in setting. You can choose whether to average the values of the two contacting materials, add them up, use the highest number, or use the lowest number.

Here's the Unity description of Dynamic Friction:

Quote

A value of zero feels like ice, a value of 1 will make it come to rest very quickly unless a lot of force or gravity pushes the object.
- https://docs.unity3d.com/Manual/class-PhysicMaterial.html

So if something keeps moving to the point where Static Friction isn't applied, it's because the Dynamic Friction is set too low, or the method of combining them isn't right for the situation.

If you want to know why stuff in KSP likes sliding and why I'm so sure this can be remedied:

  • The default value KSP gives to PhysicMaterial (before Breaking Ground) is 0,4.
  • The method of combining them is PhysicMaterial.average

This means that you can make a surface look as rough as you want, and you can land the roughest looking lander on it. But internally they will always have a Friction coefficient of 0,4.... On a scale of 0 - 1....

Contrary to the subject of the game: It's not rocket science.

Share this post


Link to post
Share on other sites
Posted (edited)
10 hours ago, 5thHorseman said:

I don't really see an issue with the entire landing leg having high friction. If they're touching the ground it doesn't really matter if I'm sliding or not :)

Sadly, I looked in both landing leg and grip pad configs, and don't see anything related to friction. Drag? Yes. Friction? No. :/

Huh.. Was that 2nd line there initially? *scratches head*

This is the bit in the lGripPad.cfg that sets the PhysicMaterial for the grip pad:

MODULE
{
	name = ModulePhysicMaterial
	activePhysicMaterialName = MediumGrip
	PhysicMaterialName = MediumGrip
	PhysicMaterialName = HighGrip
	PhysicMaterialName = ExtremeGrip
	PHYSICMATERIALCOLORS
	{
		MATERIALCOLOR
		{
			name = MediumGrip
			color = 1,1,1
		}
		MATERIALCOLOR
		{
			name = HighGrip
			color = 0.63,0.63,0.63
		}
		MATERIALCOLOR
		{
			name = ExtremeGrip
			color = 0.38,0.38,0.38
		}
	}
}


Those PhysicMaterialName properties refer to the PhysicMaterial definitions in GameData\SquadExpansion\Serenity\Resources\PhysicsMaterials.cfg
Which look like this:

PHYSICMATERIAL_DEFINITION
{
  name = LowGrip
  displayName = #autoLOC_6011086 //Low Grip
  dynamicFriction = 0.1
  staticFriction = 0.1
  bounciness = 0
  frictionCombine = Maximum
  bounceCombine = Average
}


I've done some basic testing and this simple MM patch adds PhysicMaterial settings to the small landing legs (or rather, a cloned version of it)

+PART[miniLandingLeg]
{
	@name = miniLandingLegTest
	@title ^= :$: - Testing:
	@MODULE[ModuleWheelSuspension]
	{
		%autoSpringDamper = false
		%damperTweakable = 1.5
		%springTweakable = 3
	}
	MODULE
	{
		name = ModulePhysicMaterial
		activePhysicMaterialName = ExtremeGrip
		PhysicMaterialName = ExtremeGrip
		PhysicMaterialName = Default
		PHYSICMATERIALCOLORS
		{
			MATERIALCOLOR
			{
				name = ExtremeGrip
				color = 1,1,1
			}
			MATERIALCOLOR
			{
				name = Default
				color = 0.63,0.63,0.63
			}
		}
	}
}


You can ignore the ModuleWheelSuspension bit, that's just to set defaults to ease testing (placing and removing many legs and not having to manually tweak them all <3).

In my quick tests just now my rocket-propelled-rover-with-folded-legs-for-skids reached a staggering 6m/s on the stock legs, but didn't get much over 0.1m/s with the cloned+tweaked legs.
I added the Breaking Ground-added 'Default" material to the leg as well so I could confirm whether those are indeed the default settings (even when PhysicMaterial isn't explicitly defined) and for some strange reason that setting was equally grippy as the Breaking Ground-added ExtremeGrip setting..

So adding PhysicMaterial to existing parts is indeed a CFG tweak away from being a thing, but I think there is another  step to it. Maybe with regards to opening the model in Unity, but since I’m not a modeler, I can’t confirm that  

Squad however has the original models (and the legal rights to them) so making the legs (or even just the feet of the legs) grippy-er should be rather easy for them.

Squad. Pretty please with a cherry on top, polish these parts even though you're not getting new money for them? Please? Gesture of good will and such? Or is Take Two standing behind you so you don't spend time on not-making-money? Blink twice if so.

Edited by Jognt

Share this post


Link to post
Share on other sites
On 7/27/2019 at 11:45 AM, steve_v said:

I know, I know, and I don't disagree. I've just been watching KSP accumulate quick not-really-fixes for a long time, and they never seem to get sorted out properly, just plastered over with more quick-fixes and buried under a mountain of "shiny new stuff" hype.
I'm not claiming to know better than anyone, and I sure don't know how to fix this stuff myself or I would have done so already. It's just frustrating the number of years I've been waiting and hoping for this game to loose it's early-access jank and stop shipping new bugs with every release.

Are you aware that any technical history of computer game advancements could also be called 'Clever tricks to allow a potato to do things in real-time that can't be done properly by a super-computer at 1/10 speed'

Like all game engines, Unity does not do 'Real' Physics, it does a mish-mash of workarounds and clever tricks that generally look like physics within given constraints.

If I remember correctly, on this forum it was discussed how wheels are a special class of object that allows interaction between the current vehicle and the ground to do things like apply acceleration or suspension forces, as such, landing legs had to be classified as a unity 'wheel' to function properly.  Also, the 'functional' part of a wheel, is a small square between the axis of the wheel and the body surface(This is probably a big part of the 'goes crazy when other parts of the wheel/leg touch a kerbal or another vessel' bug), but the 'proper' fix for this requires checking every vertex of every component of every object in the current bounding-box against every part of every other vessel in the same bounding box.  This includes every vertex of the body you are on as well.  This is an O(n^2) operation for every *vertex* in physics range.  Yes, this would give much more realistic interactions between objects, even components of the same vessel, but you will not be docking, or probably even launching any vessels with even 30 parts using a desktop computer.  (it might work if you were to reduce physics range to say, 10 meters, but then you would need a new 'dirty hack' to have any vessel more than 10m long)

 

You know in one of the first first-person-shooter games there was an enemy with a mirrored surface?  They tried for months to figure out a fast way to ray-trace for the mirrored surface, but it was always too slow, then some guy came in and 'fixed' it by just grabbing the colors from a random part of the screen and poof! you have your mirror-monster. 

Would that work for letting the character look at themselves in a mirror?  no.  Does it work for making a monster look like it has a mirrored surface?  Generally yes, and that is all they needed it for.

 

The problem with KSP is that it pushes the bounds of what Unity(and games in general) have done, so it runs into all of these corner cases that no one has ever bothered to properly look at in the past because they were either not needed, or easy to work around/prevent.

Sure a more experienced game producer might know more about those corner cases and be better able to address them(looks at Star Theory), but SQUAD did not start from a point of having that experience, and so they have been bit by that lack of knowledge, and there may well be parts of KSP 1 that just can't be fixed without re-writing the whole thing from scratch(looks at KSP2).

 

Incidentally, I would not be surprised if the 'simple friction fix' mentioned above causes some other unexpected behavior that may or may not be worse than the issue it is trying to fix.

 

 

Share this post


Link to post
Share on other sites
On 10/18/2019 at 8:30 AM, Terwin said:

Are you aware that any technical history of computer game advancements could also be called 'Clever tricks to allow a potato to do things in real-time that can't be done properly by a super-computer at 1/10 speed'

Like all game engines, Unity does not do 'Real' Physics, it does a mish-mash of workarounds and clever tricks that generally look like physics within given constraints.

Sure, and the "clever tricks" to allow wheels on a craft pre-1.1 had suspension simulation that worked well enough to build and land an aeroplane without bouncing around like a pogo stick. The new system fails this simple test regularly, and has done since it's introduction.

 

On 10/18/2019 at 8:30 AM, Terwin said:

If I remember correctly, on this forum it was discussed how wheels are a special class of object that allows interaction between the current vehicle and the ground to do things like apply acceleration or suspension forces, as such, landing legs had to be classified as a unity 'wheel' to function properly.  Also, the 'functional' part of a wheel, is a small square between the axis of the wheel and the body surface(This is probably a big part of the 'goes crazy when other parts of the wheel/leg touch a kerbal or another vessel' bug), but the 'proper' fix for this requires checking every vertex of every component of every object in the current bounding-box against every part of every other vessel in the same bounding box.

Okay, riddle my why the U4 wheelcollider didn't behave like a catapult, bounce around all over the place for no apparent reason, or freak out on touching another part? It had it's own problems for sure, but "will wheels work properly this release roulette" wasn't one of them. It didn't do excessively expensive collision-detection either.

One of the primary uses of landing gear and wheels in this game is, strangely enough, landing. Landing (or touching another part) involves sudden changes in suspension loading, something which the current wheel implementation has been utterly unable to deal with gracefully or consistently since day one.
It's complicated and brittle, it's trying to adapt spring force to every situation, and it's failing in strange and infuriating ways on a regular basis. How about we go back to wheels that work reasonably well within sane load limits and break when exceeding them instead of this auto-adjusting nightmare?

 

On 10/18/2019 at 8:30 AM, Terwin said:

You know in one of the first first-person-shooter games there was an enemy with a mirrored surface?  They tried for months to figure out a fast way to ray-trace for the mirrored surface, but it was always too slow, then some guy came in and 'fixed' it by just grabbing the colors from a random part of the screen and poof! you have your mirror-monster. 

Would that work for letting the character look at themselves in a mirror?  no.  Does it work for making a monster look like it has a mirrored surface?  Generally yes, and that is all they needed it for.

For reference, we had (faked of course) mirrored surfaces in 1996, character looking at themselves included.

 

On 10/18/2019 at 8:30 AM, Terwin said:

The problem with KSP is that it pushes the bounds of what Unity(and games in general) have done, so it runs into all of these corner cases that no one has ever bothered to properly look at in the past because they were either not needed, or easy to work around/prevent.

Sure, and Unity bugs and limitations are the root cause of pretty much every bug or janky system I have ever complained about. Blaming the game engine, whether deserved or not, does not fix the problems.
Insisting on working within the limitations of unity's wheelcollider has given us awful wheel physics for years. KSPWheel fixes the most annoying "corner cases", so if modders can do it, why won't Squad?

People have been complaining about Unity's wheel system forever, and several alternative implementations have been developed. What's stopping Squad from doing the same?
I'm not asking for perfect physics simulation here, that's patently unrealistic. But can't we at least have predictable suspension behaviour?

 

On 10/18/2019 at 8:30 AM, Terwin said:

there may well be parts of KSP 1 that just can't be fixed without re-writing the whole thing from scratch(looks at KSP2).

Indeed. I expect this is why some of the problems with the game haven't been fixed.  Not so much for others... (Looks at joystick support).

 

Share this post


Link to post
Share on other sites
4 minutes ago, steve_v said:

Looks at joystick support

How's that working?

Quote

=================================== v1.8.0============================================================
1.8.0 Changelog - BaseGame ONLY (see below for MH and BG changelog)
...
+++ Bugfixes
...
* Joysticks and gamepads on Linux are again recognized and usable.
...

 

 

Share this post


Link to post
Share on other sites
11 minutes ago, razark said:

How's that working?

Waiting for the standard major-release-day bugs and hotfixes, as usual. I'll try it out once the release is release-worthy.

Comment on input stack borkage not being fixable without rewriting the game stands though, Squad didn't fix this, it came along with the Unity update.
Comment elsewhere on waiting for unity to fix it not being quicker than an in-house solution also still stands, Unity update or no, this regression went unfixed for a ridiculous amount of time.

Edited by steve_v

Share this post


Link to post
Share on other sites
50 minutes ago, steve_v said:

Sure, and the "clever tricks" to allow wheels on a craft pre-1.1 had suspension simulation that worked well enough to build and land an aeroplane without bouncing around like a pogo stick.

So the question is, what did the changes to 1.1 fix that also broke this, and was that fix better or worse than the landing gear?

I don't know the answer to that. I doubt anybody does except maybe the programmer who was involved and maybe not even them. And they probably don't even work for Squad or Unity anymore.

Share this post


Link to post
Share on other sites
On 6/26/2019 at 5:15 PM, Brikoleur said:

YES!

This just keeps getting better and better. It looks like Breaking Ground didn't just unleash some mad kerbal energy among us players...!

(Now how about wheels we could mount on rotors? Pretty please...?)

I'm currently attempting to create a cylindrical grip pad to attach to rotors as a wheel. simple structural part with high impact tolerance and a fraction of the grip properties from the pad parts. Trying to make sense of the cfg files for the grip pads at the moment.

Share this post


Link to post
Share on other sites
20 hours ago, Dundrogen said:

I'm currently attempting to create a cylindrical grip pad to attach to rotors as a wheel. simple structural part with high impact tolerance and a fraction of the grip properties from the pad parts. Trying to make sense of the cfg files for the grip pads at the moment.


Grip pads can already be set to have a circular shape; I've used them as rover wheels in just this way! Over here. They are a little less than ideal as wheels, so good luck!

 

Share this post


Link to post
Share on other sites
3 hours ago, BigFatStupidHead said:


Grip pads can already be set to have a circular shape; I've used them as rover wheels in just this way! Over here. They are a little less than ideal as wheels, so good luck!

 

i see. unfortunately that setup would face the same problem i did. the problem is that there are no actually round shapes. even those round looking grip pads placed sideways probably have 12 sided collider mesh and you can see the problem with a 12 sided wheel lol. Alas, my yearning for a simple wheel persists. I wonder if i import a custom asset with a perfectly round collider, would the unity engine just explode my cpu?

Share this post


Link to post
Share on other sites
5 hours ago, Dundrogen said:

i see. unfortunately that setup would face the same problem i did. the problem is that there are no actually round shapes. even those round looking grip pads placed sideways probably have 12 sided collider mesh and you can see the problem with a 12 sided wheel lol. Alas, my yearning for a simple wheel persists. I wonder if i import a custom asset with a perfectly round collider, would the unity engine just explode my cpu?

I would love to see the result. Go for it!

Share this post


Link to post
Share on other sites
On 10/17/2019 at 12:30 PM, Terwin said:

Would that work for letting the character look at themselves in a mirror? 

 

On 10/18/2019 at 5:50 PM, steve_v said:

For reference, we had (faked of course) mirrored surfaces in 1996, character looking at themselves included.

This reminds me of playing Soldier of Fortune 2. There was a custom (player-made?) map of a swimming pool (which had as a soundtrack the classic "Splish-Splash, I was taking a bath"), and there was a mirror in the changeroom. If you pulled out the .44 Magnum for your weapon, the reflection raised its hands in surrender! I LOLed and LOLed...

On 10/18/2019 at 6:42 PM, 5thHorseman said:

So the question is, what did the changes to 1.1 fix that also broke this

It was a major Unity version upgrade, that required rewriting pretty much the entire code base...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.