I believe it’s all of the [inverted] point is inside
If there are multiple tiles then unless they’re stacked then point isn’t inside will always be true for the other tiles and will alway trigger the actions.
If you had 10 instances then
0 inside, 10 not inside
1 inside, 9 not inside
Instead, you need a regular point isn’t inside inside a not condition. That will invert the overall result instead of the individual instance results. It’s kind of the difference between any and all. Since it inverts the result you don’t want to also invert the condition.
If any points inside not inverts the result and doesn’t trigger
If any points not inside not inverts the result and triggers
It can be confusing but when dealing with instances it’s sometimes necessary to use not instead of inverted conditions.
Edit: just for clarity. The regular point is inside are fine. You want them to trigger if any point is inside. 1 or 10 instances, it doesn’t matter. But all of the inverted should be inside a not without being inverted" I know, it sounds the same. It’s a subtle difference.
I recall having the same problem years ago. So, I conducted a quick test and here are the findings:
In the first test, I arranged a grid of 64x64 and utilized a tile of the same dimensions for both the ground and walls. I employed one of Kenney’s characters, which always has measurements that are multiples of 64. I incorporated the necessary behaviors and kept the events to a minimum. Then, I examined collisions from both sides, and there was no flickering at all.
In the second test, I resized the tile at 90x90 (not a multiple of 64) and configured the grid to match at 90x90. Upon inspecting wall collisions, I noticed a flicker lasting about a second, consistently occurring on the right side.
For both tests, I evenly distributed the tiles across the grid. The character’s point of origin was centered on the X-axis and aligned with the bottom edge on the Y-axis.
I’m pretty sure that if you continue to modify the dimensions of the tiles and characters, the flickering issue will likely worsen. Years ago, I abandoned a GDevelop project because I couldn’t resolve persistent (non-stop) flickering that occurred when a character hit a wall on the right side, and it’s not the only time I have seen it. Sometimes, the flickering seems to be slow, and at other times, it’s very quick, resembling a flashing effect. Occasionally, it’s persistent, but sometimes it lasts for just a fraction of a second and is barely perceptible. However, when it does occur, it always happens on the right side. This is the exact same problem.
My recommendation is to always utilize sprites with collision boxes whose dimensions are multiples of a specific even number throughout your game if you want to avoid encountering this problem in the GDevelop engine.
Below, you can find the events I employed for both of the tests:
Well I tried your method about the grab point being now Left and Right respectively for each naimation, but it didn’t changed anything.
My grid is an 8X8 should I modified it to be 4x4 But it does not makes any changes…
I checked my hitboxes and nothing is out of the box… I’m kind of lost rn
Is the same thing happening? Did you also change the inverted point is inside to a NOT condition with a regular non-inverted point is inside inside it? Make sure to change all of them.
They are all deactivated, to see if something change, but nothing changed And I still don’t have player is in collision with wall = stop player bc i cant find one working lol
What do you want to see
If nothing else has changed then IDK. i don’t see anything obvious. Maybe someone else can help.
My only suggestion is to keep debugging. Add something to the events like using the output (debugger) or a text object or even something like playing a sound so you know what is and isn’t being triggered. Either something isn’t being triggered or multiple things are and one thing is undoing the changes. It can be tough.
I wish you luck. There are much more experienced people here than me.
Did you try editing the collision masks? I just think it’s sus that the left idle and left run both hit the left wall at x 0 and they don’t do that, but the right idle hits the right wall at x 28 and right run hits it at x 32 and they do that.
Excuse my ignorance, but why are the hitboxes for each animation different? I’m assuming this is the first thing you’ve tried, but I’m wondering, have you tried setting the hitboxes for all animations to the same size? because on the left side they all start from point 0, which does not change. However, they go up to the values 28, 32, 27 and 30 on the X axis. This will always affect the right side. In turn, the height goes from 0 (top) to 36 in some animations and 37 in others (bottom), which will make the character in some animations shorter or taller.
Are the origin and center points of each animation the same?
This is only bc the sprites are more “larger” on some animation but it does not affect anything concerning my bug, I even tried to lower it and nothing changed
And I still don’t have player is in collision with wall = stop player bc i cant find one working lol