Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The test_move() function may not be behaving properly, when rotating #42175

Closed
vesk4000 opened this issue Sep 18, 2020 · 6 comments · Fixed by #42574
Closed

The test_move() function may not be behaving properly, when rotating #42175

vesk4000 opened this issue Sep 18, 2020 · 6 comments · Fixed by #42574

Comments

@vesk4000
Copy link

vesk4000 commented Sep 18, 2020

Godot version:
Godot Engine v3.2.3.stable.official

OS/device including version:
Windows 10 Pro, Version 2004

Issue description:
In this demo, I've got this T shape and it can move around in an invisible grid as well as rotate 90 degrees clockwise. It should collide with these blue walls, and when simply moving - it does. But if I try to rotate next to a wall that is to the right of the T shape (when looking from its perspective by taking into account the rotation), the T shape kinda glitches out instead of just not moving or rotating at all like it is supposed to.
rotation_test

Here's the script that's attached to the T shape:
2020-09-18 20_32_44-Godot Engine - Rotation Collision Test - Level tscn

Minimal reproduction project:
Rotation Collision Test.zip

@madmiraal
Copy link
Contributor

This is also fixed with #35945 and its 3.2 version #37498.

@vesk4000
Copy link
Author

Yup just compiled your commit (#35945) and tested it with my demo project - it works! Thanks so much for the fix! Do you have an idea when the commit might find itself in the stable version of Godot, because I think this is a very important commit and I don't feel that the current master is stable enough for me to use?

@Calinou
Copy link
Member

Calinou commented Sep 19, 2020

Do you have an idea when the commit might find itself in the stable version of Godot, because I think this is a very important commit and I don't feel that the current master is stable enough for me to use?

We can't make any guarantees that it will be merged as-is, since reduz disagrees with the implementation.

and I don't feel that the current master is stable enough for me to use?

You can always compile the 3.2 branch from source and apply your own commits on top 🙂

@vesk4000
Copy link
Author

vesk4000 commented Sep 19, 2020

You can always compile the 3.2 branch from source and apply your own commits on top 🙂

@Calinou Yeah that is actually a good idea. I see that @madmiraal has made a 3.2 version of the PR, so I think I'll just compile that (now that I actually know how to compile Godot, which really ended up being easier than I expected).

We can't make any guarantees that it will be merged as-is, since reduz disagrees with the implementation.

I haven't extensively looked at the implementation and from what I read it seems that it is a bit of a workaround until/if the physics engine is reworked. But the thing is, it is a massively important workaround in my opinion, given how basic of feature that is. Like I don't know how more people aren't having problems with this, but it's quite nonsensical (for the lack of a better word) how something as simple and basic as my demo didn't work. I really hope this gets fixed in stable as soon as possible, whether it is by #35945 or something else.

@vesk4000
Copy link
Author

@Calinou By the way, I closed the issue, because it was fixed by #35945, but since you say that it is unlikely that that PR will be merged, should I reopen it until it is fixed in an official build, or should I keep it closed?

@Calinou Calinou reopened this Sep 19, 2020
@pouleyKetchoupp
Copy link
Contributor

Fixed by #42574, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants