I verified this experimentally. I added a point at roughly (1,0,0), and
dragged a handle back to the origin. The result was:
```
get_point_position: (0.991079, 0, -0.000069)
get_point_in: (0.993409, 0, 0)
get_point_out: (-0.993409, 0, 0)
```
(cherry picked from commit c6093ae612)
- Mention Lua-style syntax.
- Make the code samples self-contained.
- Mention caveat with `const` (also in Array).
- Clarify the description of `size()`.
This closes https://github.com/godotengine/godot-docs/issues/4272.
(cherry picked from commit 5325de4e6b)
Some controllers (notably those made by 8bitdo) do not always emit an event to zero out a D-pad axis before flipping direction. For example, when rolling around aggressively the D-pad of an 8bitdo SN30 Pro/Pro+, the following may be observed:
```
ABS_HAT0X : -1
ABS_HAT0Y : -1
ABS_HAT0Y : 0
ABS_HAT0Y : 1
ABS_HAT0X : 1
```
Notable here is that no event for `ABS_HAT0X: 0` is emitted between the events for `ABS_HAT0X: -1` and `ABS_HAT0X: 1`. Consequently, the game engine believes that both the negative _and_ positive x-axis directions of the D-pad are activated simultaneously (i.e `is_joy_button_pressed()` returns `true` for both `JOY_BUTTON_DPAD_LEFT` and `JOY_BUTTON_DPAD_RIGHT`), which should be impossible.
This issue is _not_ reproducible on all controllers. The Xbox One controller in particular will not exhibit this problem (it always emits zeroing out events for an axis before flipping direction).
The fix is to always zero out the opposite direction on the D-pad axis in question when processing an event with a nonzero value. This unfortunately wastes a small number of CPU cycles on controllers that behave nicely.
**I have verified this issue is also reproducible in the stable 3.2 branch**
(cherry picked from commit dd021099ff)
This check was there since the first commit in 2014, but a later feature added in 2018
with #17717 did not properly update the code while adding non animation-related code
in `perform_node_renames`.
Fixes#40532.
(cherry picked from commit d107fd4c9e)
This also makes borders always display in the editor theme,
even if the editor scale is below 100%. Otherwise, "focus" outlines
would vanish when using an editor scale below 100%,
which harms usability.
- The grid is now infinite, it follows the camera.
- The grid is now dynamic, if you zoom in and out, the grid subdivides,
expands, and fades.
- You can now enable grid planes for the XY and YZ planes. Only the flat
XZ plane is enabled by default. Each plane is independently dynamic
of the others.
- The default grid size has been increased to 200, and the maximum
has been increased to 2000. At 1000, the grid mostly looks edgeless.
- If you set the division level max and min to the same value then
the grid does not expand or subdivide, but instead stays the same size
and just follows the camera. Also, if these values are the same,
the bias value does nothing.
- If you want to have Blender-like behavior, set max to 1, min to 0,
and set the bias to a really low value. You may also wish to increase
the grid size if you have a small bias.
Co-authored-by: Aaron Franke <arnfranke@yahoo.com>
In some situations where polygons were scaled, existing software skinning was producing incorrect results.
The transform inverse needed to use an affine inverse rather than a cheaper inverse to account for this scaling.
