Kraken slay idea.

[Jeq]

If you add variable for total momentum force of vessel, each moving part increases that force, game math could use that to detect if vessels momentum is growing for now reason (impacts or player inputs) and then game could actually damper those forces to their origin states. Even impacts and player inputs game could calculate how much new momentum force should be and correct and dampen anything abnormal activity. Just one variable.

[gluckez]

that sounds a lot like a hack that would hide the underlying issue instead of actually solving the problem, and it would make it even more difficult to track the problem down and potentially raise more bugs if not implemented perfectly. it's also not just one variable, it's a system that needs to know exactly what is happening to a vessel, or a collection of game objects at any given time, measure it's momentum and apply a force in the opposite direction, unless the change in momentum is caused by a scenario that is either directly started by the player, or a consequence of interaction between 2 or more objects. So there's a lot of hidden variables. I like the active thinking and the willingness to cooperate with the devs though, good work!

[Barrackar]

This is going to reveal how much of a major math nerd I am, but....

Balancing momentum is one of the techniques sometimes used when conducting numerical approximations in N-body simulations. For example, a variable time step is attempted and calculating the momentum of the system is then used as a sort-of checksum to determine whether a time-step of that size introduces significant errors or not. If there is a determined change in momentum for the simulated system above a threshold then the simulation tosses out the results and tries a time-step of half the size. Usually also done in combination with combining objects which are very close together into binary systems which would otherwise require very small time steps to simulate.

On that note, N-body simulation and KSP have very different requirements. KSP physics simulation must be guaranteed to be completed within very small periods of time. It cannot at any point pause while the calculations catch-up. N-body simulation is almost the opposite where it is most important to make sure the simulation is accurate within some threshold level of accuracy. Many of the physics calculations done for N-body numerical simulation cannot be used in KSP.

So what does all this mean for your suggestion? First, momentum calculations are plausible, but it is never as simple as just saying momentum should be calculated. Second, I'm not sure KSP doesn't already do momentum calculations at some level of approximation. I don't often encounter situations which defy the laws of physics in KSP unless somebody has intentionally set out to break them. Is there some situation you have seen which would behave differently if conservation of momentum were more explicitly enforced? Third, vehicles are not single rigid objects but composed of dozens of parts. Accordingly, calculating momentum is not a single variable but composed of 6 degrees of freedom for every part (and additional calculations for reaction engines). Even if you determine the total momentum is off,  figuring out which part is to blame for the error and would need to be dampened would not be easy. Incorrect dampening may itself create abnormal momentum or oscillations.

[Bej Kerman]

On 9/18/2023 at 5:08 PM, Jeq said:

If you add variable for total momentum force of vessel, each moving part increases that force, game math could use that to detect if vessels momentum is growing for now reason (impacts or player inputs) and then game could actually damper those forces to their origin states. Even impacts and player inputs game could calculate how much new momentum force should be and correct and dampen anything abnormal activity. Just one variable.

To a computer, there is no fundamental difference between a vessel collision calculation and a calculation in an otherwise fine situation that's gone awry. A Kraken attack is simply impossible to detect - the game just sees the vessel doing a thing.

[Jeq]

On 9/19/2023 at 11:30 AM, gluckez said:

that sounds a lot like a hack that would hide the underlying issue instead of actually solving the problem, and it would make it even more difficult to track the problem down and potentially raise more bugs if not implemented perfectly. it's also not just one variable, it's a system that needs to know exactly what is happening to a vessel, or a collection of game objects at any given time, measure it's momentum and apply a force in the opposite direction, unless the change in momentum is caused by a scenario that is either directly started by the player, or a consequence of interaction between 2 or more objects. So there's a lot of hidden variables. I like the active thinking and the willingness to cooperate with the devs though, good work!

I believe kraken is bug in unity physics and before unity does something to it, developers has to find temporary solutions

 

[gluckez]

1 hour ago, Jeq said:

I believe kraken is bug in unity physics and before unity does something to it

I don't think it's that simple. I think it's related to floating point rounding errors, and overlaps between colliders caused by those errors per physics timestep. those colliders would need to be pushed apart, which causes other colliders to also need to be pushed apart again. It's easy to attribute it to unity itself, but I think the issue is related more closely to the nature of floating point calculations by computers in general.

[Barrackar]

9 hours ago, gluckez said:

I don't think it's that simple. I think it's related to floating point rounding errors, and overlaps between colliders caused by those errors per physics timestep. those colliders would need to be pushed apart, which causes other colliders to also need to be pushed apart again. It's easy to attribute it to unity itself, but I think the issue is related more closely to the nature of floating point calculations by computers in general.

As I understand it, floating point rounding is part of the issue, but not the whole picture. So-called Kraken attacks where a craft vibrates and breaks apart has more than one cause.

(1) Colliders are certainly involved when loading a vessel and it miscalculates collisions while landed or when adjacent an asteroid or other colidable object. This kind of kraken attack is characterized by occurring at physics loading in KSP1 and visually looks like some part spontaneously exploded. I don't know of any way to avoid these types of kraken attacks except reload a save and try again.

(2) There is another kind of kraken attack associated with SAS oscillations. Most often affecting large stations with things docked to it. SAS oscillations occur because torque is applied to reaction wheel parts, but there is a lag time until the orientation of the "control from here" part's orientation is changed. When there is a joint between the "control from here" part and another large mass the inertia of the mass can overcorrect the SAS adjustment causing ever increasing wobbling until something breaks. These types of kraken attacks can be prevented by turning off SAS and using time-warp to freeze everything in place. Notably, these kinds of oscillations can occur without any floating point rounding effects - but a floating point rounding effect could be the tiny push which starts the first oscillation.

(3) There are probably other causes of kraken attacks as well.

 

[gluckez]

5 hours ago, Barrackar said:

(2) There is another kind of kraken attack associated with SAS oscillations.

you're right, but I think this one is more of a bug than an actual kraken attack. the kraken attack is probably a result of several forces being applied simultaneously because of SAS and reaction wheels. So I believe these are seperate issues, but that this one can cause a kraken attack.
either way, there's an important distinction that needs to be made between what causes the kraken attack, and the nature of the kraken itself. I think the nature of the kraken is those floating point rounding errors, but the cause can be anything from overlapping colliders, misaligned forces, etc. I'm pretty sure the dev team already knows better than I do how it works, but that it's also a complicated issue to crack.

[Jeq]

On 9/20/2023 at 10:04 AM, Bej Kerman said:

To a computer, there is no fundamental difference between a vessel collision calculation and a calculation in an otherwise fine situation that's gone awry. A Kraken attack is simply impossible to detect - the game just sees the vessel doing a thing.

If human can detect it, it can be mathematically solved for computer to detect it. There is allways a solution. Even KSP log shows whenever something did collide to surface/other vessel.

Edited September 27, 2023 by Jeq

[Bej Kerman]

13 hours ago, Jeq said:

If human can detect it, it can be mathematically solved for computer to detect it.

Practically untrue.

[DancZer]

20 hours ago, Jeq said:

If human can detect it, it can be mathematically solved for computer to detect it. There is allways a solution. Even KSP log shows whenever something did collide to surface/other vessel.

Yes you are right. One solution for that to have an AI which is trained by reinforced learning, so it learn the essence of gameplay a can detect a kraken. Otherwise you can't.

[Jeq]

On 9/28/2023 at 5:22 PM, DancZer said:

Yes you are right. One solution for that to have an AI which is trained by reinforced learning, so it learn the essence of gameplay a can detect a kraken. Otherwise you can't.

I was actually thinking this too at work today. AI could help with number crunching but its human task to make correct formula.

 

On 9/25/2023 at 7:56 PM, gluckez said:

I don't think it's that simple. I think it's related to floating point rounding errors, and overlaps between colliders caused by those errors per physics timestep. those colliders would need to be pushed apart, which causes other colliders to also need to be pushed apart again. It's easy to attribute it to unity itself, but I think the issue is related more closely to the nature of floating point calculations by computers in general.

You might be right. But i remember one bug at KSP which i found using KOS mod which revealed that any vessel were rattling small amount of xyz position, it was almost impossible to see but it caused vessels move at surface for no reason. I reported my founding to KSP developers and they found a way to dampen floating errors, today vessels stay mostly still if they are at even surface, some kraken still exists especially with those long thick metal poles. This same rattling may happen at KSP 2 too if it uses same coordination system as KSP.

[Jeq]

Based on my 4k time in kerbal, SAS kraken is happening mainly because of SAS gimbals engines so violently. Engines gimbals are very unrealistic fast from one point to another. Even upper stage engines, which doesn't have yet decoupled to use, are gimbaling inside vessel. You can get almost all kraken problems of space stations away if you turn off engine gimbals. Gimbal should be more dynamical.

Edited December 7, 2023 by Jeq