Search Issue Tracker
Fixed in 2019.3.X
Fixed in 2018.4.X, 2019.1.X, 2019.2.X
Votes
0
Found in
2018.3.9f1
2018.3.10f1
2019.1.0b7
2019.2.0a7
Issue ID
1140632
Regression
Yes
OnTriggerEnter is called inconsistently when moving a trigger via Input key press with AddForce()
How to reproduce:
1. Open user-submitted project (Test)
2. Enter Play Mode while holding the up arrow key
3. See that OnTriggerEnter is called when the trigger reaches the sphere
4. Enter Play Mode without holding the up arrow key
5. Use the up arrow key to move the trigger into the sphere
Expected result: OnTriggerEnter is called
Actual result: OnTriggerEnter is not called
Reproducible with: 2018.3.10f1, 2018.3.11f1, 2019.1.0b7, 2019.1.0b9, 2019.2.0a7, 2019.2.0a9
Not reproducible with: 2018.3.9f1, 2019.1.0b6, 2019.2.0a6
Could not test with: 2017.4.23f1(Project incompatibility issues)
Notes:
Tweaking the Rigidbody component options on the trigger fixes this issue
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
goran_okomotive
Jul 04, 2019 11:43
You workaround worked @FHREBST. But it caused quite a performance hit on our Switch port, because of a combination of large hierarchies and collider position updates on the physics side. Updated the project to 2019.1 - I don't get why it takes so long to fix it in 2018.4.
fherbst
Jun 14, 2019 15:11
Also just found out about this (a regression from 2018.2). After some testing, I found that the "internal" representation of the collider that enters the trigger seems to be still in another place (can be seen when moving the trigger towards the collider).
Workaround seems to be to change the transform of the not-working collider every frame ever so slightly (like, oscillate with 0.0001f).
goran_okomotive
Jun 05, 2019 09:03
Does anybody know a good workaround for this issue? We are working with 2018.4 and it's quite hard to do a port right now, without having this bug back-ported on time.