This fixes a bug introduced by 806425621c, where dragging the gizmo no longer respected local transforms.
I'm not sure why I called set_local_coords_enabled(false) in _compute_edit. Removing this line seems to fix gizmo-dragging local transforms, without breaking anything else.
I also noticed that confirming a transform leaves the gizmo axis lines on the screen. This is fixed by calling update_transform_gizmo after clearing the edit mode/instant flags, so update_transform_gizmo knows not to render any axes.
Having local_space enabled when starting a transform changed the
behavior of VIEW space transforms. Now we disable local_space when
starting a blender transform (there was already logic to restore the
setting after the transform ends).
This also hides the gizmo while performing a blender transform,
otherwise the user will see it snap back and forth between the local and
global alignment. I think the transform looks cleaner with the gizmo
hidden anyways.
Fixes#59392.
* Description of `ui_text_submit` action should be "Submit Text" instead of "Text Submitted".
* Spell out "Animation" instead of using "Anim.".
* Treat "Max" as regular word instead of writing "Max.".
* Use generic "Set %s" for action name instead of a dedicated "Set target_position".
* Add translator comment for:
* "Inclusive" and "Self" in the profiler.
* Places where it needs the context about being an editor progress label.
* "Duplicated Animation Name" since it's refering to the new name of a duplicated animation.
* Disambiguation of "View Plane Transform", "Paste Selects" and "Display Normal".
* Fix wrong undo action name for renaming an input action.
* Fix missing end quote in a shader error message.
* In class reference:
* Fix duplicated "if" in the description of `signf()`.
* Fix mismatched example output in `String.operator %()`.
* Fix typo in the description of `Decal.texture_emission`.
* Unify description of `String.match()` and `StringName.match()`.
* This solution is much cleaner than the one in 3.x thanks to the use of callables.
* Works without issues in any language (no need to worry about camel or snake case).
* Editor code uses a compatibility function (too much work to redo).
Fixes#59899
* All core types masks are now correctly marked as bitfields.
* The enum hacks in MouseButtonMask and many other types are gone. This ensures that binders to other languages non C++ can actually implement type safe bitmasks.
* Most bitmask operations replaced by functions in BitField<>
* Key is still a problem because its enum and mask at the same time. While it kind of works in C++, this most likely can't be implemented safely in other languages and will have to be changed at some point. Mostly left as-is.
* Documentation and API dump updated to reflect bitfields in core types.
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.
It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).
We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).
Also fixed "cf." Frenchism - it's meant as "refer to / see".
This prevents the project setting from being located directly within
a root category, which is confusing from an UX perspective in the
project settings editor.
DisplayServer::screen_is_touchscreen will likely never utilize its
parameter p_screen.
This PR replaces this function by DisplayServer::is_touchscreen_available()
with the same functionality.
This solves the problem, that a SubViewport was used for determining
the screen, which resulted in error messages.
* When there's nothing to collide with:
* Place the new scene on XZ plane when possible.
* When the camera does not point toward the XZ plane or the
intersection is too far away, place the new scene on a plane that
is in front of the camera and parallel to the frame.
* Fixes positioning when in orthogonal view.
* Place on physical collision point or the XZ plane when possible.
* Otherwise, place it on the plane in front of the camera as if the
camera was perspective.
* Makes use of snap settings when placing the new scene.