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

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

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

I would like if VBoxContainer/HBoxContainer/GridContainer is renamed to simple VBox/HBox/Grid…

AABB has intersection, while Rect2 has clip. They do the same thing. One name should be chosen, but which one?

Poll: ❤️ = both should be intersection, 🚀 = both should be clip, 👎 = don’t rename.

For single numbers, we have stepify. For Vector2/Vector3, we have snapped.

They do the same thing, the vectors call stepify for each component. One name should be chosen, but which one?

Poll: ❤️ = both should be stepify, 🚀 = both should be snapped, 👎 = don’t rename.

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.

For reference, Unity has Text and TextMesh, and I personally refer to it as text rather than label.

Array we should rename empty() to is_empty() to better illustrate it’s boolean

I recommend Resource’s local_to_scene should be local_to_instance or unique_per_instance. “Local to Scene” denotes the behavior as local to the scene, when it’s actually per instance of a scene.

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. The documentation even describes it as “reverse” so there is really no excuse.
• remove vs. erase is confusing. Suggestion: remove_at and remove_value.

The last two also apply to all Pool*Array classes.

Curve.clean_dupes() -> clear_duplicate_points()

In both the API and the engine code, there are a lot of places where idx, position, at and index are used to refer to an index. I propose to use index everywhere when referring to an index (or at least in the API).

While working on https://github.com/godotengine/godot/pull/48542, I noticed we could rename String.is_abs_path() to String.is_absolute_path(). I think it’s better to use plain English rather than abbreviations, and NodePath already has a method called is_absolute().

bool, float, int are the only types/classes whose names start with a lowercase letter. I think they should be renamed (in GDScript) to Bool, Float, Int. This will automatically fix the problem with incorrect type syntax highlighting.

And bool, float, int should be used only for built-in Python-like functions from @GDScript page (they also include len and str).

Note that the situation is similar with str/String: str(x) and String(x) give the same result.

ADD. It should have looked like this:

# `Int` is type.
func get_key() -> Int:
    # `int` is Python-like function.
    return int(config.get_value("sect", "key"))

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.

In various places in the engine there are properties or methods containing the word priority. In some cases, objects with a higher priority value are processed first, in others - with a lower one.

I suggest making it consistent everywhere (this only applies to priority, not layer, weight, etc).

(This list may be incomplete or inaccurate.)

Rename ShortCut to Shortcut

Edit: https://github.com/godotengine/godot/commit/3e0226515eec5f904701fce36c7856617d3ca6b8

String::begins_with to String::starts_with.

Like in serious programming languages (Java, Python etc).

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.

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.

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.

I prefer index over idx for a couple reasons:

• idx is harder/less natural to say (“eye-dee-ex” vs “in-dex”), unlike abbreviations like int and float (and even stuff like Vec, Rect and Quat) which are one syllable
• I think it’s more consistent with the rest of Godot’s API’s way of spelling out the full names of things (Vector, not Vec, Quaternion, not Quat, although admittedly there are exceptions like Rect).
• index is more universal. To someone not familiar with what idx stood for they might think it’s some kind of ID.
• It only saves 2 letters off a 5 letter word.

I think Vector3* BACK property could be renamed to BACKWARD to look relevantly with already existed FORWARD.

This suggestion does make sense to be fair, although more for clarity than consistency because the word ‘back’ has several different meanings depending on the context. For example, if you said ‘move back’, it could mean move backwards but could also mean move/return to your previous location, which is a different thing (you could have side-stepped right for instance 😃 ). Backward however is more clearly the direction opposite to forward. And left, right, up and down are clear directions so I think they are fine also!

I think Vector3* BACK property could be renamed to BACKWARD to look relevantly with already existed FORWARD.

TextEdit: cursor could be caret to not be confused with mouse cursor, in these methods cursor_get_column() cursor_get_line() cursor_set_column() cursor_set_line() etc

Some class renames worth considering for consistency with other 3D renames:

• BakedLightmap -> BakedLightmap3D
• BakedLightmapData -> BakedLightmapData3D
• Decal -> Decal3D
• GIProbe -> GIProbe3D
• LightmapProbe -> LightmapProbe3D
• Lightmapper -> Lightmapper3D
• LightmapDenoiser -> LightmapDenoiser3D
• LightmapRaycaster -> LightmapRaycaster3D
• ReflectionProbe -> ReflectionProbe3D
• Voxelizer -> Voxelizer3D
• Skin -> Skin3D
• RootMotionView -> RootMotionView3D

Editor only:

• BakedLightmapEditorPlugin -> BakedLightmap3DEditorPlugin
• GIProbeEditorPlugin -> GIProbe3DEditorPlugin
• GPUParticlesCollisionSDFEditorPlugin -> GPUParticles3DCollisionSDFEditorPlugin
• EditorSceneImporter -> EditorSceneImporter3D
• EditorSceneImporterMesh -> EditorSceneImporterMesh3D
• EditorScenePostImport -> EditorScenePostImport3D
• ResourceImporterScene -> ResourceImporterScene3D
• SceneImportSettings -> SceneImportSettings3D

For the lighting ones, 2D lighting is a thing, so it makes sense to have the 3D ones with the “3D” suffix.

For the scene import ones, it’s not like I’m against 2D scene importing or anything, but the current scene importers are hard-coded to work with 3D (they import from things like OBJ, Collada, GLTF, and FBX to 3D), so the “3D” suffix makes sense to me. If we want a 2D scene importer in the future (from what format…?), we would likely need a separate codebase anyway.

Should we remove Node2D/Node3D/Control’s hide() and show() methods in favor of the visible property?

Pros:

• Only one way to achieve something (hiding/showing a node). This also applies in the engine C++ code since both hide()/show() and set_visible() methods are used interchangeably right now.
• Using the visible property is more concise when you want to toggle something’s visibility.

Cons:

• Copy-pasting code from tutorials that use hide() and show() won’t work anymore. Sometimes, I wonder if we should list removed properties/methods somewhere so that the GDScript compiler can tell you to use the “correct” property/method.

Probably, we need to resolve the conversion method naming inconsistency (a_to_b vs a2b).

doc/classes/TileMap.xml
	map_to_world
	world_to_map

doc/classes/Marshalls.xml
	base64_to_raw
	base64_to_utf8
	base64_to_variant
	raw_to_base64
	utf8_to_base64
	variant_to_base64

doc/classes/String.xml
	bin_to_int
	hex_to_int

doc/classes/@GlobalScope.xml
	bytes2var
	bytes2var_with_objects
	cartesian2polar
	db2linear
	deg2rad
	linear2db
	polar2cartesian
	rad2deg
	str2var
	var2bytes
	var2bytes_with_objects
	var2str

doc/classes/Image.xml
	rgbe_to_srgb
	srgb_to_linear

doc/classes/TextServer.xml
	name_to_tag
	tag_to_name

modules/gridmap/doc_classes/GridMap.xml
	map_to_world
	world_to_map

modules/gdscript/doc_classes/@GDScript.xml
	dict2inst
	inst2dict

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().

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” can mean two very different things.

I’ve updated the OP with most of the suggestions given so far.

I would like if VBoxContainer/HBoxContainer/GridContainer is renamed to simple VBox/HBox/Grid

I’m not convinced, in Godot we try to give everything explicit names, and for example Grid doesn’t tell me that it’s a Container. For VBox and HBox one could argue that boxes are containers by definition, but since we have BoxContainer which is not the same as Container, I think the verbosity is still warranted.

LineEdit has a parameter new_text on “text_changed” but TextEdit does not.

I don’t think it would be useful to add new_text to TextEdit. On LineEdit, it simply contains the whole text of the LineEdit, not the text that changed, so I’d even argue that it should not be there in LineEdit’s text_changed. Yet, it’s more common that you want to use the full text of a LineEdit on input, than to do things with the full text of a multiline TextEdit when a new character is pressed.

We should rename Camera2D zoom to e.g. view_scale. Or reverse the behavior, because that’s not how zoom works.

I noticed some methods are virtual but their names don’t start with _ (for example drag and drop-related methods in Control). I think we should rename them all to have _ at the beginning, for consistency and maybe less confusion.

runner doesn’t seem very clear to me. standalone is ok. Removing it would be ok too, because you can just use !OS.get_feature("editor").

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

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

• Array.remove => remove_at (like C#) to remove by index
• Array.erase => remove_value, or just remove (like C#) to remove by value

(or variants of that with erase)

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.

Was raised already, my bad. Didn’t notice, Github is folding the thread, my Ctrl+F search missed it xD Not in the OP yet

@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().

@Calinou I 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.

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

String::validate_node_name() -> String::to_valid_node_name()

Because validate_node_name() actually doesn’t validate anything, it just mutates the string by removing a set of illegal characters and gives the string back. From the name, I’d have expected it returning a boolean.

https://github.com/godotengine/godot/blob/92f20fd70e6957cd65ccb7837fdc28f9b1e4a315/core/string/ustring.cpp#L4489

As per https://github.com/godotengine/godot-proposals/issues/2939#issuecomment-871566586, we should probably rename the GLOBAL_GET and GLOBAL_DEF C++ engine macros to PROJECT_GET and PROJECT_DEF. The Globals singleton was renamed to ProjectSettings in 3.0 after all.

Edit: Pull request opened: https://github.com/godotengine/godot/pull/50350

SpriteLight for 2D, maybe? I am definitely in favor of renaming Omni to Point in 3D. This is how it is called in Blender, so to me the meaning of Point is clear and cannot be confused with Spot.

Also it seems we prefer direct/natural word order in functions names so caret_get_column could be get_caret_column etc

I think InputEventWithModifiers’ control property should be renamed to ctrl. “control” sounds like a gui element, I got pretty confused when I saw !b->get_control() while reading the source code. Probably also command -> cmd for consistency.

Dictionary.empty() -> is_empty()

@me2beats This has already been implemented in #44401.

TreeItem: get_children() -> get_first_child() https://github.com/godotengine/godot/issues/19796

AudioStream — AudioStreamPlayer{,2D,3D} VideoStream — VideoPlayer

We should probably rename VideoPlayer to VideoStreamPlayer. Or we can rename AudioStreamPlayer{,2D,3D} to AudioPlayer{,2D,3D}.

I don’t know if this has been mentioned elsewhere (is there a way to force GitHub to show all hidden items?) but I think Control::set_focus_neighbour and friends should be renamed to the AmE spelling to keep it consistent with the docs which use “neighbor,” Color, etc. I would be happy to open a pull request for this.

EDIT: Resolved by #44412

“Less verbose” is definitely not on the menu if we want to have robust codebases across our Godot projects. Modern coding tools provide autocompletion and other intelligent features that allow you to type quickly even if the name is long. Plus, if you read the argumentations for those changes, there is a goal to make those functions less ambiguous to developers using them. Short name might be sweet, but confusing and less discoverable.

And always remember: typing code is the quick part of the software development. Reading and understanding code afterwards is much more important. It’s like conceiving and raising a child respectively.

Should we rename Control.MOUSE_FILTER_PASS to Control.MOUSE_FILTER_PASSTHROUGH? This would make it more obvious that the event will be passed through the Control node to nodes located below it. I’m not sure if it’s actually worth renaming it, though.

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

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).

In terms of API, it’s IMO more user-friendly to have draw_rect(bool filled) and draw_circle(bool filled) than draw_rect(), draw_filled_rect(), draw_circle() and draw_disk() (or what would be the mathematical name for a filled rectangle?).

Edit: Actually draw_circle() doesn’t have a filled argument yet. I think we should add one, so that it can be used to draw both circles (perimeter) and disks (filled circle).

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

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).

loop, repeat, oneshot, of animationplayer, timer, and similar nodes, could be clarified.

looping, repeating, and not being a oneshot, are all the same things.

@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 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()

TreeItem.get_children() should be renamed get_first_child(). The doc should also explain that it’s NOT returning the child items. Children are iterated using get_next().

Animation.track_remove_key_at_position should be Animation.track_remove_key_at_time

In PhysicsDirectSpaceState, functions return collision info as dictionary.

I wonder if we should move these to dedicated Reference-based types (similar to JSONParseResult) to provide type safety and autocompletion. Compile-time errors are better than run-time errors 🙂

In general, I think we should avoid returning Dictionaries unless the returned keys’ names is meant to change depending on the input.

Is it worth opening a separate proposal for a more OOP approach to print, having some Printer that allows for a reusable configuration of targeted output stream (out/err, editor, etc.), separator (tab/space), use of indents for pretty-printing, other dump()-like print settings for Objects/Dictionaries, etc.? That way you don’t have to have such a variety of global printing functions?

I think this adds too much complexity and would also require more typing than necessary. Unlike most operations in programming, printing is one of these things people do so often it’s important to save every possible keystroke.

Well, if we have to pick one that works for everything, it’s to, not 2. This also works better for other class methods that convert it to something, like Object.to_string(), which you wouldn’t call 2string(). But do we actually need to make it the same for everything?

This would also affect some of the names, because str2var should probably be expanded to at least string_to_var, if not string_to_variant.

@LightningAA What if we changed count() so that it had a single optional parameter. If you give it a null argument, then that is perceived as “empty” (the default) and it returns a value similar to size(). But if you give it a non-null argument, then it returns the number of elements matching that argument. If the argument is a Callable that accepts a single parameter, then you could even treat it like a predicate.

On Control: focus_neighbour_* -> focus_neighbor_*

Mesh: surface_get_material -> get_surface_material and surface_set_material -> set_surface_material #16863 (comment)

I disagree. A Mesh has multiple surfaces. These are not getters and setters of the Mesh’s surface_material. They are methods to set a specified surface’s Material. This is a standard naming convention in Godot for this type of method; so they should not be changed.

I disagree with both of you. I am a Godot user and I use Godot specifically because GDScript is terse and quick to write. If you gonna make them twice as long then the speed advantage is lost as I will be forced two write twice as much and would have to scroll twice as far to see the entire line of code horizontally.

When you are coding you don’t wanna be typing incredibly long function or variable names. Some of these proposed changes changes add extremely long function and variable names for the sake “clarity” at the expense of everything else. You can read the built in help if you have any doubts. Plus programming is about learning an API. You will always look up a function first time you use it regardless of the name. Take printf in C is terse and simple. In Godot you would name it send_formatted_string_to_standard_out. Not only you’re forcing everyone to re-learn the api but some of these changes don’t even have a unified vision. Seems to me like a whole bunch of people got together and each changed one parts of the engine.

Take Array for example remove -> remove_at What does _at add here? You already have remove_value. What else can you remove? erase -> remove_value Still not clear enough. From documents “Removes the first occurrence of a value from the array.” Also people might think you can remove one single value from the entire array. For clarity it should actually be remove_first_occurance_of_value because that’s what the function actually does. So you made the function longer and equally confusing just longer.

You have remove and erase two different functions but you turn them both in the same variation on remove with extra letters. But they function work differently. Remove removes from a specific index where as erase removes the first instance of a value found.

These are okay just not really useful other than forcing people to update their code. invert -> reverse
duplicate -> clone empty -> is_empty

If is not broken don’t fix it.

Editor vs standalone is probably standard naming (at least one I see in many different engines) so no reason to reinvent the wheel imho.

I think find_node and/or get_node should be renamed because the names don’t indicate they differences between the 2 at all. Since find_node only looks at children, maybe find_child_node? I’m not sure what a good alternate name for get_node would be. My first thought was get_tree_node since it can get a node from anywhere in the tree, but it can also be used outside of the scene tree with relative paths.

@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 and isn’t exposed, but is used internally.

In the end I think this whole class should be looked over. Viewport has 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).

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 what rename it to, maybe view_scale or something similar.

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

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

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 global 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.

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

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

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

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.

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

TileMap.set_y_sort_mode(val) -> TileMap.set_y_sort_enabled(val) TileMap.is_y_sort_mode_enabled() -> TileMap.is_y_sort_enabled()

We should probably rename RID_Owner’s getornull() to get_or_null() (also for RID_Alloc and RID_PtrOwner).

Edit: Done in https://github.com/godotengine/godot/pull/53227.

In Godot 3.x, we have the following two nodes:

CanvasItem
    Node2D
        Light2D # Same as OmniLight but for 2D

Spatial
    VisualInstance
        Light
            OmniLight # Same as Light2D but for 3D

In the current master, we have the following two nodes:

CanvasItem
    Node2D
        Light2D
            PointLight2D # Same as OmniLight3D but for 2D

Node3D
    VisualInstance3D
        Light3D
            OmniLight3D # Same as PointLight2D but for 3D

I propose we rename OmniLight3D to PointLight3D to match 2D (❤️). Alternatively, we could have OmniLight2D (🚀).

TextEdit: cursor could be caret to not be confused with mouse cursor, in these methods cursor_get_column() cursor_get_line() cursor_set_column() cursor_set_line() etc Also it seems we prefer direct/natural word order in functions names so caret_get_column could be get_caret_column etc

See #47548

ScrollContainer’s and RichTextLabel’s get_scroll_v() methods should be either renamed or unified to return the same thing (in 3.3.2, ScrollContainer’s returns the scrollbar value while the RTL’s returns the scrollbar itself)

I wonder if we should move these to dedicated Reference-based types (similar to JSONParseResult) to provide type safety and autocompletion

Last time I asked why that is, the answer was that this form of result is cheaper to construct than a full-fledged object (notably for a function that can run a lot every frame), while also using less memory.

Obligatory mention of godotengine/godot-proposals#2816 which could possibly meet both needs in some future 4.x release.

@pycbouh I added that just now though, because of @MikeSchulze’s comment 😉

I think the endian_swap property of File could be renamed to big_endian.

• It’s hard to figure out the actual endianness of endian_swap without referring to the doc.
• It’s counterintuitive that Godot won’t do any swapping when endian_swap = true on a big-endian-native platform (if any).
• StreamPeer also uses big_endian for a similar property.

Array: count() to something like count_occurrences() . “count” is confusing because in C# it means the length of a list.

Change “pickable” of the CollisionObject2D to “enable_mouse_interaction” See: https://github.com/godotengine/godot/issues/38085 https://github.com/godotengine/godot-proposals/issues/2441

Should we rename the TextureProgress node to TextureProgressBar?

Advantages

• When searching for “progressbar”, you’ll see both nodes in the search results.
• More consistent with Button/TextureButton.

Disadvantages

• TextureProgress can be used for circular progress bars, which are not “bars” in the literal sense of the term. Nonetheless, they still visually represent a progress.
• TextureProgressBar is longer than TextureProgress.

Edit: Done here: https://github.com/godotengine/godot/pull/44377

I just stumbled upon the counterparts Camera::unproject_position() and Camera::project_position(). They do the exact opposite of what you would expect / what is commonly agreed upon. Camera::unproject_position() does a normal camera projection, i.e. it takes a 3D position and projects it onto the screen. Camera::project_position() does what people would call an unprojection, i.e. 2D->3D. (Technically everything is a projection, but we’re not speaking correct mathematical terms here but graphics slang.)

If you’re not convinced see https://www.google.com/search?q=camera+unproject or https://dondi.lmu.build/share/cg/unproject-explained.pdf to convince yourself that practically every other library uses the terms project and unproject in the opposite directions to what they are currently implemented in Godot.

Edit: I think I now understand how this happened historically. There are also:

• Camera::project_local_ray_normal()
• Camera::project_ray_normal()
• Camera::project_ray_origin()

which all take screen positions as inputs. I get that you can say “to project a ray onto an object in world space”, but also look at the documenation of Camera::project_ray_normal() and Camera::project_ray_origin() (they are identical):

Returns a normal vector in worldspace, that is the result of projecting a point on the Viewport rectangle by the camera projection. This is useful for casting rays in the form of (origin, normal) for object intersection or picking.

… you mean by the inverse camera projection? One could suggest that it would be less confusing to just call them cast_ instead of project_. But since projecting rays is also not an uncommon term, a documentation update for the ray functions will probably suffice.

Edit²: I fixed a typo and deleted most of my last edit. Now its restored.

I would prefer simpler and shorter less verbose changes. It’s a function name not also a description of the function.

The name should be descriptive though. Also length doesn’t matter if you take advantage of the autocompletion (which is built-in in the Godot editor).

I mentioned it once on IRC and didn’t get a reply, but TextureRect has a stretch mode called “Scale On Expand (Compat)”. This sounds like something that could be removed.

The Tracking_status enum in ARVRInterface should be renamed to TrackingStatus, to be consistent with the styles of other enum names.

EditorImportPlugin and EditorExportPlugin look like they are related, however one is about importing resources and the other is about exporting a project. I suggest we rename EditorImportPlugin to EditorResourceImportPlugin or something along those lines.

Edit: And EditorPlugin.add_import_plugin must be renamed accordingly as well.

@MuffinManKen I think that get_node is perfectly understandable since, as you stated, it can fetch any node, anywhere, so long as it is connected with the same tree as the given node, regardless of whether they are part of the SceneTree or not.

@Coldragon I’m not sure I like renaming find_node to find_child either, as it then gives me the impression that it works only with direct children for some reason. The alternative would be to have it be called find_descendant or something, but that is far too wordy/complex. Cutting it down to just find() also doesn’t make sense since it is then unclear what we are searching for. As such, I think that unless another alternative is sought, find_node should stay as it is too. It should just have clear documented differences in behavior for the API docs.

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.

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

I noticed some methods/properties use normal_map, whereas others use normalmap. We should settle on either of these, but probably not both. I’d prefer normal_map, but I’m OK with normalmap too.

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

@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 .

@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.

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 😃

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/

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.

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

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.

If I can have one added to the list, the LineEdit and TextEdit control nodes would really benefit from having consistent APIs with each other 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.

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.

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

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.

Likewise, I prefer it when reading the reference or using the autocompletion of a scripting API keeps all related things together (which you get when they all have a texture_ prefix).

String: get_file() -> get_filename()

https://docs.godotengine.org/en/stable/classes/class_string.html#class-string-method-get-file It’s confusing because there’s already a File class but this method just returns the name of the file.

Just came across the Status enum of StreamPeerTCP. The STATUS_NONE status is not very intuitive, it’s the initial status and also the status after disconnecting.

I think STATUS_DISCONNECTED would be better. This is also how HTTPClient names its corresponding status.

Not sure if this has already been brought up but also

Both #47548 and #47448 have a full list of what has been changed, these are listed there.

These are “out of order” on purpose, because they are not actually out of order. These methods are grouped around a virtual sub-entity, like caret or camera, which you cannot fetch individually and independently from the parent object, but methods are still unrelated to the parent itself.

Basically, if you could get a caret as a reference, it would be get_caret().get_column(). But as it stands in the scripting API you cannot extract a reference to the caret, so this is reflected in the name of the function. This also nicely groups the related methods in the class reference.

In other words, these methods are named consistently with our practices, not against them.

Could String.trim_suffix() and String.trim_prefix() be renamed to String.remove_suffix() and String.remove_prefix()?

• More straight forward.
• “trim” is usually related to whitespaces in other places like JavaScript, C#, Qt, and Unreal.
• We already have the Python styled lstrip, rstrip, and strip. And Python uses removeprefix and removesuffix.

rpc should be renamed to rpc_reliable and rpc_unreliable to rpc. Basically, RPCs should be unreliable by default. That is how Unreal Engine does it, and how you should do it in most circumstances.

Image and Texture has confused me like crazy. If Image would be called ImageData or maybe even better TextureData

Image is not always used as a source for textures to be further rendered. Neither ImageData could fully describe the purpose of the class, since it contains data and a plethora of algorithms to process the data.

In general, I haven’t used every single class in Godot, and I will be confused as well when trying to understand something which I may not necessarily need at the moment. I don’t get how a simple class rename could significantly improve the issue with misunderstanding/misconception. Confusion is a part of the learning process. 😕

I mean, it’s basically a dilemma between making this more clear either for beginner use cases, or advanced use cases. Seeing ImageData could be equally confusing to an experienced developer when they also want to find image processing methods to manipulate the data, or limiting the use cases to rendering textures with TextureData name.

I use Image class almost like on a daily basis so that’s why I’m so vocal about this, sorry! 😃

Also, 4.0 renames MeshInstance->MeshInstance3D, and Mesh3D “the node” also technically isn’t ambiguous to Mesh “the resource”, but still a bit confusing 😃.

I’m in favor of renaming MeshInstance2D/3D → Mesh2D/3D in 4.0.

By the way, the sprite conversion tool in 3.x also refers to it as Mesh2D:

This can also be considered a bug in 3.x, in fact.

Sprite is also renamed to Sprite2D in 4.0, so this should make it consistent.

I don’t really like renaming Mesh to MeshData because it would lead to renaming inherited classes as well. It’s similar to renaming Image to ImageData just to avoid confusion with a Texture. In cases like this, it’s certainly just documentation issue, but the above discussion does makes sense on some level.

AnimationPlayer and Animation: replace all occurrences “remove” and change them to “delete”. Including the in-editor drop down “Remove” to delete an animation. -> “remove” is associated with something staying in memory ( like Node.remove_child(child), Node.remove_from_group(group), Node.remove_and_skip()) -> “delete” is what these methods are actually doing. If you currently “remove” a key, track, or animation, they are gone for good. -> “delete” is less ambiguous

@Geequlim @Calinou How about web? Otherwise I would prefer webassembly.

Should we remove the .append() alias for .push_back() in the various Array classes? See https://github.com/godotengine/godot/pull/44274/files/2f3386794b3fabefb9840be3f78c2d7195e16214#r541057877.

Advantages

• Only one way to achieve something, more consistent with its .push_front() counterpart which doesn’t have an alias.

Disadvantages

• Less intuitive name.
• Less obvious to people coming from languages where .append() is used to append to arrays.

Edit: Done here: https://github.com/godotengine/godot/pull/44382

@Feniks-Gaming I can tell you empty or is_empty are equally confusing just one is longer than the other.

Why not ResourceImportPlugin? Many (most?) editor classes don’t contain the word “Editor” already, like SceneTreeDock or all of the animation stuff.

TreeItem’s get_children() only returns the first child and not all children like the name (or the description in the docs) suggest.

[Edit] Nvm the docs. The method description is updated in master, sorry.

Yeah, but consistency would be good, too. Get rid of boolean parameters in InputEvent then?

@dalexeev Boolean parameters are often less readable than having different methods, since true and false have no context.

We should consider changing String begins_with() to starts_with().

It is that way in Java, C#, Python, JavaScript, etc.

Bugsquad edit: https://github.com/godotengine/godot/issues/16863#issuecomment-596069130

What about RayCast.target?

IMO: get_image yes, get_bytes no.

texture.get_image().get_data()

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?

#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.

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.

Related to https://github.com/godotengine/godot/issues/16863#issuecomment-394745886

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. 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 or perhaps even Vector2.normal(), but people might get confused between normalized() and normal()

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

@pycbouh It would also be a good idea for linking PRs for each issue if there is one. The OP already does this, but not for the comments below it.

@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.

SoftBody has an areaAngular_stiffness which should be area_angular_stiffness (same for all related methods).

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

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 😉

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

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.

Change CanvasItem.visibility_changed() signal to CanvasItem.visibility_changed(visibility: bool), ie. send the visibility status with it. Since this will be enough then remove CanvasItem.hide() signal

Consider renaming Array.invert to Array.reverse. Invert is more like upside down or the “reciprocal of” type of thing. See https://docs.godotengine.org/en/latest/classes/class_color.html#class-color-method-inverted

Rename Tween.tween_completed to Tween.tween_finished? Just like Animation.animation_finished? Generally prefer _finished over _completed? It feels like started/finished have a tighter relation than started/completed - biased from competition sports: start/finish - maybe 😄

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.

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.

If they were renamed to Gizmo then perhaps they could be given more general uses.

I’ll add a 🎉 reaction to all suggestions which have been integrated into the OP, to have a better overview.

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

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

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

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()

They are just a few examples out of many.

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).

When working on converter from Godot 3.x to Godot 4 I found, that renaming this functions(first string) to another one(second string), works for some classes, but broke others. I think that this should be unified to help users to upgrade its projects

{ "_set_name", "get_tracker_name"}, // XRPositionalTracker - CameraFeed use this
{ "_unhandled_input", "_unhandled_key_input"}, // BaseButton, ViewportContainer broke Node, FileDialog,SubViewportContainer
{ "get_extents", "get_size" }, // BoxShape, RectangleShape broke ReflectionProbe
{ "get_h_offset", "get_drag_horizontal_offset"}, // Camera2D, broke PathFollow, Camera
{ "get_mode", "get_file_mode"}, // FileDialog broke Panel, Shader, CSGPolygon, Tilemap
{ "get_name", "get_tracker_name"}, // XRPositionalTracker broke OS, Node
{ "get_recognized_extensions", "_get_recognized_extensions" }, // ResourceFormatLoader, EditorImportPlugin broke ResourceSaver
{ "get_translation", "get_position" }, // Node3D broke GLTFNode which is used rarely
{ "get_type", "get_tracker_type"}, // XRPositionalTracker broke GLTFAccessor, GLTFLight
{ "get_v_offset", "get_drag_vertical_offset"}, // Camera2D, broke PathFollow, Camera
{ "get_zfar", "get_far" }, // Camera3D broke GLTFCamera
{ "get_znear", "get_near" }, // Camera3D broke GLTFCamera
{ "has_font", "has_theme_font" }, // Control broke Theme
{ "has_icon", "has_theme_icon" }, // Control broke Theme
{ "has_stylebox", "has_theme_stylebox" }, // Control broke Theme
{ "instance", "instantiate" }, // PackedScene, ClassDB - Broke
{ "is_listening", "is_bound"}, // PacketPeerUDP broke TCPServer, UDPServer
{ "listen", "bound"}, // PacketPeerUDP broke TCPServer, UDPServer
{ "load", "_load"}, // ResourceFormatLoader broke ConfigFile, Image, StreamTexture2D
{ "save", "_save"}, // ResourceFormatLoader broke ConfigFile, Image, StreamTexture2D
{ "set_autowrap", "set_autowrap_mode" }, // Label broke AcceptDialog
{ "set_color", "surface_set_color"}, // ImmediateMesh broke Light2D, Theme, SurfaceTool
{ "set_extents", "set_size"}, // BoxShape, RectangleShape broke ReflectionProbe
{ "set_flag", "set_particle_flag"}, // ParticlesMaterial broke Window, HingeJoint3D
{ "set_normal", "surface_set_normal"}, // ImmediateGeometry broke SurfaceTool, WorldMarginShape2D
{ "set_region", "set_region_enabled" }, // Sprite2D, Sprite broke AtlasTexture
{ "set_translation", "set_position" }, // Node3D - this broke GLTFNode which is used rarely
{ "set_zfar", "set_far" }, // Camera3D broke GLTFCamera
{ "set_znear", "set_near" }, // Camera3D broke GLTFCamera
{ "translation", "position" }, // Node3D - broke GLTFNode

Shouldn’t it be pressed_texture, disabled_texture etc, similar to albedo_texture of SpatialMaterial.

TextureButton:

This is a debatable issue. In one case, the advantage is that the name corresponds more to the English language, and in the other case, the advantage is that similar properties have one prefix and are located next to each other.

It’s necessary to bring all such cases to consistency.

I would also like the same name for index position everywhere, but would opt for idx in this case because it is used so much and so often and “sounds” exactly the same as “index”. Even though I’m usually for more explicit names, there is hardly any chance to misinterpret idx as something other than “index”.

The term “point light” is sometimes used to refer to both omni and spot lights. In contrast to DirectionalLight, the position of a point light matters. If we rename OmniLight3D to PointLight3D, we lose on this distinction.

PointLight2D has no concept of omni and spot lights because its appearance depends on the texture you use. While you could use a projector texture on an OmniLight3D to make it look like a spot light, doing so is inefficient, especially when shadows are enabled (which is a requirement for using projectors in Godot).

Due to this, I think neither of the suggested renames are appropriate. If improving search quality in the Create New Node dialog is a concern, we should add a keyword system with alternate names for nodes instead (e.g. using the class reference XML).

BTW there are a lot of VisualServer methods with such word order like

camera_create() camera_set_cull_mask() camera_set_environment() camera_set_frustum()

IMO the decision should be made as to whether all engine functions should have “natural word order” (like in cases above) so that there is no need to come back to this question (maybe it’s worth a separate proposal?)

_Geometry2D::point_is_inside_triangle-> is_point_inside_triangle DirAccess::current_is_hidden -> is_current_hidden

There are probably many more.

Is it worth opening a separate proposal for a more OOP approach to print, having some Printer that allows for a reusable configuration of targeted output stream (out/err, editor, etc.), separator (tab/space), use of indents for pretty-printing, other dump()-like print settings for Objects/Dictionaries, etc.? That way you don’t have to have such a variety of global printing functions?

# I wouldn't mind if printt() and prints() were removed, I'm not convinced that they're that useful
printt() -> print_tabs()
prints() -> print_spaces()

I’m not sure I can agree with printt() and prints() being removed. They are useful to me because then I don’t need to type in my own spaces/tabs to separate the many arguments I provide to them.

I will say that I’m not opposed to them being renamed, but I don’t think the suggested names are that great. The need to type out two words, rather than one word and a optional letter that adds common separators, just doesn’t feel right to me. I’m not sure I can really explain why though.

(P.S. I don’t think merging them into the print() function could happen either, as unless I’m missing something about GDScript, I don’t think you can have function arguments after a varargs (and requiring them before the varargs would just be annoying).)

# I wouldn't mind if printt() and prints() were removed, I'm not convinced that they're that useful
printt() -> print_tabs()
prints() -> print_spaces()

Removing these would make sense only if there will be an alternative for printing with a custom separator. If renaming these at all I’d rather go with something like:

printt() -> print_tabbed()
prints() -> print_spaced()

so the name would actually tell what the function does. But I’d rather leave them as is.

from https://github.com/godotengine/godot/issues/37019

User suggested to rename CollisionObject._input_event arguments click_position to mouse_position and click_normal to mouse_normal:

CollisionObject.input_event has the args click_position and click_normal. The naming suggests that they are only valid for click events, but they in fact seem to be valid for InputEventMouseMotion as well. This is great, but it seems like they should be called mouse(position,normal) to indicate that they aren’t just for clicks.

It seems like an easy fix, but I’m not sure if renaming an argument is considered a breaking change. Would it affect language bindings for languages that support named arguments?

You are right, I have not considered Image containing and doing more than just being a container for raw data. That being said, I still find the naming conventions around textures and images extremely counter productive in terms of aiding the learning process. I would think what we are trying here is to find a balance that works for most people at least somewhat good. Not something that either only works for beginners or only works for pros.

@akien-mga What you are saying makes a total sense, but what @nathanfranke is saying is not pointless either. All nodes in the scene tree are instances, but not all of them have the ...Instance suffix. It seems like a pointless thing to add and has confused me in the beginning as well. MeshInstance could just have been named Mesh and the mesh resource could instead have been named MeshData or MeshResource or whatever. This would have aligned more with my expectations before I got used to MeshInstance out of shear frequency of using it. It would also seem to align more with the rest of the engine that does not explicitly call it’s Instances ...Instance. Like Sprite2D or Sprite3D.

replace all occurrences “remove” and change them to “delete”

same for Tabs.remove_tab(), ItemList/OptionButton/PopupMenu remove_item() and many of other occurrences I guess?

Either: CapsuleMesh.mid_height -> height or: CapsuleShape2D.height -> mid_height CapsuleShape3D.height -> mid_height

Dictionary.empty() -> is_empty()

Just chose one like all other programming languages.

Aliases are actually common in some languages, e.g. Ruby. Also append is consistent with append_array.

This is the implementation btw: https://github.com/godotengine/godot/blob/06314c1b0e8100546a53cf2786fa244c5d19af6f/core/variant/array.h#L70 It indeed calls push_back but it’s done inline, so I think it has zero overhead.

I would appreciate the consistency. Ultimately I don’t care what it will be as long as there are no aliases. The world is a mess, don’t try to fix it with aliases; it just adds onto it. Just chose one like all other programming languages. When it comes to aliases I am fully autistic:

• Was it an alias or were they doing something slightly different?
• Is one calling the other hence one is a CPU cycle faster?
• have I already used one or the other, what should I use for consistency?
• am I consistent with counterpart functions that may have similar aliases?
• which alias are others using, what is best practice?

I know that all of this is nonsense but once I realise this I would have already spent 30 seconds of brain power on something else than my project. While googling "godot array append" will result in push_back (if that’s the one) in 10 seconds without any distracting thoughts.

Rename ButtonBase Property from toggle_mode to more clear can_be_toggled. Issue with toggle_mode is that it’s not clear enough what it does. When you see toggle_mode = true you need to stop and think what it means. When you see can_be_toggled you know for certain that this button can now be toggled when you click it.

Object::is_class(name) → Object::inherits_class(name).

I understand now that this method is mostly equivalent to GDScript is (which was extends btw), but C++ requires more explicitness.

The confusion I ran into is checking whether particular object is of existing type (without inheritance):

// Use case: we're only interested in editing "Node2D" classes directly.
node = Object::cast_to<Node2D>(p_edited);
if (!node) {
	return;
}
if (node->get_class() != "Node2D") {
	return; // OK, any class other than "Node2D" is not edited.
}
// vs.
if (!node->is_class("Node2D")) {
	return; // ERROR: derived classes like "Sprite" will also be edited...
}

The underlying implementation uses “inherits” macros/templates all over the place, so it makes sense to me to rename this to inherits_class.

See also https://github.com/godotengine/godot/issues/21461#issuecomment-416155187:

get_class() and is_class() are confusing to me in general

That is beyond renaming and should be discussed as a proposal.

@Calinou I find the current behaviour unusual. This scene setup yields “Click Child2, Click Scene”

(Note, all are set to Pass)

😄 Proposition A: Perhaps something like Control.MOUSE_FILTER_PASSPARENTS for the current behaviour, since input events only seem to be sent to the parents.

🚀 Proposition B: Change the constants to these:

• STOP: Current Behaviour - Take event and stop all propagation
• PASS_PARENT: Same behaviour as PASS currently
• PASS_ALL: IGNORE, but takes events
• IGNORE: Current Behaviour - Do not take event, but still propagate

👀 Proposition C: Whether or not the node takes gui inputs isn’t really relevant, since one can just not connect any signals (or use a boolean flag). We can change the option to Control.propagation_mode and have these constants:

• NONE
• PARENT
• ALL

That would look a lot cleaner in my opinion.

global random functions such as randf and rand_range should be deprecated or removed.

Discussed as part of godotengine/godot-proposals#1590.

I’d prefer these basic random methods to be at global scope for accessibility and prototyping purposes, at least some of them. But seed() and rand_seed() can be surely removed.

Rename Image.load() → Image.load_from_file().

1. Helps to alleviate possible confusion with load("image.png") files via code, see documentation changes at #42412.
2. Image.load() won’t be highlighted as a GDScript built-in name anymore: #28866.
3. Consistent with Image.load_*_from_buffer() per image format. Buffer-related methods can be potentially unified into the same interface to prevent API bloat, but that’s another topic for discussion.

@dalexeev What you propose is not correct. When we talk about echo events, we talk about repeated keyboards events while pressing a key, using the term here makes little sense, since the action system does not relies of event directly, it’s state being updated in a per-frame fashion. Also, actions can also work with other devices like controllers or mouse buttons, where “echo” event do not exist.

As mentioned above, raw bools should be avoided. A flag like INPUT_ALLOW_ECHO/INPUT_NO_ECHO would be much better than a bool.

@dalexeev There are many cases where you need to check if a key is pressed and not only if it was just pressed. For example, a script for moving a character needs to do this with WASD or the arrow keys. Pretty much every game is going to need to process input, so I don’t think it’s wasteful to just have two methods for these things.

When reading the code, you can use Shift + Click.

Not if you are viewing diffs on GitHub. If the code requires an IDE to be readable, it is not good code.

The Mutable type column is wrong: only Object-derived, Dictionary, and Array are mutable. (Vector2 might look mutable since you can do vec2.x = 0, but it actually translates to something like vec2 = vec2.with_x(0))

Here are the terms as I understand them:

Regardless, these names aren’t going to be changed. They are fine as-is, and familiar to programmers of various languages. We should end the discussion here to avoid filling this tracker with pointless discussion.

@razcore-art I recently answered a question related to ray casting, and I used segment word to describe it, so I think makes sense. But this could also be rewritten as direction and length, so it will actually become something closer to a ray rather than a segment, speaking geometrically (or just provide alternative properties which could co-exist). The problem is that there’s no way to set a normalized direction vector easily in the inspector. I wrote a proposal to make one, at least for 2D: godotengine/godot-proposals#397, but perhaps that’s too far fetched.

EDIT: Upon further thinking, segment wouldn’t make sense much in terms of RayCast node, but makes sense in terms of Physics2DDirectSpaceState.intersect_ray().

What about RayCast.target?

@nathanfranke I’d assume target to be a Node or a NodePath. So at least this could be RayCast.target_position. Maybe RayCast.cast_position or RayCast.cast_offset. Don’t forget that ray casts can rotate, which can shift the actual cast position in global coordinates.

Mesh / MeshInstance

• In Mesh you get/set Materials with those methods : surface_get_material/surface_set_material
• In MeshInstance you get/set with those methods : get_surface_material/set_surface_material

It should be the same naming I guess ?

@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.

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

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

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

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

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.

Even the class reference says:

Makes the currently focused cell visible.

This will scroll the tree if necessary. In SELECT_ROW mode, this will not do horizontal scrolling, as all the cells in the selected row is focused logically.

Note: Despite the name of this method, the focus cursor itself is only visible in SELECT_MULTI mode.

GDScript

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

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

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 the OP would also mean that the suggestion posted is accepted as worthwhile by the team.

@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.

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.

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).

Edit (2020-01-03): On second thought, call_remote() and set_remote() might make more sense as we already have call_deferred() and set_deferred().

Edit: Don’t mind the closing/reopening below, I clicked too fast.

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.

@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.

UPD. JSON.serialize is also possible, but by the number of characters it is the same as JSON.stringify. 😄

@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.

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

InputMap: get_action_list( String action ) the function name doesn’t tell much about what it does. Since it returns the EventInputs associated to a given action, it could be get_action_events(String action)

Also could help avoiding possible confusion as InputMap has another function called get_actions( ) and both names could mean the same thing out of context.

Should RayCast have a “Disabled” property instead of “Enabled”? CollisionShape has a “Disabled” which is false by default (which means they’re enabled by default). In contrast, RayCast’s “Enabled” property is false by default, making them disabled by default.

Or, to use the positive form (which I think is less confusing overall), should CollisionShape have an “Enabled” property (true by default) instead of “Disabled”?

@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.

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 “<node>2D” and “<node>3D”, or just “<node>” 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 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.

If I may, however… perhaps rename Area2D to Area, and Area to Area3D?

Edit: Seems text surrounded by <> doesn’t appear unless you escape the <>

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

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.

@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.

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

Rename CanvasItem.visible to CanvasItem.is_visible (and all other places where it’s used)? to be in line with all (or most, maybe I missed some) bool properties?

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.

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

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.

@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)

@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.

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.

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) #19302

@dalexeev That’s a good topic for a dedicated proposal on godot-proposals, it will be easier to follow than on an issue with 515 comments 😃

I’ll close this issue as superseded by #54161 as this one is too big to still be useful. Most proposed changes have been done, others might not be consensual yet or should be moved to #54161 or dedicated proposals if they are far reaching.

Yeah, makes sense. I don’t think PointLight3D would be confusing with SpotLight3D personally, but I see why OmniLight2D would not be an appropriate term.

Also, if PointLight2D is defined with a texture, is it even a point light? A point light comes from a single point, if PointLight2D has light coming from a texture then isn’t that light coming from the area of the texture?

(P.S. I don’t think merging them into the print() function could happen either, as unless I’m missing something about GDScript, I don’t think you can have function arguments after a varargs (and requiring them before the varargs would just be annoying).)

That’s why I was saying GDScript would have to support named arguments first

When would you want to use printerr() instead of push_error()?

It’s about terminal output redirection. The standard output and standard error streams can be redirected independently from each other (e.g. to a file).

For instance, curl will print the response’s contents to stdout and print progress reporting to stderr. This way, when you do curl https://example.com > out.html, out.html only contains the response, not the progress bar that was printed to the terminal. In contrast, if you use curl https://example.com &> out.html (in Bash), out.html will contain both the progress bar and the response (and your terminal won’t print anything to screen).

This is just an example among many others, but I want to make sure we don’t break user expectations when it comes to this kind of stuff. stdout/stderr handling is mostly a solved problem by now, so let’s not break it 🙂

@LightningAA printerr() and push_error() are not equivalent to each other. printerr() does not cause a message to appear in the editor’s Errors tab, and it doesn’t use the same formatting as engine-provided error messages in the terminal output.

printerr() should just print a message to the standard error stream and do nothing special about it. It should behave exactly like standard print(), except that it prints to the standard error stream instead of the standard output stream. This means it will look the same to the end user, but standard streams aren’t distinguished from each other in a default configuration.

As for renaming push_error()/push_warning() to print_error()/print_warning(), the issue is that we risk increasing the confusion between printerr() and push_error().

I don’t use prints() often, but printt() can be useful when performing print-statement debugging and printing many values on the same line. That said, I think we need some kind of PHP-style dump() function eventually… 🙂

@GDScript:

printerr() -> print_error()
push_warning() -> print_warning()
push_error() -> # replaced by print_error()

If GDScript ever supports named arguements:

print(), printt(), prints(), printraw() -> print(varargs objects, String separator = ", ", String end = "\n")
# Used like:
print("a", "b", 3, separator = "\t", end = "")

otherwise:

# I wouldn't mind if printt() and prints() were removed, I'm not convinced that they're that useful
printt() -> print_tabs()
prints() -> print_spaces()

printraw() -> print_raw()

AudioStreamSample -> AudioStreamWAV. Documentation states it can be used for PCM audio data, so maybe AudioStreamWAV should inherit AudioStreamPCM?

Edit: https://github.com/godotengine/godot-proposals/issues/4532

rpc should be renamed to rpc_reliable and rpc_unreliable to rpc. Basically, RPCs should be unreliable by default. That is how Unreal Engine does it, and how you should do it in most circumstances.

I would say rpc is usually reliable and rset is usually unreliable but those should remain the same for consistency. If there’s anything that should be done it would maybe be a warning against using rpc or rset reliable in _process

oh my fould, if there a changelog?

Yes, this issue. The opening post here lists every rename that was/is considered, has a checkmark if it has been done and a link to the appropriate PR.

i mean it is not documented here

It is.

String: Rename empty to is_empty PR: #44401

Vector2.angle_to_point(Vector2 other) could be removed as it same as (a-b).angle(), see #16307.

Personally, (a-b).angle() is more intuitive.

@Error7Studios For get_data it was already proposed, PRed and merged: https://github.com/godotengine/godot/pull/47435 And set_data doesn’t exist on master (the method was effectively replaced with update in https://github.com/godotengine/godot/pull/36098).

@nathanfranke Since there’s already Mesh, MultiMesh, and NavigationMesh, it’s pretty clear that the Instance part is not redundant and has a special meaning.

See the relevant documentation for these classes: https://docs.godotengine.org/en/stable/classes/class_meshinstance.html

(If that’s not clear enough, it’s a documentation issue.)

signal Tabs close/tab_closed should be close_pressed (or close_button_pressed) It is emitted when close X button pressed, not when a tab closed/removed

The JavaScript class refers to the JavaScript singleton, which lets you run JavaScript code at run-time. I think its current name is correct.

@Calinou It is not a good name thought. All *Script classes are extended from Script but JavaScript not. I can’t find a better name for JavaScript language binding as there’s no namespace in godot script binding system.

Should we remove Node2D/Node3D/Control’s hide() and show() methods in favor of the visible property?

I actually like these functions, they make code very easy to read. Considering that showing and hiding is very common, I see no reason to remove them.

I’ve noticed that 2 is used throughout GDScript language exclusively compared to other core/scene classes which use to, so perhaps we already have consistency here… Those methods are technically part of the language, so GDScript aims to be less verbose.

Principle of Least Surprise vs “There should be one — and preferably only one — obvious way to do it.”

I welcomed append, and was confused by the lack of prepend.

Another advantage of push_back is the nice symmetry with pop_back. An advantage of append is that it makes the code look a little more idiomatic.

If performance is not impacted by aliases, it boils down to whether the expense of maintaining aliases is worth the comfort (sugar) and learning curve flattening provided to Godot users.

@nathanfranke the ultimate solution for this would likely be #26990.

I think the length of the naming name should be moderate. If people who have never learned programming read this code, it is like reading an English article again, which is great. Even if I haven’t learned programming, I know what the code is doing. The name should avoid ambiguity, avoid too many abbreviations, too many abbreviations, you need to check the document to know its function, but not intuitively see its function. But also avoid long names, because this will make the code too verbose and not concise enough. A balance must be found between the two! Disclaimer: English is not my native language. Too many abbreviations is really difficult to understand its function quickly, unless you remember the function of this function. The above is my personal opinion and my experience.

@opl- this is also discussed here: https://github.com/godotengine/godot-proposals/issues/287

Tween: Rename stop() to pause(), stop_all() to pause_all() (#43442)

This is covered by #41794

The whole existence of this megathread is the evidence that people are asking for it. These problems may be insignificant for you or someone else, but people do have problems with understanding the API because of bad naming. And this is the type of problems this issue collects. As for the significance of these changes overall, believe it or not, but tracking and implementing these is not taking away from the other development time.

And look at the example you gave and tried to explain:

Remove removes from a specific index where as erase removes the first instance of a value found.

You write that and see no reason to improve naming to be at least a bit more clear for all current and future Godot users?

@CarlGustavAlbertDwarfsteinYung empty can be an action if it’s read as a verb. is_empty is definitely a quality. Of course that confusion may depend on your level of English.

Also, even if a function was called send_formatted_string_to_standard_out in a modern code editor it can be typed as sfstso, or any other combination of the intermediate letters, if you so desire and the autocomplete will give you the only option.

Why all these renames are so long? You’re changing something simple and short to something really long.

You’re changing clip to intersection twice as long to type. You’re also changing Control.MOUSE_FILTER_PASS to Control.MOUSE_FILTER_PASSTHROUGH etc

I would prefer simpler and shorter less verbose changes. It’s a function name not also a description of the function.

I discovered methods property_can_revert and property_get_revert in the Inspector and reported them in #43078. However, I think they should be renamed with leading underscores to follow the conventions of _get, _set, and _get_property_list.

@aaronfranke For the other 207 cases, do you also suggest creating separate functions? If not, then this argument is not conclusive. In addition, I wrote above that if you can specify the parameter name, then it becomes readable without an IDE.

There are many cases where you need to check if a key is pressed and not only if it was just pressed.

Often, but not more often than without echo.

The presence of three methods (is_action_just_pressed, is_action_just_released, is_action_pressed) is confusing because you expect there to be an is_action_released method.

ADD. Which option is easier, at least visually?

The following methods should be changed Inconsistencies between

Input.is_action_just_pressed(action: String) -> bool
Input.is_action_just_released(action: String) -> bool
Input.is_action_pressed(action: String) -> bool

to

Input.is_action_pressed(action: String, allow_echo: bool = false) -> bool
Input.is_action_released(action: String) -> bool

for consistency with and

InputEvent.is_action_pressed(action: String, allow_echo: bool = false) -> bool
InputEvent.is_action_released(action: String) -> bool

need to be corrected.

P. S. I proceeded from the principle “The fewer similar methods, the better”.

@Xrayez I would avoid using the word “cast” at the start of a property, since I naturally read that as the verb “cast” and not the noun “cast”, and therefore cast_position likely wouldn’t have solved the original problem of not knowing this is a property and not a method (it would be easy to assume cast_position is a method that casts to a position). I like target_position.

Get_node is not limited to getting descendents, so that would be a very misleading name. The 2 methods need very different names because what they do is very different.

On Sat., Jul. 25, 2020, 3:14 p.m. golddotasksquestions, < notifications@github.com> wrote:

I remember the confusion I had for a long time in the beginning with find_node and get_node. I would really like find_descendant and get_descendant, as these would be true and informative @willnationsdev https://github.com/willnationsdev @Coldragon https://github.com/Coldragon The “wordyness” might not be everyones cu of tea, but imho is not a really issue as there is autocomplete and shorthand “$”.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/16863#issuecomment-663890652, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFMN5DJNBNB6ZOUIV62VX2DR5MVJBANCNFSM4ERRCEZA .

@MuffinManKen independent doesn’t sound very self-explanatory to me either.

What about exported or release?

In Godot 3.1, I added a standalone feature tag which evaluates to true when the project is running from an export template binary (debug or release). The opposite is editor, which evaluates to true when the project is running from an editor binary.

However, with time, I think it would be better to rename standalone to runner as it’s shorter and slightly more self-explanatory. What do you think?

I find get_node good, but find_node could be renamed find_child

String we should drop find_last() in favor of rfind(). Not exactly a rename, but it’s still worth discussing which one to keep.

@Coldragon It should be get_surface_material/set_surface_material and a property of surface_material.

It’s not “normal” set/get, they have an index for the target Surface (it’s a Vector inside Mesh class)

Texture (Texture2D) and Image

• get_data() in Texture (Texture2D) should be named get_image() and get_data() in Image should be named get_bytes() to be self-describing.

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

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.

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

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

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.

@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 would. If we go the “invert scale” route, it can’t be fixed automatically, unfortunately. Still, it might result in less confusion in the long term.

Just because someone else does 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 .

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

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.

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

@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 could also keep .tangent() as just an alias for .perpendicular(), no?

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

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

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…().

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.

P.S. We already did that rename the other way around in 2017.

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 in these last two 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 …

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

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

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 in all those cases.

For many people “layering” especially when working with 2D graphics or animation 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 various ways of “sorting” to accomplish this task.

The fact that we call the abstract commonality that Physics objects or Render objects might share “Layers”, while at the same time these abstract commonalities have nothing to do with the stacking appearance of visual layers (that’s “sorting”), 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”, “affected by group” for masks, or maybe some other term I can’t think of right now would be more accurate.

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 existing 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. They just learned the basics a new engine, which they now have to relearn again. Beginnings are hard, having to go through this twice too 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?

@Xrayez Change print to write? From Python to Pascal? 😆

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.

When 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 (2×, 4×, 8×, 16×), since only power-of-two values make sense here.

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

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

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.

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

EDIT: Doesn’t anymore.

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

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

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?

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.

As pointed out by @clayjohn, WORLD_MATRIX in CanvasItem shaders is actually a modelview matrix. @reduz agrees that in 4.0 we should replace it by actual model and view matrices, e.g. CANVAS_MATRIX and ITEM_MATRIX.

Morning! @akien-mga couldn’t we rename instance to new instead of instantiate? Having the same interface on PackedScene as Objects do for example removes some boilerplate for plugin creation especially, but probably more generally. @willnationsdev what do you think? I know you encountered this before.

Sorry if there is already a talk about this somewhere, I couldn’t find it by skimming through.

grabber_area -> slider_progress slider -> slider_background

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

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.

load_from_globals() in InputMap should be load_from_project_settings().

Need to remove get_selected_id() from OptionButton currently it always returns -1. After https://github.com/godotengine/godot/pull/21837 was merged get_selected_id() will return the same as get_selected().

@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.

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

• 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

@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.

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

From this #20228, Label.clip_text is not necessary anymore. I believe it’s the same for Button.clip_text.

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

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.

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

#16116