just updated to 1.0.20 from 1.0.18 and the collision detection issue has not been fixed and is now worse, like development halting worse. Before the update the player would incorrectly enter fall state on slopes or on any non-ground object with collision. Now the player loads in to game and immediately enters fall state and stays there. Absolutely no change has been made to the players scripting or setup in any way. I have gone over the VS and all of the settings an there is no logical reason for this to be happening that I can see. Am I missing something in the new update or is this a new bug?
Is there a clear minimal reproduction project to demonstrate this issue?
The update 1.0.20 aims to fix the issue where collision detection on the left and right sides is triggered when game objects move close to the ground. (This issue is mainly due to corner collisions being triggered.) It sounds like when the character falls, only one corner touches the slope, and the behavior does change somewhat. However, a specific case is needed to analyze whether it is a bug.
sent a link to the project to you. it was a bit over the attachment size. thank you for your response.
Well, maybe I can shed some light on the matter. In my case, I loaded several projects, and on ramps it no longer goes into the fall/run state, but on the “normal” floor, when you press right, for example, it goes from the wait state to the run state when it reaches the end of each tile. I checked the projects and in all of them I have the condition in the run action that if you are pressing right, (I also have it for left), and it collides with a wall on the right, (in the case of pressing left, the detection is done on the left logically), it goes into the wait state because I don’t like the character to stay stuck to the wall running. Well, I eliminated that condition and the character no longer goes from the run state to the wait state when it reaches the end of the tile. I just tested the project I sent for the fire button bug and the loss of performance with the bullet settings options, (by the way, it is not fixed yet :P), and what I described happens. It’s as if it somehow detects the wall on the right or left even though there isn’t a wall. It must be a collision issue.
Interesting. not quite what I am experiencing but you did give me an idea that might be a work around for my issue. thanks!
my idea did not work just FYI. Can not seem to get the out of fall state. thinking this is a bug. hoping to hear back.
Well, the error also affects enemies, if you have a condition set that when it collides with a wall on the right when it reaches the end of the tile it turns around and walks to the left even if there is no wall.
Is this the issue you are having Locelaro?
No it is not that. it is this: (sorry did not know how to upload video)
Recording 2025-08-22 143658.zip (2.3 MB)
I wish to state again that the only change made was updating to the 1.0.20 release from 1.0.18. Prior to update the issue was not present unless on a slope or object other than the ground (i.e. a destructible crate)
Ok understood. Can you please send in your project to pgmmv-support@gotchagotcha.jp so we can look into what may be causing this behavior?
Thank you very much.
Follow up:
Support has passed the issue on to the Devs. I will update when I learn anything more.
Hello, I’m not sure if this is related, but I’ve found an issue. In version 1.0.19, it seems that behavior related to angles is misaligned. Strangely, this occurs right at the start of test play. For example, the initial visible_direction is somehow set to 90, and when jumping, it changes to 270. Pressing F5 to reset brings it back to 0 and works normally.
Additionally, the movement action that uses the display direction also tries to move upward for some reason. This too is fixed when pressing F5 to reset.
That does seem related. Unfortunately the f5 trick made no corrective difference in my case. It did however change the direction orientation of my attack to fire straight down (not a direction programmed in at all). Direction seems to correct itself if left or right is pressed. Hoping this get fixed soon because for me development is halted until this is sorted.
Follow up:
Thanks to BAZ (Base?) I was shown how to revert to 1.0.17 however the issue from 1.0.20 was there. I reverted to 1.0.19 and it was back to how it was in 1.0.18, meaning the collision detection issue was only happening while going UP slopes (going DOWN slopes the issue is intermittent similar to BAZ’s video above) or while on top of objects with collision. I am able to continue on thankfully and I will follow up again if any significant developments arise. Thank you all for the support.
「いいね！」 1
Follow up:
1.0.21 has had no change to the issues I have been experiencing. I have rebuilt my project from the ground up 5 times now and the prospect of doing it again in 1.0.21, to what I fear is going to be the exact same result, is demoralizing to say the least. When I was working in Godot 4.3 things were going well but my GDscript knowledge is rudimentary at best so development was slow. I had hoped that AGM would help me speed up development but it really hasn’t so far. The community has been great and the support is fantastic its just that the product I feel isn’t quite there yet. What is worse is I now can not get back to 1.0.18 which was the version that was working best for me. I will rebuild in 1.0.21 but I think it will be the last one. Thank you all.
They did publish an explanation and apology for this collision hiccup in their latest producer letter. It will be fixed soon with a better system, but yea 1.0.21 was not it. I did report your exact issue, so the devs are aware of it.
「いいね！」 1
It is great that the Devs are acknowledging it but that still leaves me stuck. is there any way to get back to 1.0.18 or even .19? If no then I would like to request that it be made available.
Ah good idea, I passed this along to add a 1.0.18 branch. It is Saturday in Japan, so give it a couple days.
「いいね！」 1