-
-
Notifications
You must be signed in to change notification settings - Fork 104
Description
Repro:
- Place a brush
- Switch to Place tool
- Click the brush
- Click it again - a little overlay appears by the cursor denoting an offset
- Right click and move the mouse
- Nothing happens
- Keep holding mouse down, use WASD to attempt a move
- Exceptions will be thrown
This can be replicated with the Edit tool as well but it feels like it's a bit more finicky.
Fumbling around a little, I found this here line in Place tool:
realtime-CSG-for-unity/Plugins/Editor/Scripts/View/GUI/EditModeGUI/EditModes/EditMode.Place.cs
Line 1763 in 4aaf0bc
| break; |
It exits on mouse downwhen the mouse button isn't LMB.
However, a previous mouse down has already set toolEditMode and the GUIUtility.hotControl etc.
Hence the tool remains in that twilight state where it expects a drag but none is coming.
Adding some resets before the break will alleviate the issue described:
toolEditMode = ToolEditMode.None;
GUIUtility.hotControl = 0;
GUIUtility.keyboardControl = 0;
EditorGUIUtility.editingTextField = false;
And one more:
realtime-CSG-for-unity/Plugins/Editor/Scripts/View/GUI/EditModeGUI/EditModes/EditMode.Place.cs
Line 1845 in 4aaf0bc
| SelectionUtility.DoSelectionClick(sceneView); |
The same reset procedure before
SelectionUtility.DoSelectionClick(sceneView) in MouseUp will make it feel a lot better. Albeit that isn't necessary to make the NullRefs go away and the editor respond to input.
Same thing in the Edit Tool.
Some reset code right in here before the break:
realtime-CSG-for-unity/Plugins/Editor/Scripts/View/GUI/EditModeGUI/EditModes/EditMode.Edit.cs
Line 2196 in 4aaf0bc
| break; |
And reset the
_editMode to None.
This is probably something in Unity 6.
So I don't know what the behaviour in earlier versions is or if this is even the correct fix.
It is, hoewever, what I found that works for me - and wanted to share that for the folks that might be looking for an answer.