I notice that there is an additional default CollisionShape2D overlaid on top of the purple box.
This light blue box moves automatically according to the position I set for the collision box. Normally, it has no physical collision effect and only appears when the “Show Collision” option is enabled.
To make it easier to understand, I’ll adjust the collision box position and demonstrate again:
Now, this light blue CollisionShape2D box appears here.
Since it has no physical collision effect, I’ve always ignored its presence. However, recently I noticed that this box is being detected in the “Wall Embedding Check,” as shown in the image above. This indicates that my object is embedded in the wall… which is interfering with some of my actions.
I am certain that my object only has one CollisionShape2D set up. Does anyone know why this light blue box appears? What does it represent? And how can I make it disappear?
During debugging, it seems that selecting “2D” at the top of the screen and then pressing “Alt” + right-click on the target collision will display the target node.
Could this provide any specific hints about what is configured here?
The object name is P1. This @Area2D@13/@CollisionShape2D@12 is not my character’s CollisionShape2D. Although I found its location, I still don’t know how to disable it so it doesn’t appear.
After a long investigation, I’ve finally found the cause of this collision box appearing. When an object has the [Wall Embed Detection] action in its VS, this collision box is generated to detect whether the object is embedded in a wall.
However, this collision box, which should overlap with my base CollisionShape2D, moves away from my CollisionShape2D whenever the CollisionShape2D is not centered at position (X: 0.0px, Y: 0.0px).
Example A
If my CollisionShape2D is located at X: 0.0px, Y: 0.0px, the wall-embed detection collision box will overlap perfectly with my CollisionShape2D.
But if my CollisionShape2D is at X: 10.0px, Y: -10.0px, the wall-embed detection collision box will automatically shift by half the distance it is offset from the center of my CollisionShape2D.
I believe it is unreasonable for the collision box of [Wall Embed Detection] to behave this way. This behavior causes my character to be frequently misjudged as being embedded in a wall.
I hope the development team can see this post and provide a solution! Thank you very much!!!
Great investigation @S.C, thank you for the thorough breakdown!
From my understanding, you’re saying the IsEmbeddedInWall (BuriedInWall) condition auto-generates a CollisionShape2D that should mirror your main CollisionShape2D, but when the main one is offset from (0, 0), the generated one drifts by half the offset distance instead of matching. I was able to confirm the same behavior on my end, so I’m reporting this to the developers. Thanks again for the detailed write-up, it made it easy to verify.
In the meantime, a possible workaround is to keep your main CollisionShape2D centered at (0, 0) and offset the Sprite2D or AnimatedSprite2D instead to get the visual positioning you want. Not ideal, but it should avoid the false detection until there’s a fix.
Thank you very much for gaz’s reply and report; your understanding is absolutely correct.
Since my character has many action animations, such as crouching or transforming, which use AnimationPlayer to fix the positions of different CollisionShape2D nodes, I decided to temporarily disable the IsEmbeddedInWall (BuriedInWall) condition before the fix.
@Baz Today I was testing 【Wall Embedding Detection】 and found something odd.
For example: I set Object A to trigger 【Wall Embedding Detection】 > 【HP0】 > 【Load Save】.
I noticed that when Object A stands on a tilemap, being squeezed up or down by other objects immediately triggers the Wall Embedding Detection and activates HP0.
However, squeezing from the left or right fails to trigger the Wall Embedding Detection. Instead, Object A gets pushed into the wall until the moving object leaves.
Is this a bug? Could you please help reproduce it? If it is indeed an issue, let’s report it together. Thank you very much.
However, another issue related to collision detection was identified earlier and remains unresolved. Could the development team please take a look at the following?
Hi, my object is a standard GameObject, and the setup is quite simple.
However, I’ve configured it so that when it’s hit from the left or right, it gets knocked back and takes damage. I’m certain that this action is what’s preventing the wall-embedding detection from triggering. Even though it’s being knocked away, it should still be in the anystate state, so theoretically, the detection should still work.
I changed it to a regular GameObject and tested the state of being pushed by enemies, and it was working correctly.
A player that transitions from Anystate to being embedded in the wall and outputs “Embedded” to the console.
An enemy that simply pushes that player.
I tested pushing from right to left and top to bottom, as well as embedding into walls, and it correctly outputs “Embedded.”
I suspect that some other setting might be affecting this.
The likely culprits are the collision layer/mask or some setting related to the knockback action.
Could you try reproducing the issue with a minimal setup?
Sure, I’ll send the simplified GameObject separately to your email. Please let me know your email address.
I already know where the problem lies, but I’m not sure how to fix it, so I’d appreciate your help to take a look. I’ve also been continuously trying various fixes myself.
Update: After adding more constraints to the condition action for receiving attacks, I finally managed to trigger the wall-embedding behavior!!!
Thank you so much, Mr. moonling, for your prompt feedback, which has greatly helped me learn and grow.
After several tests, I successfully fixed the issue, so there’s no need for you to help with debugging this time!
Additionally, I have a few small questions about the BGM in version 1.29. I’ve left a comment under your update announcement, so please take a look when you have time. Thank you again.
