text:
[TRACKER] Methods, properties and signals to consider for renaming in next planned compatibility breakage

This issue is meant to keep track of awkwardly named or deprecated methods, properties and signals that we would like to rename next time we have the opportunity.
This can't be done lightly as it breaks compatibility for users using their old names, so any such change has to be done:

either after following a deprecation procedure: marked as deprecated - using it shows a warning - for at least one full minor release cycle (e.g. 3.1.x), then removed in a future minor or major version bump,
or within a major compatibility breaking release (such as 3.0 was to 2.1; but such situations won't happen often - if ever again - so the deprecation workflow should be preferred).

To properly deprecate methods, properties and signals, we need #4397 implemented.

Classes

[ ] OS* could be renamed to Platform* https://github.com/godotengine/godot/issues/16863#issuecomment-403253127
[ ] PHashTranslation should be renamed to CompressedTranslation (matching its header)
[ ] ResourceFormat*: review all classes inheriting ResourceFormatLoader, ResourceFormatSaver and ImageFormatLoader to check that they follow the same naming convention (both class and filename)
[ ] TCP_Server and IP_Unix should be renamed to TCPServer and IPUnix #19623

Methods

[ ] @GDScript (and several other places): instance when used as a verb/action should be instantiate https://github.com/godotengine/godot/issues/16863#issuecomment-367061984
[ ] @GDscript: decimals should be renamed to step_decimals #21425
[ ] AcceptDialog and ConfirmationDialog: get_ok and get_cancel should be get_ok_button and get_cancel_button (matching WindowDialog.get_close_button) https://github.com/godotengine/godot/issues/16863#issuecomment-421071469
[ ] Animation: track_remove_key_at_position should be track_remove_key_at_time
[ ] Area: set_audio_bus and get_audio_bus should be renamed to set_audio_bus_name and get_audio_bus_name to match the related property and their Area2D counterparts #29670
[ ] Camera: set_znear and set_zfar should be renamed to match the near and far properties https://github.com/godotengine/godot/issues/16863#issuecomment-412810788
[ ] Control: Discrepancy between property names and their setter/getter names https://github.com/godotengine/godot/issues/16863#issuecomment-381420942
[ ] CollisionShape: make_convex_from_brothers should be make_convex_from_siblings https://github.com/godotengine/godot/issues/16863#issuecomment-493794313
[ ] InputMap: load_from_globals should be load_from_project_settings https://github.com/godotengine/godot/issues/16863#issuecomment-426457888
[ ] ItemList: unselect and unselect_all should be deselect and deselect_all, matching other classes with similar methods. There's also deselect_items in FileDialog, harmonize this #28558
[ ] KinematicBody and KinematicBody2D: The API grew organically and is becoming quite convoluted, a refactor/reorder of some method arguments might be welcome (see e.g. #16757 #19648).
[ ] MainLoop: _iteration should be renamed to _physics_process, _idle should be _process. Non virtual methods should be unexposed, and input_text does nothing and should be removed #30096
[x] Node: get_index and get_position_in_parent are synonyms, one should be removed #21802
[ ] OptionButton: get_selected_id might be obsolete after #21837
[ ] OS: can_draw would be better suited in the Engine singleton
[ ] OS: execute should be split in two different methods, one blocking and the other non-blocking.
e.g. names: execute/exec_process (blocking) and spawn_process (non-blocking) #19302
[ ] Physics (various classes): add_force and apply_impulse methods need harmonization of their arguments order https://github.com/godotengine/godot/issues/16863#issuecomment-416791048
[ ] RichTextLabel: set_use_bbcode and set_bbcode should be renamed to set_use_fixed_bbcode and set_fixed_bbcode. Warnings should be thrown if bbcode is modified by another function #19118
[ ] Skeleton: set_bone_global_pose should be renamed to set_bone_skeleton_pose (same for the getter). get_bone_transform should also be renamed, or dropped if unnecessary #19551
[ ] Sprite, Sprite3D: set_region and is_region should be renamed to set_region_enabled and is_region_enabled https://github.com/godotengine/godot/issues/16863#issuecomment-380225780
[ ] String: ord_at considered unclear, proposal to rename it to unicode_at #15519
[ ] String: right behaviour is unintuitive and mostly duplicate of substr https://github.com/godotengine/godot/issues/16863#issuecomment-419635744
[ ] TileMap: set_y_sort_mode and is_y_sort_mode_enabled should be renamed to set_y_sort_enabled and is_y_sort_enabled https://github.com/godotengine/godot/issues/16863#issuecomment-380250110
[ ] TileMap: Discrepancy between property names and their setter/getter names https://github.com/godotengine/godot/issues/16863#issuecomment-382545668
[ ] Tree: get_selected should be renamed to something like get_active https://github.com/godotengine/godot/issues/16863#issuecomment-425712040
[x] Tween: Many methods return bool for no reason, should be changed to void https://github.com/godotengine/godot/issues/16863#issuecomment-420286639
[ ] UndoRedo: is_commiting_action has a typo, should be "committing"
[ ] VisualServer: sync and draw bindings should be deprecated in favour of the existing force_sync and force_draw #15892

Properties

[ ] BoxShape, CubeMesh and CSGBox: their dimension properties are inconsistent, and CubeMesh should maybe be renamed to BoxMesh https://github.com/godotengine/godot/issues/16863#issuecomment-403253127
[ ] Camera2D: offset and offset_h/offset_v are confusingly named as they refer to completely different things. It should likely be harmonized with Camera too which has h_offset and v_offset https://github.com/godotengine/godot/issues/16863#issuecomment-407133383 #7489
[ ] Control: Rename margin to offset now that they can be negative? https://github.com/godotengine/godot/issues/16863#issuecomment-401824810
[ ] ImageTexture: lossy_quality should be changed to an enum (low, mid, high, etc.) instead of a float ratio interpreted as arbitrary plateaus (same in Image::compress()) https://github.com/godotengine/godot/pull/21167#issuecomment-414234160
[ ] Label and Button: clip_text is not necessary anymore, as all Controls have rect/clip_content #20228
[ ] LineEdit: cursor_* properties should be renamed to caret_* #16116
[ ] LineEdit and TextEdit: Their respective APIs could be homogenized as far as possible https://github.com/godotengine/godot/issues/16863#issuecomment-409058538
[ ] Node2D, Spatial: inconsistency between position (2D) and translation (3D) #9128
[ ] Resource: resource_name is not used, should be dropped #13358
[ ] TileMap: collision_friction property should be renamed to friction #18191

Signals

[ ] ARVRController: button_release should be spelled button_released (like button_pressed)
[ ] CanvasItem: hide should be renamed to hidden
[ ] Tabs: tab_close and tab_hover should be spelled tab_closed and tab_hovered
[ ] Tree: item_activated (label double-click) and item_double_clicked (icon double-click), names don't properly convey what they do #16839

Enums

[ ] Viewport: ClearMode and UpdateMode enums should use the same suffixes (#19404)

Constants

[ ] Global Scope: PROPERTY_USAGE_STORE_IF_NONZERO and PROPERTY_USAGE_STORE_IF_NONONE should be fully dropped, also from GDNative

Theme properties

[ ] ItemList, LineEdit, RichTextLabel, TextEdit and Tree: font_color_selected should be renamed to font_selected_color to match other _color properties. #30018

Objects

[x] CapsuleShape should be vertical by default

Shading language

[ ] WORLD_MATRIX is actually a model-view matrix and should be renamed. @reduz suggests to replace it (and CAMERA_MATRIX, which is a view matrix) by actual view and model matrices, e.g. CANVAS_MATRIX and ITEM_MATRIX.

Project Settings

[ ] display/window/size/test_width and test_height should be renamed to window_width and window_height. We should also consider renaming the width and height settings, maybe render_width and render_height. https://github.com/godotengine/godot/issues/16863#issuecomment-412308210

File formats

[ ] Discuss what we want to do with custom binary resource extensions (RES_BASE_EXTENSION) https://github.com/godotengine/godot/issues/16863#issuecomment-413620204

Too tedious for me, but Godspeed to whoever fixes instance as instantiate where used as a verb.

#16116

Sprite.set_region(val) -> Sprite.set_region_enabled(val)

rect_min_size
Control.set_custom_minimum_size(value) -> Control.set_rect_min_size(value)
Control.get_custom_minimum_size() -> Control.get_rect_min_size
There are many more in Control class the get/set should all have the same name as the variable it is annoying to check the docks every time when you know the variable name.

The TileMap class has a bunch of getter and setter methods that don't agree with their respective properties. In fact I'd suggest renaming most getters and setters in that class, so they agree with their properties as well as the naming in other classes.

Animation.track_remove_key_at_position should be
Animation.track_remove_key_at_time

Methods

OS: execute should be split in two different methods, one blocking and the other non-blocking.
e.g. names: execute/exec_process (blocking) and spawn_process (non-blocking)

LineEdit has a parameter new_text on "text_changed" but TextEdit does not.
https://github.com/godotengine/godot/blob/master/scene/gui/text_edit.cpp#L6104
https://github.com/godotengine/godot/blob/master/scene/gui/line_edit.cpp#L1466

I would like if VBoxContainer/HBoxContainer/GridContainer is renamed to simple VBox/HBox/Grid, but its probably suggestion for 4.0 version of Godot

And later it will be renamed again because it is too short like pos->position :D
They are a bit long you are right.

I noticed that Godot currenly has two different naming conventions in its method names.
Sometimes, it follows a common convention that can be found in APIs of such languages like C# or Java, like [action][object]() form: i.e.)

Mesh.GetBlendShapeName()
AnimationPlayer.GetCurrentAnimation()
Button.GetButtonIcon()

However, in other places, it follows a different convention of [prefix][action][object], like:

Mesh.SurfaceGetFormat()
AnimationTreePlayer.NodeGetInputCount()
CollisionObject.ShapeOwnerGetOwner()

If we can afford to do sweeping compatibility breaking changes sometime in future, I'd like to see they can be renamed to follow a single, well defined naming convention (hopefully the former, as it's more often used both inside and outside Godot).

However, in other places, it follows a different convention of [prefix][action][object](), like:

Mesh.SurfaceGetFormat()
AnimationTreePlayer.NodeGetInputCount()
CollisionObject.ShapeOwnerGetOwner()

I didn't double check all usages, but from what I've seen this style of method naming, though a bit awkward, also follows a specific convention. For example the shape_owner_get methods:
doc/classes/CollisionObject.xml
101:            <method name="shape_owner_get_owner" qualifiers="const">
110:            <method name="shape_owner_get_shape" qualifiers="const">
121:            <method name="shape_owner_get_shape_count" qualifiers="const">
130:            <method name="shape_owner_get_shape_index" qualifiers="const">
141:            <method name="shape_owner_get_transform" qualifiers="const">

The "prefix" refers to the first argument, and the part after get is what you'll actually be getting in that prefix. For example, shape_owner_get_shape_index(owner_id, shape_id) is conceptually similar to a get_shape_owner(owner_id)->get_shape_index(shape_id), but there's no ShapeOwner exposed to the scripting API, hence this "shortcut".
Same story for the surface_get methods:
doc/classes/ArrayMesh.xml
88:             <method name="surface_get_array_index_len" qualifiers="const">
97:             <method name="surface_get_array_len" qualifiers="const">
106:            <method name="surface_get_arrays" qualifiers="const">
114:            <method name="surface_get_blend_shape_arrays" qualifiers="const">
122:            <method name="surface_get_format" qualifiers="const">
131:            <method name="surface_get_material" qualifiers="const">
140:            <method name="surface_get_name" qualifiers="const">
148:            <method name="surface_get_primitive_type" qualifiers="const">

doc/classes/VisualServer.xml
2363:           <method name="mesh_surface_get_aabb" qualifiers="const">
2374:           <method name="mesh_surface_get_array" qualifiers="const">
2385:           <method name="mesh_surface_get_array_index_len" qualifiers="const">
2396:           <method name="mesh_surface_get_array_len" qualifiers="const">
2407:           <method name="mesh_surface_get_arrays" qualifiers="const">
2418:           <method name="mesh_surface_get_blend_shape_arrays" qualifiers="const">
2429:           <method name="mesh_surface_get_format" qualifiers="const">
2440:           <method name="mesh_surface_get_index_array" qualifiers="const">
2451:           <method name="mesh_surface_get_material" qualifiers="const">
2462:           <method name="mesh_surface_get_primitive_type" qualifiers="const">
2473:           <method name="mesh_surface_get_skeleton_aabb" qualifiers="const">

Or the *node_get methods in ATP:
doc/classes/AnimationTreePlayer.xml
35:             <method name="animation_node_get_animation" qualifiers="const">
44:             <method name="animation_node_get_master_animation" qualifiers="const">
53:             <method name="animation_node_get_position" qualifiers="const">
109:            <method name="blend2_node_get_amount" qualifiers="const">
146:            <method name="blend3_node_get_amount" qualifiers="const">
172:            <method name="blend4_node_get_amount" qualifiers="const">
225:            <method name="mix_node_get_amount" qualifiers="const">
255:            <method name="node_get_input_count" qualifiers="const">
264:            <method name="node_get_input_source" qualifiers="const">
275:            <method name="node_get_position" qualifiers="const">
284:            <method name="node_get_type" qualifiers="const">
315:            <method name="oneshot_node_get_autorestart_delay" qualifiers="const">
324:            <method name="oneshot_node_get_autorestart_random_delay" qualifiers="const">
333:            <method name="oneshot_node_get_fadein_time" qualifiers="const">
342:            <method name="oneshot_node_get_fadeout_time" qualifiers="const">
478:            <method name="timescale_node_get_scale" qualifiers="const">
523:            <method name="transition_node_get_current" qualifiers="const">
532:            <method name="transition_node_get_input_count" qualifiers="const">
541:            <method name="transition_node_get_xfade_time" qualifiers="const">

@akien-mga

I didn't double check all usages, but from what I've seen this style of method naming, though a bit awkward, also follows a specific convention
I'm aware of the fact that it's a naming convention of its own. But it's still not something commonly used outside Godot, and also a bit confusing because sometimes the same word like BlendShape is used in methods which follow two different naming convention.

Personally, I'd like to see them all renamed GetPrefix* and SetPrefix* for consistency, but maybe other people might have different opnions about it.

The methods changed in #16757. The argument order makes more sense, but it breaks API compatibility between 3.0 and 3.1 (#19648).

I'll raise #9128 again: translation in 3D vs position in 2D is an odd dissimilarity.
It was raised ages before 3.0 but was closed after 3.0 went out due to... 3.0 being out.

OS.execute should use posix_spawn.

Another one might be renaming "margin" to "offset" for control nodes.
Since margins are negative on the right side, this misleads people, especially when comparing with StyleBoxes

@groud I feel offset is too generic though

@groud I feel offset is too generic though, margins were a good term (and werent negative when first introduced)

Well, margin is misleading now that they are negative. Offset is generic, but makes more sense. I don't think it's a problem that they are generic since it is in the context of control nodes.
Anyway I'm open to better suggestions. I just wanted to drop this idea here since such property name change has already been suggested. See here  for example.

The size of boxes/cubes is named inconsistently.
BoxShape for collisions uses extents.
CubeMesh has a size property with x, y and z, which are each half the extents.
CSGBox has a Width, Height and Depth property which are defined like the x, y and z size in CubeMesh.
In addition to the size property, sometimes "Cube" is used and sometimes "Box" is used. It would make sense to use "Box" for everything since x, y and z for CubeMesh can be set independently and it is thus also a box.

Since we have e.g. HTML5 and UWP as targets, which aren't exactly operating systems, I propose renaming OS to Platform (PlatformWindows, PlatformUnix,...).
Makes sense with the OS/Display split too.

From this #20228, Label.clip_text is not necessary anymore.

Camera2D currently has two different properties both named offset (Regular offset and the one split up in V and H) that are two totally different things, this is really confusing.

Methods

Dictionary: erase_checked should be removed (this method is not exposed to scripts).
Dictionary: erase should be changed to return bool to determine whether the pair with the specified key was removed or not (see erase_checked implementation).

@akien-mga but it would break GDNative API compatibility, isn't it?

@akien-mga Wouldn't that break forward compatibility? Are we allowed to make changes that potentially make 3.1 scripts incompatible with 3.0?

@neikeq Yes, 3.1 scripts are already incompatible with 3.0 (class_name, tons of API changes with new optional parameters or brand new properties/methods, new classes, etc.). We only take care of backward compatibility, not forward.

Oh, I see! If that's the case I will make those changes now.

If I can have one added to the list, the LineEdit and TextEdit control nodes would really benefit from having (nearly) identical GDscript APIs so they can be used (mostly) interchangeably. Right now it feels like a mess trying to work with them together, to the point where looking at one node gets me confused about the other.

@eska014 In addition, the scons option is already platform. It makes sense to be consistent.

The project settings display/window/size/test_width and test_height should be renamed to window_width and window_height. We should also consider renaming the width and height settings, maybe render_width and render_height.

Camera near and far have different names than its setters/getters ( eg set_znear/set_zfar). This should be  changed ?

znear and zfar are confusing. It doesn't have anything to do with the Z axis in the world space.
And if you assume Z is camera depth, I don't know what other kind of "near/far" you could be referring to then, so what's the point of distinguishing it as "Z"?
I would support changing the methods to set_near etc.

Yeah, there are two ways to solve this problem.

We should get rid (or seriously discuss) binary resource extensions.. (RES_BASE_EXTENSION)

gdscript_function.cpp and gdscript_functions.cpp are very similarly named, I keep getting them mixed up. Worth renaming?
I changed https://github.com/godotengine/godot/pull/21425 to rename "decimals" to "step_decimals" but keep "decimals" as an alias. Assuming it's merged, we can remove "decimals" in the next compatibility breakage, if not, just renaming.
@mysticfall In my opinion it's better to not have the word "get" in method names when unnecessary. Classes like Vector3 only contain get in one place, "get_axis", which is necessary because there's already an enum called axis. Ex: I would change these:
Mesh.GetBlendShapeName()
AnimationPlayer.GetCurrentAnimation()
Button.GetButtonIcon()
Mesh.SurfaceGetFormat()
AnimationTreePlayer.NodeGetInputCount()
CollisionObject.ShapeOwnerGetOwner()

To these:
Mesh.BlendShapeName()
AnimationPlayer.CurrentAnimation()
Button.ButtonIcon()
Mesh.SurfaceFormat()
AnimationTreePlayer.NodeInputCount()
CollisionObject.ShapeOwner()

Sometimes you want a property to be able to be both get and set, but control access. In C#, properties allow you to do this and control access just by reading and assigning as if it was a field, which is nice.
 var thing = CollisionObject.ShapeOwner;
 CollisionObject.ShapeOwner = thing;

However, in GDScript, properties are not a thing (?). This could be possible if properties were added to GDScript. We could also have a method name without the word get. Most methods return something so it's better to have an implicit get-ness than set-ness:
 var thing = CollisionObject.shape_owner;
 CollisionObject.set_shape_owner(thing);

This does seem a bit inconsistent though.
In a nutshell, I agree that it's not good to have "get" in inconsistent places, but the ideal solution in my opinion is not really a possible at the moment in GDScript, or we could remove "get" and keep "set".

@aaronfranke GDScript does have properties in a way, since engine classes can define a getter and setter (or only a getter) and expose to GDScript as properties. That said, I'm against removing get and set from the methods because 1) it makes the name clearer and 2) it makes a distinction between getter and setter. For instance Mesh.SurfaceFormat() sounds like a method that "formats the surface", and not one that "gets the format". Also, most (if not all) of those can be ignored and used as properties instead anyway.
Now, I don't care that much about gdscript_function.cpp and gdscript_functions.cpp. One has the GDScriptFunction class, the other contains the definition of the GDScript functions, it's always clear to me which is which (though I'm used to it). It's also not a breaking change, so it doesn't need to be here.

There's a few methods for RigidBody and it's related classes whose parameters should be swapped:

RigidBody.add_force(force, position) to add_force(position, force)
PhysicsDirectBodyState.add_force(force, position) to add_force(position, force)
PhysicsServer.body_add_force(force, position) to add_force(position, force)

Class and method list

@TGRCdev I would vastly prefer changing apply_impulse to (force, position) rather than changing add_force to (position, force). Position of the force is an optional parameter so it should go at the end. But all forces and impulses must have a force vector.

@aaronfranke Fair point. In that case, the list of required swaps is:

RigidBody.apply_impulse(position, impulse) to apply_impulse(impulse, position)
RigidBody2D.add_force(position, force) to add_force(force, position)
RigidBody2D.apply_impulse(position, impulse) to apply_impulse(impulse, position)
PhysicsDirectBodyState.apply_impulse(position, impulse) to apply_impulse(impulse, position)
Physics2DDirectBodyState.add_force(position, force) to add_force(force, position)
Physics2DDirectBodyState.apply_impulse(position, impulse) to apply_impulse(impulse, position)
PhysicsServer.body_apply_impulse(position, impulse) to body_apply_impulse(impulse, position)
Physics2DServer.body_add_force(position, force) to body_add_force(force, position)
Physics2DServer.body_apply_impulse(position, impulse) to body_apply_impulse(impulse, position)

@aaronfranke I agree that using Get- or Set- prefixes is sort of a 'Javaism' which is better be avoided in C#.
My main concern was the usage of 'domain prefix' as in the case like shape_owner_get_shape or node_get_input_count, so if we can reimplement them as proper C# properties without Get- or Set- prefixes, it'd be even better.
On a side note, I always thought it rather odd that properties in Godot's C# API have matching set of getters and setters, like for example, Node.Name and Node.GetName()/Node.SetName().
It feels rather redundant to me, but if there's any reason why we keep such a convention, I suppose we would get both NodeInputCount and GetNodeInputCount()/SetNodeInputCount() anyway, if we are to rename node_get_input_count as suggested.

Guys, please keep discussions on the C# API and usual conventions outside this issue, which is focused on the Godot API. The Godot API (C++, C and GDScript) will not be adapted for C#'s sake, unless it's also an improvement for other languages.

@akien-mga You mean we should only discuss about simple return/argument type changes or list up those names still in snake_case here?

No, I mean anything C# specific should not be in this issue. There can be another issue for C#-specific compatibility breakages if need be (though there already are several of those IINM).

How about renaming Spatial to Node3D? I always found it weird.

@KoBeWi The naming scheme that Godot currently uses is "Thing2D" for 2D stuff and just "Thing" for 3D stuff, so it's fairly consistent with the rest of the 2D code. Of course then the logical thing to call "Spatial" would be "Node" following the pattern of removing "2D", but that name is already taken of course.
I quite like the name Spatial personally, so I would not change it. It might make more sense to rename Node2D to Spatial2D. It does seem inconsistent that the "Thing and Thing2D are 3D/2D counterparts" is broken here, so that would fix it.

The naming scheme that Godot currently uses is "Thing2D" for 2D stuff and just "Thing" for 3D stuff

So maybe change everything 3D to "Thing3D"? That crossed my mind too, but sounds like overkill.
Anyways, I just suggested. Not like it's very important. Also, Spatial2D is even worse than Spatial.

So, String.right() returns n right characters from given position. Wouldn't it be more intuitive if it returned just n characters counting from the right?
"abcdef".right(2)
Instead of "cdef" would return "ef". IMO it'd be better.

I expected the same.
Python has the same method most user like to compare GDScript with Python. It would probably confuse even more changing it.

@KoBeWi I agree. I don't see the difference between the current implementation and substring.

The Godot substr forces you to indicate the size of the string if you want everyting on the right.

@aaronfranke Um, but default arguments do exist. 0 or -1 could count as no length specified.

There are a lot of tween methods which return true every time, they should probably be made void.

WindowDialog.get_close_button()
ConfirmationDialog.get_cancel() -> ConfirmationDialog.get_cancel_button()
AcceptDialog.get_ok() -> AcceptDialog.get_ok_button()

What's the point of KinematicBody and StaticBody if RigidBody can be set to Static and Kinematic? https://godot.readthedocs.io/en/3.0/classes/class_kinematicbody.html#class-kinematicbody

The Tree node has a get_selected() function with seems to return the focused TreeItem. It might be worth to rename it to something like get_active(), since focus and selection are different things.

load_from_globals() in InputMap should be load_from_project_settings().

I'll add a :tada: reaction to all suggestions which have been integrated into the OP, to have a better overview.

global_rotate should be renamed rotate_global and rotate_object_local should be renamed rotate_local for consistency and so that all rotate methods start with "rotate".

global_rotate should be renamed rotate_global and rotate_object_local should be renamed rotate_local for consistency and so that all rotate methods start with "rotate".

Well, on the other hand I like that global-related function (like global_position, global_scale and global_transform) are next to each other in the auto-completion suggestions. Both solutions make sense IMHO.

Maybe tree_exiting could be renamed to tree_exited as it seems it cause some confusion by now. See #22840.

@groud There already is a tree_exited signal right?

@groud There already is a tree_exited signal right?

Damn you're right. I guess the request in #22840 is valid then

MenuItems.MENU_MAX is never used in LineEdit and TextEdit, should we remove it?

The Position3D and Position2D nodes are a bit ambiguous. Without reading the description, one might assume that they are like Spatial and Node2D but without rotation or scale. They should probably be renamed to PositionHint and PositionHint2D or perhaps some other word like Gizmo since it's a gizmo only in the editor or AxisMarker because it looks like a little axis marker.

Note that the same node in the Control tree is ReferenceRect, so, ReferenceAxis/2D might work as well.

Loving this issue right now. May hate it later when the breakage actually hits ;)
Some proposals for the humble Array class:

duplicate → either copy or clone. I don't know of any language that calls this concept "duplicating". copy is what it's called in Python and in C++ so it would be the natural choice for Godot. clone is from Java and JavaScript and is maybe a bit more precise.
invert → reverse.
remove vs. erase is confusing. Suggestion: remove_at and remove_value.

Note: Duplicate → copy/clone applies to Dictionaries also.

Rect2:

clip → intersection

AABB has intersection method but not clip, clipping generally means that we cut something out, which is not implemented in either class btw. Documentation describes it as:
Returns the intersection of this Rect2 and b.

Might as well rename:

intersects → overlaps
in order not to be confused with the actual intersection operation:

Returns true if the Rect2 overlaps with another.

grabber_area --> slider_progress
slider --> slider_background

Remove Resource::notify_change_to_owners, Resource::{un}register_owner.
They are used only by GridMap and CollisionShape, the rest of the code uses the "changed" signal.

Rect2: has_no_area should be renamed has_area that would prevent double negation logic checking the opposite in conditionals. Same applies to AABB: has_no_surface.

Building on what @lupoDharkael said, Godot has several places where double negatives are used. Errors like "Condition !Math::is_nan(x) is false" are confusing.

parse_input_event( InputEvent event )
Feeds an InputEvent to the game. Can be used to artificially trigger input events from code.
parse is misleading, parse would be receiving and processing but the description indicates sending or triggering an input

As per #24153 - CanvasLayer uses layer to describe what layer to draw its nodes on. But nearly every other 2D node uses the terminology "Z Index" (z_index) to describe (what appears at first to be) the same thing. As @swarnimarun suggested https://github.com/godotengine/godot/issues/24153#issuecomment-444950584 improving the names for layers.

Would OS.has_feature() / Platform.has_feature() be more sensible in something like ProjectSettings, since they don't exclusively convey anything about the OS?

set_cell_item can be renamed to set_cell to unify GridMap with TileMap ?

set_cell_item can be renamed to set_cell to unify GridMap with TileMap ?

Come to think of it, maybe there should be a set_cellv for GridMaps as well?

ARVRInterface:

ar_is_anchor_detection_enabled -> anchor_detection or similar
interface_is_initialized -> is_initialized or is_interface_initialized

AnimationPlayer:

play_backwards can be removed because play has an optional bool for that.

BaseButton / CollisionShape / CollisionPolygon / CollisionShape2D / CollisionPolygon2D:

Change the disabled bool to an enabled bool.

Bone2D:

get_index_in_skeleton -> get_skeleton_index

play_backwards can be removed because play has an optional bool for that.

That would be bad for readability, at least as long as #6866 is not implemented. It's not a problem in C# as it supports named parameters.

ID in id_pressed( int ID ) and id_focused( int ID ) should be lower case.

^
That change actually wouldn't break any compatibility. It could get a separate issue probably.

^
That change actually wouldn't break any compatibility. It could get a separate issue probably.

Really? But GDscript is case-sensitive, isn't it?

#28746 - Node.replace_by might be confusing as a name. Not sure what exactly could be a better name though.

@bojidar-bg maybe replace_self or swap_by? but I think that the only way to avoid any kind of confusion is by documenting it properly.

If I have a Node2D with a script attached that contains class_name MyNode2D, the get_class() method returns Node2D instead of MyNode2D. This might be intentional but it's confusing and misleading.

@aaronfranke get_native_class() perhaps? Then you could get the script name from get_script().global_name if it has one.

make_convex_from_brothers()
I guess "brothers" should be changed to "siblings", as that's the word used everywhere for sibling nodes.

ARVRPositionalTracker: get_type() -> get_tracker_type()

get_tracker_type() is more explicit - get_type() could be confused with get_class()

GetType() is already used for something else in C# as noted here.

Node.NOTIFICATION_TRANSLATION_CHANGED should probably become NOTIFICATION_LOCALE_CHANGED, as "translation" is used in Spatial nodes to mean "position" and not "language".

set_as_toplevel() could be renamed to set_as_top_level(), but its behavior should be looked at.

This should be looked at for 4.0, as it could be breaking: https://github.com/godotengine/godot/issues/28814

CanvasItem method:

RID get_canvas_item() const
Returns the canvas item RID used by VisualServer for this item.

Should be renamed to get_rid() then.
get_canvas_item() is confusing because I'm already at CanvasItem node. It also ensures consistency as other classes have similar get_rid() method already: CollisionObject, Resource.

Should Label be changed to TextLabel? Several times now I've wanted to put down a text object and forgot what it was called, so I search for "text" and only RichTextLabel shows up. TextLabel would be more consistent with RichTextLabel as it's still text but without the rich.

I've also been wondering about Tree and GraphNode being renamed TreeView and GraphEditNode.
For Tree, the reason is it's way too broad of a name for a GUI node IMO, all other GUI frameworks I know of use TreeView.
For GraphNode, it's because I worked on a few prototypes recently involving actual graphs structures, and I could neither use Node nor GraphNode which was quite annoying.

@Zylann since the Graph nodes are visual/controls for graphs (not trees), GraphContainer may be better. Not sure about about GraphNode.

Should we have lerpf & lerpv instead of Vector2/3.linear_interpolate? At least rename Vector2/3.linear_interpolate to Vector2/3.lerp

As mentioned in #29598  http_escape / http_unescape to uri_encode / uri_decode

Should we have lerpf & lerpv instead of Vector2/3.linear_interpolate? At least rename Vector2/3.linear_interpolate to Vector2/3.lerp

Shortening to vector.lerp() sounds good.  At least as of https://github.com/godotengine/godot/pull/16106 usage of lerp() in script has a switch to support vectors and colors.

Vector2.angle_to_point() should be renamed. It's name is not consistent with current description. Not sure what a good name would be, and whether this function is worth keeping.
Original issue: #16307

@razcore-art Already a PR open about this https://github.com/godotengine/godot/pull/20371, and it keeps backwards compatibility (I think).

Area should really be Volume, since it's 3D. And Area2D should then be Area. An area is 2D by nature.
GridMap should maybe be CubeMap. Not sure on this one, just that "grid" sounds like a 2D thing to me.
CheckButton control should be SwitchButton or something. It's confusing because there is also Checkbox. Or maybe it should be removed altogether. It serves the same function as Checkbox anyway, as far as I can tell.

I agree re: CheckButton, and the others are just cosmetic.

Or maybe it should be removed altogether. It serves the same function as Checkbox anyway, as far as I can tell.

UX-wise, CheckBox and CheckButton are different things, despite having the same functionality.
https://uxmovement.com/buttons/when-to-use-a-switch-or-checkbox/

@Rodeo-McCabe Area is called like that for consistency with the 2D counterpart, also one of the definitions of area is a particular extent of space or surface.
Cubemaps are 3D images, syntax correctness must be on context or it just add confusion.

grabber_area -> slider_progress
slider -> slider_background

or just:
grabber_area -> progress
slider -> background?

Maybe:
grabber_area -> progress_area or progressed_area
slider -> progress_background?

Cubemaps are 3D images, syntax correctness must be on context or it just add confusion.

Fair enough, I didn't know that.

Area is called like that for consistency with the 2D counterpart

The problem is the 2D counterpart is also inconsistent. In math an area is length * height, there just isn't any third dimension. So it doesn't make sense to say Area2D, because it should be 2D by virtue of being an area. Another, more mathematical definition of "area" is:

the surface included within a set of lines, specifically: the number of unit squares equal in measure to the surface

Similarly, a 3D space in math is called a "volume". I was confused at first when I found Area was actually a 3D node, instead areas were strangely called "Area2D". Being that this is a game engine, the math definitions are the ones we should take.

While I understand the reasoning, I don't know if there would be any particular benefit to changing the name, especially to new people. I do agree that "Volume" might be a more appropriate term for this, but I feel like having "Volume" for 3D and "Area" for 2D may be a little confusing. After all, a lot of nodes who have both 2D and 3D variants will be named "2D" and "3D", or just "" in some cases where the term being used would describe its 2D/3D nature on its own (i.e. "Sprite" instead of "Sprite2D", since sprite is already a 2D term, so we don't need the 2D suffix).
I think that the naming scheme being there in the first place (as much as there are some nodes who only mostly stick (rather than completely stick) to the scheme) means that we shouldn't have an exception to the rule, even where another term for one variant would make more sense, as otherwise it's likely to confuse users.

@Rodeo-McCabe I get the impression the node naming intention is to express things in human language and not mathematical.  So the "area" isn't meant to be a geometric one, but a place to be, like inside of a level or stage.  IE - Area 1.
The node itself doesn't directly have any geometry or is itself a geometry, so others like myself would wonder where is its area/volume when creating it, and then why would I have to attach areas and volumes (Shapes) to an area and volume?
If it were to undergo renaming to avoid confusing it with geometric area, synonyms would probably be the way to go.
They might be called:

Region2D/3D
Space2D/3D
Zone2D/3D
Field2D/3D
etc.

Btw, apart that this tracker is only for method, properties and signals (not Nodes), @reduz mentioned recently that there are intentions to minimize compatibility breakage on 4.0, so probably this huge list may need a review from core devs before we continue adding things ad eternum...

It sounds like the goal is to leave things much as they are right now, so stuff like this might be kicked back until the next major version after 4.0?

Please leave this issue for core contributors, it's not a place to make suggestions of big renamings all over the place, the aim is to fix actual inconsistencies that make the API cumbersome.
The changes outlined in the OP are not a big compatibility breakage and most will be done for 4.0, what @reduz referred to is compatibility breakage of the "your project can't be opened anymore" kind as between 2.1 and 3.0 (a lot more changed than just things getting renamed back then, such as the audio and particle systems being completely rewritten, the import system changing, etc.).
There will be some compatibility breakage in 4.0, otherwise it wouldn't be called 4.0. It will be reasonable and porting will be easy, likely with a converter to ensure that renamed properties, methods and signals are properly converted if used in scenes and scripts. It's not the place to discuss it in any case :)

Control's _set_anchor() should also drop the beginning "_".

PopupMenu's has index_pressed(index) and id_pressed(id) which work fine, but also id_focused which is actually emitted with the index instead of the id of the item.

No issue for this yet but after suggesting it to Akien today worth putting on the list.
Refactor the ARVRServer so it is called the XRServer. When we designed it the term XR to indicate both VR and AR wasn't in wide use yet. And no, I'm not going for MRServer ;)

I suppose XR could also be used to mean all of AR/VR/MR. Though it would be funny to have "Mr. Server".

Should RayCast have a "Disabled" property instead of "Enabled"? CollisionShape uses "Disabled" (which is false by default), which makes them enabled by default. In contrast, RayCast's "Enabled" property is false by default, making them disabled by default.

@Calinou I dunno if that would require a separate issue, but I'd really prefer such booleans to be Enabled always. Setting a boolean to true to disable something confused me often.

@Calinou I disagree, and agree with @Zylann double negatives are confusing and should be avoided whenever possible. We should instead change "Disabled" bools to "Enabled" ones. It's fine if the default value of something is "true". I had this discussion in #17212 and #21822.

The speed property of the mouse and touch input events should be renamed to velocity since it's a Vector2.

InputMap: get_action_list( String action ) the function name doesn't tell much about what it does.
Also InputMap has another function called get_actions( ) which can cause confusion as both function names could mean the same thing out of context.
Since get_action_list( String action ) returns the EventInputs associated to a given action, it could be get_action_events(String action)

Tangentially related to #30736, we should rename the two Godot physics engines to something like "GodotPhysics2D" and "GodotPhysics3D", since saying that something's broken with "GodotPhysics" entails two very different things.

What about renaming Object._init() to Object._new()?
get — _get
get_property_list — _get_property_list
notification — _notification
set — _set
new — _init

I guess _init  actually followed Python's __init__.

Is something like String: empty() -> is_empty() a good fit for this thread? I always think it's a function to clear a string at first.

@vortexofdoom if talking about method name inconsistencies and/or how they should be named, then yes.
I could add that String and NodePath have empty and is_empty methods respectively which do the same thing. The rest of the core built-in types seem to prefer empty name so maybe is_empty could be renamed in NodePath to make this consistent across all built-in types, but this could potentially involve some serious compatibility breakage I think.

I always think it's a function to clear a string at first.

Most methods use clear name in Godot for that.

@Xrayez,

Most methods use clear name in Godot for that.

I know, just referring to the fact that empty is a verb as well as an adjective, and adding is_ makes clear which one is meant.
I'd be in favor of using is_empty across all built-ins for that bool.

In Godot 3.0 and 3.1, we had Set methods in C#. However, these actually didn't add any actual functionality compared to just using a constructor and assignment, yet allowed code to silently fail, so they've been obsoleted. They were mostly added by me to try and be consistent, since a method for Quat already existed, which came from core having set methods. For more info see #30744
GDScript does have set_euler and set_axis_angle, but there are also constructors for doing the same thing (q.set_axis_angle(myvec3, myval) can be replaced with q = Quat(myvec3, myval). Core also has these methods for Basis, but they're not exposed to GDScript.
The question is then, what should be done about this? Should the Quat set methods be deprecated in favor of constructors and to be consistent with C#, or is it worthwhile to keep them to be explicit about the operation being performed? If the latter, should the Basis methods be exposed too?

@aaronfranke I always found it strange those constructors had dedicated methods when basically nothing else does, so I'm for taking the former route if possible.

@akien-mga raised a concern here that there is some inconsistent logic with including/excluding files in disabled addons. I'm not sure what, if anything, should be done, but it should be looked at for 4.0.

@aaronfranke This issue is about renaming things in the API, not engine functionality or bugs.

Geometry's point_is_inside_triangle() to is_point_inside_triangle(), to match the other methods that also return bools in the same class.

TreeItem.get_children() should be renamed get_first_child(). The doc should also explain that it's NOT returning the child items.

From working on #31976, I noticed the shadow atlas value must be a power of 2 (both for directional shadows and omni/spot shadows). However, the methods accept any integer value; if it's not a power of 2, the method will round it up to the nearest power of 2. We should probably make it accept an enum of values, so it can be presented in an user-friendly manner in the Project Settings.
Likewise, the anisotropic filtering level should be an enum, since only power-of-two values make sense here.

VisualServer's instance_create2() should be changed to actually describe what it does differently than instance_create().

For object-relative translations, Spatial has translate_object_local which takes a Vector3, and Node2D has move_local_x and move_local_y, which take floats. Both Spatial and Node2D should have methods that take Vector3 and Vector2 respectively, and either translate_local or local_translate would be simpler names than translate_object_local.

@leonkrause Instead of render_width and render_height it would make more sense to call it viewport_width and viewport_height, or perhaps canvas_width and canvas_height, since it's the reference resolution used for the canvas viewport, and doesn't actually affect rendering.

@akien-mga please consider adding the Tree navigation methods to your list. They are very confusingly named and not well documented.
When I first encountered them I thought get_child() and get_next(), get_prev() operated an iterator much like they way Directory works. I had to do my own testing to find out that all they do is produce the pointer same pointer each time they are called.
get_children() should be renamed to get_first_child().
get_next() and get_prev() should be renamed to get_next_sibling() and get_prev_sibling()

What about renaming Engine.iterations_per_second to Engine.physics_fps for consistency with the Project Settings?

is_processing:

Returns true if processing is enabled.

can_process:

Returns true if the node can process while the scene tree is paused

It might be better to rename can_process to something like can_process_paused to avoid confusion with is_processing method.

JSON
----
String print( Variant value, String indent="", bool sort_keys=false )

I think this method should be renamed.

@dalexeev What should it be renamed to, and why?

@Calinou This method does not actually print anything to the screen; it returns a string. The first thought is that JSON.print works just like Node.print_tree or OS.print_all_resources or like all other print* methods.

What should it be renamed to? I'm not sure. JavaScript uses JSON.stringify for this. PHP has a json_encode function. Directly in GDScript there is a similar function - to_json.

I would suggest against the word "serialize" since that's usually used for binary serialization, and such an output would need to have further steps to get in that form.
Since this class only has two methods for going between JSON and Variant types, I would suggest against methods containing the word json since it's pointless.
Now, for things that would be a good name, the existing parse method doesn't really have a clear opposite word (see here). Perhaps one of these: encode, create, compose, generate?

I've seen format and write being used as an inverse of parse. stringify has the benefit of being better-known among developers due to being used in JavaScript, however.

I've seen format and write being used as an inverse of parse. stringify has the benefit of being better-known among developers due to being used in JavaScript, however.

str2var is VariantParser and var2str is VariantWriter internally (see #33241 for instance, I've even used the same term to describe it).
So I'm for write, consistency wins. 😛

@Xrayez Change print to write? From Python to Pascal? :laughing:

As suggested in https://github.com/godotengine/godot-proposals/issues/252#issuecomment-557901552, it might make senses to rename everything related to clear_color to background_color (including the Project Settings).

I would expect 4.0 to bring a big wave of new people into Godot due to better performance, GI probes improvements, general hype and so on.
If those changes are made with 4.0, these people will get a hard landing as almost no tutorial (besides the official "first game" tutorial) will work for them anymore.
If those changes are made after 4.0, lets say in 4.1, it will be an extremely bumpy ride for those people. As they just learned basics a new engine, which they now have to relearn again. Beginnings are hard, having to go through this twice to shortly after another can be frustrating enough to give up altogether.
Would it therefore not make sense to have a "3.3" or "3.9" version before the 4.0 release that has all those compatibility breaking API changes, however gives the tutorial creators enough time to create some tutorials before expected massive influx of new users?

Not sure if this is the right place or not but since this could be a possible partial solution to renaming issues I will pitch it here.
Why not make all the renaming changes that are required and then add a new language to translations called GodotOldNames/GodotPre4.0 which has all old names for all the changes.
This way in case someone doesn't find the old names present in old tutorials, they can just change language to GodotPre4.0 . This would also make switching to new names easier.
This doesn't solve the whole problem but might work along with #4397.

@Anutrix This adds a lot of complexity (what about non-English languages?). Moreover, not all strings displayed in the editor are localizable in the first place.

Physics "Layer", Render "Layer"
I remember going exactly through the same confusion as this poor person during my first few weeks of learning Godot.
Physics "Layer", Render"Layer" might make sense to someone coming from Object Orientated Design, but to anyone else it's very confusing. The term "layers" is used when describing multiple coatings of paint, or coats of cloth in a fabric, coats of skin on an onion (or ogre), coats of sediment on the planet surface, ...
Layers (plural, opposed to a single layer), seem to imply being stacked on top of each other.
For many people "layering" especially when working with 2D implies working with a foreground, background, and layers in between or on top. Many people think of layers as celloloid films on top of a background, when in fact Godot like many other game engine uses "sorting" to accomplish this task.
The fact that layers with Physics "Layer", Render "Layer", while at the same time have nothing whatsoever to do with the visual appearance (that's "sorting"), at nothing to do with the stacking properties of any "layer" association outside of OOD is what makes this so confusing to some.
When I understood the real use and meaning of Physics "Layer", Render "Layer", I immediately wondered why these are not Physics Group, Render Group, and to be honest, I still don't know. They certainly don't have any ontop-stackable relation to each other, meaning their order or relation to each other is completely irrelevant. Naming them layer, imho archives nothing but confusing people, "group" would be more accurate.

AnimationPlayer method
.stop(false) should be called .pause()
because that's what it does.

Project > Project Settings > Display > Window > Stretch > Mode:
Stretch Mode "2D" should be called Stretch Mode "display", or "general purpose"
because it's confusing to call it 2D when it works just as well for 3D usecases, but not really well for all 2D usecases (like pixelart projects)
"display" would also be more descriptive for what it actually does: Rendering stuff like 3D objects, 2D meshes, Line2D and Polygons at the display resolution.
More on that here.

loop, repeat, oneshot, of animationplayer, timer, and similar nodes, could be clarified.
looping, repeating, and not being a oneshot, are all the same things.

I think that
is_a_parent_of()
should be renamed to
is_parent_of()

@KoBeWi see discussion at #19801.

I think that
is_a_parent_of()
should be renamed to
is_parent_of()

I don't think so, is_parent_of() suggests it only takes into account the first parent, while the function checks for all parents recursively.

@groud In that case, it should be called is_ancestor_of(). If there's also a corresponding function for the other way around, then it should be called is_descendant_of().

@groud In that case, it should be called is_ancestor_of(). If there's also a corresponding function for the other way around, then it should be called is_descendant_of().

Yes, but thinking about it there is not much of a need to have both functions, as the difference would only be a matter of switching the "calling" object and the function argument. Maybe we could simply replace the function by something like is_descendant_of() and we're done .

We may want to rename push_error() and push_warning() to print_error() and print_warning(). This would make them more discoverable thanks to autocompletion :slightly_smiling_face:

@Calinou print_error() might be confused with printerr()

Please, consider changing the name of TreeItem.get_children() method, as the name implies a collection of children to be the return value, when in practice it is the first child that is returned and then you have to iterate over the rest of them using get_next() (as described in #19796).

Quoting @Zylann from #31404:

[Rename rpc() / rset() to] remote_call() / remote_set()?
Those methods have really short names as well, not sure if an alias is enough. You gotta really do multiplayer a lot with tons of these calls per script to justify 3-character identifiers (which I'm sure majority of games don't).

Following methods
OS.find_scancode_from_string
OS.get_scancode_string
OS.is_scancode_unicode

should be moved from the OS class to the Input class for consistency with the methods:
Input.get_joy_axis_index_from_string
Input.get_joy_axis_string
Input.get_joy_button_index_from_string
Input.get_joy_button_string

TabContainer should have its tab_close and tab_hover signals edited as well.

LightOccluder2D light_mask -> occluder_light_mask
CPUParticles Flags enum -> ParticleFlags
ARVRPositionalTracker get_type -> get_tracker_type
ARVRPositionalTracker get_name -> get_tracker_name
PathFollow2D rotate -> something else
ArrayMesh ArrayType enum -> delete this
Mesh BlendShapeMode enum -> give to ArrayMesh

Explanations in https://github.com/godotengine/godot/issues/15763

RichTextLabel's meta_hover_started and meta_hover_ended signals should be renamed to match most other similar naming conventions: meta_hover_entered and meta_hover_exited. Not only does this make it more closely imitate the rest of the Godot API, but the current naming scheme, due to alphabetic sorting, causes their order to be reversed. This is disorienting a bit when you are reading the docs since, clearly, the chronological flow of operations is to first enter and then exit. It just all around improves readability and consistency to change it.

another inconsistency with physics body signals
Area:
area_shape_entered( int area_id, Area area, int area_shape, int self_shape )
area_shape_exited( int area_id, Area area, int area_shape, int self_shape )
body_shape_entered( int body_id, Node body, int body_shape, int area_shape )
body_shape_exited( int body_id, Node body, int body_shape, int area_shape )
i suppose area_shape should be self_shape ? or ...
Rigid Body:
body_shape_entered( int body_id, Node body, int body_shape, int local_shape )
body_shape_exited( int body_id, Node body, int body_shape, int local_shape )
here it is called local_shape ...

@FrederickDesimpel As far as I know, arguments can be renamed without breaking compatibility. Feel free to open a pull request for this :slightly_smiling_face:

In Variant:
Real -> Float
Nil -> Null?

I like the "real" name personally, since the term "float" is often used for 32-bit floats specifically, but Variant's real is a double, and most of the engine uses real_t which can be either.

Did we consider renaming these:
shader_type canvas => shader_type 2d
shader_type spatial => shader_type 3d
CanvasItemMaterial => Material2D
SpatialMaterial => Material3D

@Zylann SpatialMaterial was already renamed to StandardMaterial3D in master.

Should the limit_ values on Camera2D be changed to a Rect2i? Right now they're just four ints.

String::begins_with to String::starts_with.
Like in serious programming languages (Java, Python etc).

InputEvent.is_action_pressed to InputEvent.is_action_just_pressed
InputEvent.is_action_released to InputEvent.is_action_just_released
https://github.com/godotengine/godot-proposals/issues/316#issuecomment-589426014

Although the word "just" is missing, event.is_action_...() corresponds to Input.is_action_just...().

We should probably swap Node.add_child_below_node()'s first two arguments so the first argument is the same as Node.add_child(). See #19642.

semantical atelophobia speaking…

Should Node2D.draw_circle be Node2D.draw_disk since it draws a disk and not a circle?
Node2D.draw_circle could still exist as a shortcut for draw_arc from 0 to TAU.

@Goutte In English, "circle" can refer to either a hollow circle or a filled circle. I think the current name is more discoverable, so I wouldn't change it.

In English, "circle" can refer to either a hollow circle or a filled circle.

I can't find anything supporting this.  Do you have any source for this claim or is it a gut feeling?
About discoverability, we can still have draw_circle, it would simply draw a circle, and not a disk.

I can't find anything supporting this. Do you have any source for this claim or is it a gut feeling?

https://www.merriam-webster.com/dictionary/circle

1 b : a closed plane (see plane entry 6 sense 2b) curve every point of which is equidistant (see equidistant sense 1) from a fixed point within the curve
1 c : the plane surface bounded by such a curve

(1 b) is a mathematical circle (perimeter), (1 c) is a mathematical disk (surface).

Nice, thanks.  Most of my students are french and all of them were confused by this, and so was I, and they blamed Godot and I could not let them, of course.

what would be the mathematical name for a filled rectangle?

That's a pretty good question ; all I can find is "rectangle area" or "rectangle interior", and none is adequate.  The wiki even states that most people abuse the term polygon to mean the interior of a polygon, without providing another word for it.
I guess a filled argument could help alleviate the ambiguity, but it's going to be a pain to decide where to put it in the list of arguments.

@Goutte but it's going to be a pain to decide where to put it in the list of arguments.

Since it's an optional argument (it has a default value), and also for consistency with draw_rect, it should go at the end.

There are cases in which Control nodes are refereed to as Modal nodes. https://github.com/godotengine/godot/search?q=modal&unscoped_q=modal Mostly in relation to the Viewport.get_modal_stack_top() function

EditorInterface's get_selected_path and get_current_path methods are confusing in name and in function. They also lack documentation.
These methods are just a thin layer on top of FileSystemDock's methods of the same name:
String FileSystemDock::get_selected_path() const {
	if (path.ends_with("/"))
		return path;
	else
		return path.get_base_dir();
}

String FileSystemDock::get_current_path() const {
	return path;
}

They should both adapt either "selected" or "current" (or something else, but for both of them) with one being get_*_path and the other get_*_dir.

@Goutte Isn't Solid Rectangle an alternative to filled rectangle?

Will the OP be updated with suggestions posted after the June of 2019? I understand that this is a lot of work, but this type of tracker is also perfect for contributors to tackle together. And I assume it's already the time when we can get to work on renaming more stuff?
Updating OP would also mean that the suggestion posted is accepted as worthwhile by the team.

@Anutrix "filled" is a better word to use than "solid", because "solid" can mean "not liquid or gas".

I don't know if it was raised, but I didnt realise how often I peek into the doc for this one:

Array.remove => remove_at, or erase_at
or
Array.erase => remove_value or erase_value

Because right now, erase and remove mean the same to me, except one is by index, the other by value, I keep forgetting which is which.

@Zylann Here you go: https://github.com/godotengine/godot/issues/16863#issuecomment-441376010

Seconding Zylann, I keep forgetting that remove is by index...

The ButtonList enum likely should be renamed to MouseButtonList since they are mouse buttons.
Should the JoystickList enum be split up? It contains both buttons and axes, it might make more sense as JoypadButtonList and JoypadAxisList or similar.

Just a question, why not MouseButton?
if button == MouseButton.LEFT:
reads nicer than
if button == MouseButtonList.LEFT:

Good idea. In that case, there's also KeyList -> Key, MidiMessageList -> MidiMessage, and the joystick ones need to have List removed.

I noticed some methods/properties use normal_map, whereas others use normalmap. We should settle on either of these, but probably not both.

GDScript
range_lerp() = map()
seed = set_seed()

map() is probably reserved for the new functional programming features.

Vector2.tangent() is described in the docs as Returns a perpendicular vector., that's the definition of orthogonal or orthonormal if the returned vector is normalized. Vector2.tangent(). Since Vector2.tangent() returns a non-normalized vector I propose we should rename it to Vector2.orthogonal() or even Vector2.perpendicular() if people have something against math nomenclature.

Anecdotal on my end, but my first time looking for this, my first searches in the docs were for perpendicular.

You could also keep .tangent() as just an alias for .perpendicular(), no?

I don't like the name orthogonal because it's not a common English word compared to the others. I didn't see a problem with tangent before, but I think perpendicular is a better name anyway.

Yeah, orthogonal is rare. I vote for .perpendicular() but KEEPING the tangent() alias for compat as well as, it's shorter.

@Zireael07 I would prefer if we only had one way to get the tangent. I don't think it's a very common operation after all.

You'd be surprised how often I use it in my procgen scripts :)

I didn't expect this to spawn a debate, but I'm personally against keeping Vector2.tangent() since it's an incorrect usage of the usual math term. The product of Vector2.tangent() is just wrong by definition. The name of this thread is next planned compatibility breakage so I don't see any reason why we should bend over backwards to keep compatibility. I'm personally fine with Vector2.perpendicular().

Suggestion: make find_node()'s owner parameter false by default.

Suggestion: rename Tree's methods/signals to be less confusing with regard to e.g. terms/statuses of "selected", "focused", and "nothing".

I think Tree::ensure_cursor_is_visible is misleading and should be renamed to something like ensure_focused_item_visible or ensure_selected_item_visible

Script::get_instance_base_type() specifically returns the native type underneath. Now that we have named script classes, it makes more sense for this to be renamed to get_native_type() since the "base" of the script could potentially be the name of a script. It's misleading.

@willnationsdev There's also get_class() https://github.com/godotengine/godot/issues/16863#issuecomment-491421079

@aaronfranke Well, with get_class() it's universally used to refer to "what is the name of the thing I am currently looking at?". So, in the case of a Script, I would expect to get back "GDScript", "CSharpScript", or something of that nature. But yes, with non-Script classes, it should be a method that returns the name of the actual script class if it is named. There's even a dedicated issue for it. https://github.com/godotengine/godot/issues/21789#issuecomment-618588900

I think autotile_coord (properties and methods) of TileMap should be renamed for tile_coord because both AUTO_TILE and ATLAS_TILE use this and the name may be confusing for new users. Docs also will need an update. I can make this change if there is no problem.

Consider removing new_text argument from LineEdit.text_changed since it has the same behaviour as LineEdit.text.
Also consider adding old_text either in addition to or as a replacement of new_text.

Rename "collision layers", "VisualInstance layers", "Render Layer", ect to "Collision group", "VisualInstance group", "Render group", "Light group"
Confusion about why those "Layers" are not stacking comes up like minute clockwork on the community channels.

Note that they are called layers in Maya, Lumberyard and Unity.

Just because someone else for something doesn't mean it still doesn't cause
confusion and is a good idea.
On Mon, May 18, 2020, 1:09 PM Jummit notifications@github.com wrote:

Note that they are called layers in Maya, Lumberyard and Unity.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/16863#issuecomment-630349336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBEIS43HMTPCIFY4GYYK3LRSF2UTANCNFSM4ERRCEZA
.

I'm surprised that no one mentioned it yet buuut
Camera2D.zoom
the camera is zoomed out when the zoom is greater, which is not how "zoom" works and it's counter-intuitive. Not sure how to name it, maybe view_scale or something similar.

@KoBeWi Instead of renaming zoom, shouldn't we invert its scale so it zooms in when you increase the value?
This will break compatibility just like renaming the property anyway.

@Calinou @KoBeWi Is there a use-case for using this zoom property directly though, or would everyone need to invert it each time to apply to scale?

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ?

Viewport.get_final_transform() => Viewport.get_final_transform_2d() ?

Maybe, but where do we draw the line with that and something like Node2D.get_position_2d()?
Maybe we could name the class Viewport2D but that wouldn't be required unless we make a Viewport3D.

@nathanfranke I proposed this method because in the name alone there is no way to tell if it's 2D or 3D, considering there are 2 types of Transform.

@Zylann This method is actually really weird. There are properties called canvas_transform and global_canvas_transform, and the description of canvas_transform is this:

The canvas transform of the viewport, useful for changing the on-screen positions of all child CanvasItems. This is relative to the global canvas transform of the viewport.

So, you would expect get_final_transform to get both of these transforms combined. However, if you look at the code, that's not actually what it does.
The code for this is return stretch_transform * global_canvas_transform;. I've been trying to figure out what stretch_transform is for and I have no idea, it's not exposed, and it's certainly not set when changing canvas_transform. There is also a method called _stretch_transform which does not use stretch_transform. It's called by set_size, which takes the value generated by _stretch_transform and assigns it to stretch_transform. There's also canvas_transform_override which I haven't even mentioned, does Viewport need four Transform2D values?
In the end I think this whole class should be looked over. I don't see why Viewport needs 4 different Transform2D members, 4 Rect2(i) members, 9 Vector2(i) members, and 2 Transform (3D) members. That's already 264 bytes (with single-precision floats) of just data structures storing the transformation information, if you add up all the pointers and such it's probably closer to 1 KB. Maybe Viewport does need all this, but it seems overcomplicated, and at the very least there should be comments (there are far too few in this file).

Should Node2D/Node3D to_global and to_local be removed? I gave feedback on #38902 which proposed adding methods that only work with the basis, but there are some issues with these.
In the demo projects, to_local is not used anywhere, and $ grep -RIn "to_global" returns only 5 results, all of which are in the GUI in 3D demo, and the performance of the demo could be improved by changing this so that it caches the global transform and uses xform instead of using to_global.
In a nutshell, the concern with these methods is both that they are uncommonly used, and also that they encourage writing code that performs bad since it recalculates the global transform several times.

#27509
AnimationPlayer's animation_started and animation_finished are a bit counter-intuitive. The first one is called for all animations in the queue while the latter is only called on reaching the very end of the queue. It isn't clearly mentioned in the documentation.
If we want to detect when any particular animation ends, we have to use both animation_changed and animation_finished which isn't convenient.
I really like @txigreman's suggestion from that issue: We can use animation_finished whenever any single animation in the queue ends and add a new signal animation_all_finished(similar to Tween's tween_all_completed) which fires only when we reach the queue's end.

What about animation_queue_finished and animation_queue_started?

I can't find it here so I would propose,
find and findn pair.

image from 3.2 last stable build.
Maybe we can rename one to mention their nature of dealing with case sensitivity.
Say, find_ignorecase instead of findn?

@swarnimarun We have many other case-insensitive methods ending with n. If we rename one of them, we should rename all of them.

These methods (find/findn etc.) basically do the same. We could just add an argument whether they should be case sensitive or not.

@Calinou I would very much prefer that, using GDScript after dropping it for a few months kinda has given me a new perspective to the API I would say,
The more obvious the better. Remembering the API for everything is hard on its own, a bit more verbosity in the naming of functions seems like a sane change.

@KoBeWi being able to tell with the function name what it does rather than having to remember to add another field or while reading code(after forgetting/not-knowing that part of the API) is quite appreciated.
So I would still prefer a different function, even if the other function just calls the first one with different arguments or something.

EditorInterface.get_editor_viewport() => get_editor_main_container()
This function does not return a Viewport, only a Control which happens to be the central one holding the 2D, 3D, Script editors and the Asset Library. For the record, the returned node is even a VBoxContainer*, but is abstracted away (yet it's important to know, because it affects your choices of settings).
The doc is also wrong, as its description links to the Viewport class. https://docs.godotengine.org/en/stable/classes/class_editorinterface.html#class-editorinterface-method-get-editor-viewport

@Zylann Should be get_editor_main_screen() since it's not a container, but it's the main screen.

@aaronfranke which is also a Container node, actually^^ but yeah... main screen can work too

I want to ask: does anyone track proposals in this topic?
For example, above (https://github.com/godotengine/godot/issues/16863#issuecomment-557657413) I proposed renaming the JSON.print method. Several options were suggested, but none of them appeared in the first post.
I'm just worried that useful ideas get lost in so many posts. :smile:

@dalexeev I took a first pass at updating the first post recently, but I didn't quite go through all comments yet.

I have one that potentially fixes some bugs in RichTextLabel. Currently we have bbcode_text and text, but both use internally the same data structure. Only the called methods are different, while set_bbcode falls back to set_textwhen use_bbcode is not enabled. So I went ahead and removed them in  #39148. I added some other points there.

GetSceneInstanceLoadPlaceholder() in Node look very wrong, first it doesn't return a placeholder as the name may suggest, but a bool and secondly this leaks details of inherited implementations into the base class with no real requirement (testing for the type of the node is possible in other ways)

RayShape → SeparationRayShape, as initially suggested in godotengine/godot-proposals#711.

How about removing sort_custom and making sort take an optional Callable?

Should we remove OS.get_ticks_msec() and OS.delay_msec() in favor of OS.get_ticks_usec() and OS.delay_usec() respectively? This would avoid having two ways to achieve the same thing. If you need a value in milliseconds, you can multiply it or divide it by 1000.
Also, both GDScript and C++ allow adding separators in integer literals, which makes large values more readable.
# Since Godot 3.2.
OS.delay_usec(123_456_789)

// Since C++14.
OS::get_singleton()->delay_usec(123'456'789);

Also, both GDScript and C++ allow adding separators in integer literals, which makes large values more readable.

If the removal happens, get_ticks_usec() description should mention the separators.

@Calinou On the one hand, you are right, but on the other - in most cases, such great accuracy is not required.

'Alpha scissor' should become the standard 'alpha clip'

@Flavelius I haven't seen the term "alpha clip" used often. I've seen "alpha test" used much more often than both "alpha clip" and "alpha scissor" for sure, though.

That's a lot of stuff to change! Is someone working on implementing these suggestions?

@MCrafterzz People open pull requests to rename things on a regular basis. This is done incrementally rather than all at once.

To get an image from Texture you need to use get_data() and to get a PoolByteArray (or PackedByteArray) you use get_data() on that image.
It should be named get_image() and get_bytes() to be self-describing.

IMO: get_image yes, get_bytes no.
texture.get_image().get_data()

authors: AlexHolly AnEnigmaticBug Anutrix BastiaanOlij Calinou Chais Chaosus Coldragon DualMatrix FeatherAntennae Flavelius FrederickDesimpel Geequlim Goutte HaSa1002 Jummit KoBeWi LikeLakers2 MCrafterzz MightyPrinny Rodeo-McCabe Sslaxx TGRCdev TheDuriel Two-Tone Xrayez YeldhamDev Zireael07 Zylann aaronfranke akien-mga avencherus bojidar-bg chrisb123 dalexeev eon-s eska014 follower golddotasksquestions groud guilhermefelipecgs hilfazer homer666 isaacremnant jabcross jmf lupoDharkael menip merumelu mwerezak mysticfall nathanfranke neikeq pycbouh razcore-art reduz romeojulietthotel swarnimarun ttencate vnen vortexofdoom willnationsdev


text:
Add support for 3D textures

I'll see if I can find time to tackle this myself, for now I'll work around it with a slightly costly 2D texture with slices, but with more and more techniques relying on GL_TEXTURE_3D to do lookups in a 3D texture, especially where procedural materials are concerned, it would be nice to have support for this :)
Any input given on how to best add this into the engine and whether there are platform concerns I need to be aware off would be very welcomed :)

Can you give an example of what 3D textures are and when/how they are useful?

I second this.
@aaronfranke They are just textures with another dimension, so you have width, height, and depth. This would enable stuff like

volumetric effects, like smoke, fluid, etc
GPU based voxel terrain rendering/generation
GPU based 3D particle collision

And many more interesting things.

@aaronfranke it's for doing stuff like this:
https://www.youtube.com/watch?v=y7tQTtODTZ8
Here I've 'faked' it by putting slices underneath each other in a 2D texture but it means I can't use the optimizations in the GPU for doing 3D texture lookups with filtering.
But you can do many more nice things with it

@akien-mga I guess this should be closed via b4d3f541e761d257199104a10f53260fa149690c

There's also edde52c8dea0193111239b6b2f002adcc24ac0c9 which broke other things but may have fixed this issue.

So is there any documentation for this feature? What 3D texture formats are supported?

source: gharchive/issue

authors: BastiaanOlij Bauxitedev Chaosus aaronfranke

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
SCons wrongly expects suffix in library include path when building module

Godot version: 861d341dffe7c8cd1f6faafffbc51746ac5e3564
OS/device including version: Microsoft Windows 10 Pro 10.0.17134 Build 17134
Issue description:
When appending a library name to LIBS in the SCons environment, e.g. env.Append(LIBS=['mysqlcppconn']) there results an error when compiling for Windows (haven't tested any other OS):

LINK : fatal error LNK1181: cannot open input file 'mysqlcppconn.windows.tools.64.lib'

Instead of finding mysqlcppconn.lib, which exists, it instead looks for the given library with the added suffix .windows.tools.64.lib in its path.
Renaming mysqlcppconn.lib in the C:\Program Files\MySQL\Connector C++ 1.1\lib\opt directory to mysqlcppconn.windows.tools.64.lib resolves the issue and compiles fine.
Steps to reproduce:
Append library_name_here, can be any library, to LIBS and compile with platform=windows.
Compilation then gives following error:
[ 97%]  cannot open input file 'library_name_here.windows.tools.lib'
If you rename library_name_here to library_name_here.windows.tools.lib it will compile fine without any related warnings or errors.
Minimal reproduction project:
I think it's possible to reproduce with any custom module on Windows where the SCsub references an external library. Here's the SCsub I used:
Import('env')

env.add_source_files(env.modules_sources,"*.cpp")
env.Append(CPPPATH=['C:/local/boost_1_64_0x64'])
env.Append(LIBPATH=['C:/Program Files/MySQL/Connector C++ 1.1'])
env.Append(LIBS=['mysqlcppconn'])

Zip file containing the custom module

You can clone the environment (see how existing modules do it in modules/*/SCsub), and reset the env_mysql["LIBSUFFIX"] to "".
But there might be a less hacky way, or indeed something that needs to be fixed in our buildsystem, I'll look into it.

Just to give some context, this suffix happens because of those lines: https://github.com/godotengine/godot/blob/0aa7fcd41042f4ba96b259c438e5ea3d220c6cc9/SConstruct#L410-L413
We define those for the build outputs of our compilation, so that intermediate static libraries have all the required information to identify the target platform and config (and to avoid them being overwritten when compiling for several platforms/configs in the same tree). For example modules/libmodules.x11.tools.64.a for the modules library on 64-bit Linux with tools=yes.
But indeed we don't want those to also apply to thirdparty static libraries that we would be linking in a custom module. Maybe there's a cleaner/more idiomatic SCons way to achieve that.

@garyo May I ask for your SCons expertise here? Would there be a cleaner/more idiomatic way to add such suffixes to our own build objects without impacting the lookup of thirdparty static libraries with the LIBS env variable? Note that the current system works just fine for linking shared libraries.

LIBSUFFIX is appended to built static libraries' names, LIBSUFFIXES is used for lookup.
LIBSUFFIXES defaults to LIBSUFFIX, so standard suffixes should be append to LIBSUFFIXES.

Yes, that's similar to what I was going to suggest.

Thanks for the confirmation :) I've pushed #20380 to fix it.
@intra32 Could you test this PR and see if it fixes the issue for you?

After a rebase of my Flex implementation I'm not able anymore to compile it... This is my SCsub file: https://github.com/AndreaCatania/godot/blob/flex/modules/flex/SCsub
I know that this is not so well written, but now what do I have to change in order to make it compile again?

In order to make it compile I've added this line to my file:
env["LIBSUFFIXES"] = ""
can you please explain me better what it does, so I'll be able to write a proper SCsub file?

From the man page:
LIBSUFFIXES
A list of all legal suffixes for library file names. When searching for
library dependencies, SCons will look for files with suffixes, in the
$LIBSUFFIXES list, the base library name, and these suffixes.
(actually the man page has a couple of typos here, which I've fixed above.)
On Mon, Aug 6, 2018 at 4:25 AM Andrea Catania notifications@github.com
wrote:

In order to make it compile I've added this line to my file:
env["LIBSUFFIXES"] = ""
can you please explain me better what it does, so I'll be able to write a
proper SCsub file?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/20045#issuecomment-410628482,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIixxwQzkcdG3d7zY2Xx-6TZ_rkoknzks5uN_1wgaJpZM4VGwo3
.

--
Gary

@akien-mga Hi. Sorry for late response, couldn't get GitHub notifications working. It works, but no longer finds sub directories in my LIBPATH variable. I must now include them like this:
'C:/Program Files/MySQL/Connector C++ 1.1/include'

instead of just including the root directory like such:
'C:/Program Files/MySQL/Connector C++ 1.1

Should I create a new issue for this?

@akien-mga Hi. Sorry for late response, couldn't get GitHub notifications working. I have two issues from this on Windows 10; one is that I must still include the libsuffix in the file path, otherwise it gives this error:
LINK : fatal error LNK1181: cannot open input file 'mysqlcppconn.windows.tools.64.lib'

But in addition it no longer finds sub directories in my LIBPATH variable. I must now include them like this:
env.Append(LIBPATH=['C:/Program Files/MySQL/Connector C++ 1.1/lib/opt', 'C:/Program Files/MySQL/Connector C++ 1.1/include'])

instead of just including the root directory like such:
env.Append(LIBPATH=['C:/Program Files/MySQL/Connector C++ 1.1'])

Should I create a new issue for this?


text:
Android APK installation fails with INSTALL_FAILED_INVALID_APK

Godot version:

OS/device including version:

Issue description:
I have a project that work/export fine in godot 3.1
Now I updated in 3.1-alpha and I have this error when I try to export and install in same android device:

Steps to reproduce:
Export and install in android.
Minimal reproduction project:
N/A.

Did you build Android export templates matching your editor commit?

Did you build Android export templates matching your editor commit?

Yes. I did 2 steps: First I update godot to 3.1-alpha, then I update the export tools (download and install with no problems)

What Android version does your Android device have?

What Android version does your Android device have?

4.4.2
I use also Nox and BlueStacks. I tried in Nox but I have an failure installation error.

@git2013vb  akien-mga asked if you built the export templates, not downloaded and installed. There is a difference. See here:  https://godot.readthedocs.io/en/3.0/development/compiling/compiling_for_android.html   or for more clarity here: https://github.com/binogure-studio/godotamazon

@git2013vb akien-mga asked if you built the export templates, not downloaded and installed. There is a difference. See here: https://godot.readthedocs.io/en/3.0/development/compiling/compiling_for_android.html or for more clarity here: https://github.com/binogure-studio/godotamazon

I tried but I have an error :

@git2013vb you should open new issue 'compile error' and attach this image, seems like a new bug

This error was fixed in the meantime.

I found another error:

I found another error:

I installed 2.3 gradle but same result.
any suggestions?

Hi, even if I close the #23003 and the #22374 - which I don't know if they are related in some way with this one I can confirm that I still have this issue.
Thanks
ps. I feel more comfortable to use screen-shot to show errors.  In m opinion is more fast and I can avoid errors.


text:
Bone indexes messed up when importing COLLADA from 3DS Max (OpenCOLLADA)

Godot version:
3.1-beta4
OS/device including version:
ArchLinux rolling
Issue description:
Godot should have option to force sorting of bones when importing COLLADA model to make bone indexes deterministic. We're currently having a nightmare adding rigged cosmetic items to our characters because the bone order is different all the time.
Consider this skeleton:

Pelvis (0)

Spine

...

L_Thigh

...

R_Thigh

...

If L_Thigh and R_Thigh XML blocks are swapped in DAE (happens for some reason; thanks 3DS Max), then their indexes will change during import into Godot. This makes imported mesh no longer compatible with the same base skeleton that was imported from a different DAE file.
TL;DR
Godot should have ability to force bone sorting by their names to preserve their indexes. I consider this a bug in Godot because DAE itself uses string identifiers internally. Thus DAE is not prone to errors when bone order is different, but Godot DAE importer degrades string identifiers into integer indexes.
Steps to reproduce:

Import DAE with some skeleton and mesh.
Import a different DAE with a different mesh rigged to the same skeleton.
Observe difference in bone indexes of those 2 meshes.

After collada is converted to the in memory representation and before the internal format, the resulting list should be sorted and then the order of adding wouldn't change.
That sounds doable.

Busy, but the idea is to sort the skeleton_bone_map after they're populated.
https://github.com/godotengine/godot/blob/70689ebffd95ab34e45bcbfdce3f6389033bfd44/editor/import/editor_import_collada.cpp#L147
Map<Skeleton *, Map<String, int> > skeleton_bone_map;

Right! _populate_skeleton is called recursively in its last lines, so we could sort p_node->children before iteration.

You would not sort it, but use a array of nodes that have been sorted.

Can anyone still reproduce this bug in Godot 3.2.1 or any later release (e.g. 3.2.2-rc2)?
If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

No answer, so closing. Please comment if you can still reproduce the issue in Godot 3.3 or later.

authors: akien-mga and3rson fire


text:
Signal gui_event emitted twice for each event

First things first: Thank you very much for this great piece of software!
Godot version:
3.1.stable.official
OS/device including version:
Mac OS High Sierra (latest)
Issue description:
Signal gui_event(InputEvent event) is emitted twice
Connecting a handler method to the signal will result in the handler being called twice for each key press, mouse motion or mouse button event.
So far, I have been able to reproduce the described behaviour using Buttons and LineEdit.
I was unable to reproduce this behaviour with Range controls, here, the signal seems to be emitted just once.
Adding a print(str(event)) shows that there is actually two different event objects, e.g.
[InputEventKey:1533]
accdelta 45.734476
scancode with modifiers 16777233
is echo False
[InputEventKey:1534]
accdelta 45.785086
scancode with modifiers 16777233
is echo False

Steps to reproduce:
Open the provided sample project and run it in debug mode. Click on the button on the screen to focus it, move the mouse over it or press arbitrary keys on your keyboard and see the output in the debug console.
Minimal reproduction project:
gui_event_called_twice.zip

While this is actually a very elaborate bug report, the actual issue sits directly in front of the computer.
One must distinguish between pressed/released events. For every key pressed there is also a released event.
Problem fixed.


text:
Vulkan server does not compile

Godot version:
0b51a70
OS/device including version:
Docker via Fedora 30
Issue description:
The server is broken. Seems to be related to non-implemented virtual functions.
In file included from ./core/cowdata.h:36,
                 from ./core/ustring.h:35,
                 from ./core/os/thread.h:35,
                 from ./core/io/resource_loader.h:34,
                 from ./drivers/dummy/texture_loader_dummy.h:34,
                 from platform/server/os_server.h:34,
                 from platform/server/os_server.cpp:31:
./drivers/dummy/rasterizer_dummy.h: In static member function 'static Rasterizer* RasterizerDummy::_create_current()':
./drivers/dummy/rasterizer_dummy.h:803:17: error: invalid new-expression of abstract class type 'RasterizerDummy'
  803 |   return memnew(RasterizerDummy);
      |                 ^~~~~~~~~~~~~~~
./core/os/memory.h:98:51: note: in definition of macro 'memnew'
   98 | #define memnew(m_class) _post_initialize(new ("") m_class)
      |                                                   ^~~~~~~
In file included from platform/server/os_server.cpp:35:
./drivers/dummy/rasterizer_dummy.h:775:7: note:   because the following virtual functions are pure within 'RasterizerDummy':
  775 | class RasterizerDummy : public Rasterizer {
      |       ^~~~~~~~~~~~~~~
In file included from platform/server/os_server.h:46,
                 from platform/server/os_server.cpp:31:
./servers/visual/rasterizer.h:1255:15: note: 	'virtual void Rasterizer::prepare_for_blitting_render_targets()'
 1255 |  virtual void prepare_for_blitting_render_targets() = 0;
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./servers/visual/rasterizer.h:1256:15: note: 	'virtual void Rasterizer::blit_render_targets_to_screen(int, const Rasterizer::BlitToScreen*, int)'
 1256 |  virtual void blit_render_targets_to_screen(int p_screen, const BlitToScreen *p_render_targets, int p_amount) = 0;
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Steps to reproduce:
/bin/bash -c "scons platform=server target=release_debug use_static_cpp=yes -j`nproc` use_lto=no use_llvm=no gdnative_wrapper=yes deprecated=no"

It's normal and it's likely not going to be fixed before the OS / Display split which will also make the server platform obsolete... so overall I'm not sure it's worth keeping an issue for it :)

Vulkan 4.0 Godot Engine branch has been compiling for several months now.

Oops, I forgot I was referring to the server platform.

Superceded by https://github.com/godotengine/godot/issues/37342
It appears the errors here are gone and replaced by other errors.

authors: akien-mga clayjohn fire


text:
Linkage error when crosscompiling for Windows with mono

Godot version:

3418f76a9eab9f496e5b26310bd3bc1125b8119b
OS/device including version:

Arch Linux
Issue description:

When crosscompiling for Windows with mono enabled I got this linkage error at the end of compilation
[100%] /usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lo
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -ln
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lo
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l-
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l2
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l.
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l0
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -l-
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -ls
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lg
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -le
/usr/lib/gcc/x86_64-w64-mingw32/9.1.0/../../../../x86_64-w64-mingw32/bin/ld: cannot find -ln
collect2: error: ld returned 1 exit status
scons: *** [bin/godot.windows.opt.tools.64.mono.exe] Error 1
scons: building terminated because of errors.
The problem appears to be in this line:
https://github.com/godotengine/godot/blob/3418f76a9eab9f496e5b26310bd3bc1125b8119b/modules/mono/build_scripts/mono_configure.py#L127
When changed the line above to env.Append(LIBS=[mono_lib_name]) compilation completes successfully
Steps to reproduce:
Build from source with
scons -j8 p=windows target=release_debug tools=yes module_mono_enabled=yes mono_prefix=/path/to/windows/mono bits=64
The mono directory i have copied from windows installation

What does the mono_lib_name variable prints?

What does the mono_lib_name variable prints?
It prints mono-2.0-sgen. But if I print env.Dump(), then in LIBS section will be the following:

'LIBS': [<SCons.Node.FS.File object at 0x563ae45fa5d0>, [<SCons.Node.FS.File object at 0x563ae45da630>], [<SCons.Node.FS.File object at 0x563ae4596970>], [<SCons.Node.FS.File object at 0x563ae440f4f0>], [<SCons.Node.FS.File object at 0x563ae439aa90>], [<SCons.Node.FS.File object at 0x563ae4370050>], [<SCons.Node.FS.File object at 0x563ae479bf90>], 'mingw32', 'opengl32', 'dsound', 'ole32', 'd3d9', 'winmm', 'gdi32', 'iphlpapi', 'shlwapi', 'wsock32', 'ws2_32', 'kernel32', 'oleaut32', 'dinput8', 'dxguid', 'ksuser', 'imm32', 'bcrypt', 'avrt', 'uuid', 'm', 'o', 'n', 'o', '-', '2', '.', '0', '-', 's', 'g', 'e', 'n'],
I think that env.Append() treats mono_lib_name as a list and adds every individual character from that string to LIBS.

'LIBS': [<SCons.Node.FS.File object at 0x563ae45fa5d0>, [<SCons.Node.FS.File object at 0x563ae45da630>], [<SCons.Node.FS.File object at 0x563ae4596970>], [<SCons.Node.FS.File object at 0x563ae440f4f0>], [<SCons.Node.FS.File object at 0x563ae439aa90>], [<SCons.Node.FS.File object at 0x563ae4370050>], [<SCons.Node.FS.File object at 0x563ae479bf90>], 'mingw32', 'opengl32', 'dsound', 'ole32', 'd3d9', 'winmm', 'gdi32', 'iphlpapi', 'shlwapi', 'wsock32', 'ws2_32', 'kernel32', 'oleaut32', 'dinput8', 'dxguid', 'ksuser', 'imm32', 'bcrypt', 'avrt', 'uuid', 'm', 'o', 'n', 'o', '-', '2', '.', '0', '-', 's', 'g', 'e', 'n'],
I think that env.Append() treats mono_lib_name as a list and adds every individual character from that string to LIBS.

Thanks, I didn't understand what was actually happening until I read this. Saved me some time.

authors: crym0nster neikeq santouits


text:
Signal not emitted for ScrollContainer

**Godot version:3.1

OS/device including version:

Issue description:

When the scrolling is triggered by dragging on the scroll bar or by the InputEventPanGesture, no scroll_started or scroll_started is emitted.
Steps to reproduce:
Minimal reproduction project:

Can reproduce in 3.1 thru 3.2.3.rc3.
Can get the scrollbars and use their scrolling signal, but nothing from the container itself.
MRP: 31819.zip

Closing as duplicate of #22936

authors: KoBeWi alexzheng tom-jk


text:
Mono - Unhelpful Errors + Native SIGSEGV Stacktrace from an invalid transform

Godot version:
3.2.2 Beta 1 Mono
OS/device including version:
Ubuntu 19.10 eoan
x86_64 Linux 5.3.0-19-generic
Mono JIT compiler version 6.4.0.198
Issue description:
Mono runtime sometimes provides very unhelpful errors and native stack traces. While the attached project is an example of one, my personal project has experienced countless other varieties.
Also, the error crashes the entire game rather than just posting it in console and continuing to run (Arguable behavior)

Console output: https://pastebin.com/e0GF0BHp
Mono crash memory blob: mono_crash.mem.3390.1.blob.zip
Steps to reproduce:

Set an invalid transform on a MeshInstance (does not work on Spatial)
Example: GetNode<MeshInstance>("MeshInstance").Translation = new Vector3(float.NaN, float.NaN, float.NaN);

Minimal reproduction project:
GodotTestProject.zip

Lists of seemingly random errors:

https://pastebin.com/0yi9t6xV

Godot 3.3.3: I am unable to trigger a crash with the reproduction project.

Also seems to build and run fine for me on 3.4 beta 4, so assuming fixed.

authors: Tobi-Mob akien-mga nathanfranke