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

Grid Map Hotkeys for "changing floors" in editor no longer work #67497

Closed
Stealcase opened this issue Oct 16, 2022 · 11 comments · Fixed by #79529
Closed

Grid Map Hotkeys for "changing floors" in editor no longer work #67497

Stealcase opened this issue Oct 16, 2022 · 11 comments · Fixed by #79529

Comments

@Stealcase
Copy link

Stealcase commented Oct 16, 2022


Bugsquad note: This issue has been confirmed several times already. No need to confirm it further.


Godot version

4.0 Beta 3

System information

Windows 10

Issue description

Expected Behaviour

When editing a Grid Map, the E and Q keys are used to change the "floor" that the user is currently working on. (Marked in green in the image below)

Actual behaviour

E and Q changes the transform mode of the 3D Editor. I believe it changes from Rotation, translation or scale. (marked in Red in the image below)

image

This is a regression from Godot 4.0 Beta 2

Steps to reproduce

  1. Create a scene, add a 3D mesh to the scene.
  2. Save the scene as a Mesh Library through File>Export>MeshLibrary somewhere in your project.
  3. Create a new Scene, add a GridMap Node.
  4. Drag and drop the MeshLibrary from step 2 into the "MeshLibrary" slot in the GridMap inspector.
  5. Select the GridMap in the Scene Hierarchy. A Window should appear showing all the meshes in the MeshLibrary.
  6. Select the mesh and start drawing the mesh in the scene.
  7. Try to Change the floor you are drawing on with Q and E. Instead of changing floors, it will switch between Transform/Rotation/Scale

Minimal reproduction project

GridMap Project_v2.zip

@Anutrix
Copy link
Contributor

Anutrix commented Oct 17, 2022

@Stealcase Looks like the MRP zip file wasn't uploaded. You needed wait few moments after uploading the file before saving the issue comment/description.

@Stealcase
Copy link
Author

@Anutrix
Thanks for the heads-up.
I forgot to delete the shader cache so it was needlessly bloated.

@clayjohn clayjohn modified the milestones: 4.0, 4.x Jan 26, 2023
@hoodlumj3
Copy link

Feedback:
Can confirm this still happens in :-
Godot_v4.0-beta15_mono_win64
Godot_v4.0-beta15_mono_win64_console
Same steps as @Stealcase posted above to replicate issue.

@tristanpemble
Copy link

W will not clear cursor rotation either, and instead switches transform mode to move mode (Godot 4.1)

@rainerdeyke
Copy link
Contributor

This is a serious bug because it makes it impractical to make 3D selections in the GridMap editor. (It's kind of possible with the zxc keys, but inconvenient and unreliable.) I suspect that it is caused by another UI element snatching up the input events before the GridMap editor gets it. A workaround would be to change the key assignments to avoid the conflict; a proper fix would be to change the UI input handling order such that the GridMap editor has top priority.

@intervolver
Copy link

this is happening as described in version 4.1.1 as well

@elvisish
Copy link

elvisish commented Oct 3, 2023

Why is this closed? W key doesn't work in 4.1.1?
Opened a fresh report: #82746

@krytoou
Copy link

krytoou commented Jan 3, 2024

Q & E still not working in Godot 4.1.3...
very nice job, admins!

@akien-mga
Copy link
Member

@krytoou As the milestone says, this was fixed in 4.2. So it's expected that it doesn't work in 4.1.3.

Please keep ironical rants out of your GitHub comments, as per our Code of Conduct. This is not the place to voice frustrations at people who provide you an engine for free.

@krytoou
Copy link

krytoou commented Jan 3, 2024

this was fixed in 4.2.

that's just an shortcuts, lol! why it is not fixed in all the versions?

@akien-mga
Copy link
Member

why it is not fixed in all the versions?

Because the fix was relatively complex (and introduced two bugs, which had to be fixed later on), and was therefore not deemed safe enough to backport to the stable branch at the time. We're carefully around backporting changes which could introduce new bugs in released versions, and with a 4/5-month release cycle between minor releases, it's better to keep any risky change for the next milestone.

4.2 is released, you can use it. If you can't use it due to new bugs, this is a demonstration of what I just described. Bug fixes can be risky and introduce regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment