Colliders randomly stops working

I managed to repro once, finally! First video available below



Summary of what I've got:

• TEST 1: Only static colliders, never disabling anything in the scene: bug never happened after 4h running x18 instances of the standalone build
• TEST 2: Half the ground colliders have kinematic rigidbody attached. I disable all the ground GameObjects at start, then re-enabling them after 1s, then only do I spawn the player: It happened once after 10 mins, only on 1 instance out of 18 running in parallel (!)

I'm going to add more debug to know if the failed box collider had a kinematic RB attached or not (might be valuable info).

I'm not sure yet if the fact that disabling GO at start in TEST 2, then re-enabling provoked it to happen, or if it's only the addition of kinematic RBs that increased the chances of occurring (also added in TEST 2), or if it's just luck and could happen with TEST 1 version as well...

I can confirm it's this bug, because:

• When the issue occurs, I can take over control of the character with gravity disabled
• Then I re-activate gravity to try and walk through it again
• And I do indeed go through the floor

Here's the (unlisted) video for the curious (I'm disabling gravity to get back up, then re-enabling before walking on the problematic ground):

I'll continue investigating this to see if I can get it to happen more often before trying this then in the alpha release.

I will maybe change it to teleport above every single ground instead of moving, as if movement has no impact, then maybe it would be faster and then force reload scene when all grounds have been successfully collided with (as maybe reloading the scene makes a new "reroll" of the chances of it occuring).

Thanks,
Charles

 

Hi all,

OK, after more in-depth investigation and improving my repro project, I can confirm I have a repro case, and could rule out some stuff.

First, generally, the following changes were applied to all tests below compared to TEST 1 and TEST 2:

• Replaced Character Controller random movement, to use only linear movement forward, to check all ground colliders, then switching to next line (to the right) when the full line has been "walked on successfully". This ensures checking every single ground VS previously random movement.
• Disable then Re-Enable all ground GameObjects in between each "line" changing
• Increased timescale to 5
• When all lines were walked on successfully (30 lines), scene is reloaded to try again

________________________________

TEST 3:
- Added Kinematic Rigidbodies to all grounds

In TEST 3, it happens way more often than previous TEST 1 and TEST 2: under 10 mins, 10 of 20 sessions now fail! Versus a couple of hours in my previous tests (probably due to covering more different colliders and higher timescale).

________________________________

TEST 4:
- Removed Kinematic Rigidbodies on all grounds (only Box Collider present)
- Removed the functionality to disable / enable grounds between lines and at start

In TEST 4, it still happens as often as TEST 3, though it did take longer. But that does rule out the Rigidbody presence (doesn't seem to increase chances), and it also rules out the fact that disabling/enabling the objects could increase chances of happening:



Summary:

• Rigidbody presence doesn't seem to impact the bug
• Disabling/enable the GO doesn't seem to impact the bug

_________________________________

Additional info:
- Some fail on very first session (no scene reload), others fail only after checking all grounds 5 times (session 5): It seems like scene reload doesn't impact this bug

Now, I think I can repro enough to test in the fixed alpha, and I'll let you know how it goes. If it still occurs, I will report a full bug report with the project to finally provide you with a simple repro project (which will still require you most likely to launch it multiple times like I do to really see it).

Thank you,
Charles

 

Oops,

Unfortunately, 2021.2.0a10 isn't available yet, it seems, only up to 9, so I'll wait a couple days.

Cheers,
Charles

 

Hi again @yant, in case you want to give it a shot in 2021.2.0a10 before I can, here's the case number for the repro project I have just uploaded: 1322724

There are additional instructions to confirm the bug when it happens. You'll need to run x12 instances at least to avoid waiting too long for it to occur.

I'm excited! Can't wait to know if it is fixed And if it can eventually be backported to have it earlier than 2021.2, into a stable Tech or LTS release, that would make us very, very happy

At least if it isn't fixed, this might help in pinpointing the cause if it's something different to what you worked on. I haven't tried in development builds, but my guess is it will also happen in dev builds.

 

In my game it's a much simpler setup with basically one vehicle with box collider, and a rigidbody, and some wheel colliders. This vehicle can be directly controlled, or remote controlled. When it is directly controlled, the rigidbody is not Kinematic, and on remote control it isKinematic.

The player has a capsule collider, and a non Kinematic rigidbody. On entering the vehicle the capsule collider is disabled, and the rigidbody is destroyed, before parenting to the vehicle. On leaving the vehicle, the player is unparented, and the rigidbody are added back, and the capsule collider is enabled.

It fails 100% when the player leaves a remote controlled vehicle, and works 100% when the vehicle are direct controlled.

Haven't had time to isolate this yet, trying to work around it first.

Edit: Setting the vehicle collider to non Kinematic before the player is unparented, and then back to Kinematic seems to have fixed this. Not sure though if it's related to the other randomly stopped working collider phenomenon.

 

Yes indeed, it's a different problem. In the repro project I reported yesterday in my posts above (Case 1322724), I can successfully reproduce the CC bug with only simple Box Colliders in 2020.2.7f1, and no RigidBodies, with only the CC

In case you don't have time to check it out, I will definitely test this as soon as 2021.2.0a10 is available to download and report back here

Thanks,
Charles

 

Hi @yant !

Unity 2021.2.0a10 is available today; I've just upgraded the repro project and tested with it.

In previous Unity versions:

• After 10-20 minutes, around half of the builds of the repro project encountered the bug and the Character Controller fell through the floor
• After 1h, 90% of the build instances encountered the bug

In 2021.2.0a10:

• After 2 hours, NONE of the build instances have encountered the bug, and Character Controller NEVER falls through the floor!

I can officially confirm that your fix introduced in 2021.2.0a10 does indeed fix this bug!



A huge THANK YOU to you for solving this for us; it's a major bug in our game, and by far the most problematic.

We are planning to update ASAP, and we are waiting for this fix to be added before we update, because all the bugs we are fixing remain minor compared to some players "randomly falling through the floor and dying" and this results in softlocks, etc. until they actually restart the game, which is a horrible experience for these players.

You can test this repro project with the case number I mention in my previous posts (1322724)
May I ask if there could be an ETA for possibly backporting this in latest TECH stream? We are now on 2021.1.0f1 and would appreciate to not have to wait for 2021.2.0f1

And I guess many other uses in LTS / 2020.x would be very happy to have this bug solved

Wow, you made me very happy. Thanks again, amazing work!
Charles,

 

You're welcome @yant ! Thanks, yeah it was worth it, to finally get to the bottom of this black-magic-bug

OK, I'll wait for news on this, as we switched to 2021.1.1f1 in the hopes of getting the bugfix ASAP, but we're encountering other console-related crashes, which might lead us to remain in 2020.3.2f1 LTS.

If there is a backport involved, is it safe for us to remain in LTS? Meaning if it's backported to 2021.1.x, any chances it'll drop in 2020.3.x LTS at the same time / soon after?

Thanks!
Charles

 

Awesome, thank you for letting me know! I understand dates are a hard thing to get, just knowing it's in the works is great!

Have a nice day,
Charles

 

Yay that's awesome news! Thanks for fixing and keeping us updated!

I think we'll wait for 2021.1.5f1 at this time, but glad to know it's coming to LTS too soon

 

Hi again @yant,

Sorry for the delay, but I finally was able to run my tests on latest 2021.1.10f1, and just to confirm it is fully solved in that version as well! I had only tested in the Alpha until now.

Thanks again for your support on this, I'll regularly run these tests on updated Unity builds in case this issue reappears

Thanks,
Charles

 

What workarounds works for those that are stuck at 2019 for a while? We will eventually upgrade, but right now we are heading towards a new update to our game and it is too late for anything other than workarounds. Our current work-around is having a "death zone" below the level and reloading the level if the player falls into it. Is it possible to patch the offending code that does the pointer & check somehow? We're building for iOS.

 

On asset store you can find something better and even free.
I can recommend: https://assetstore.unity.com/packages/tools/physics/scivolo-character-controller-170660
Easy to switch from CC and out of the box has sliding down the steep slopes.

 

So it hasn't answered the question. I have a collider system that was working as expected. I am using velocity in Rigidbody for movement and all my colliders has a rigidbody. It WAS WORKING and then STOPPED between me pressing the play button one time and the next time I pressed the play button it doesn't work.

 

I am using unity 2022.2.0a18. (Mirror networking) and OverlapSphere stops working after a while

This line of code randomly fails after maybe 10-12 hours of server uptime.
It will work for the first 9-10 hours of gameplay.
Then after that it will always return 0.
The colliders on the monsters stop working.

Code (CSharp):

1.  int numFound = Physics.OverlapSphereNonAlloc(transform.position, 25, Utils.MonsterHitsBuffer, Utils.AggroLayerCheck);

AggroLayerCheck - Monster layer - 9
MonsterHitsBuffer - Array [80]

This is game-breaking for me.