Update references to private class methods across the docs

contributing/development/core_and_modules/object_class.rst

@@ -240,7 +240,7 @@ Adding signals to a class is done in ``_bind_methods``, using the
 Notifications
 -------------
 
-All objects in Godot have a :ref:`_notification <class_Object_method__notification>`
+All objects in Godot have a :ref:`_notification <class_Object_private_method__notification>`
 method that allows it to respond to engine level callbacks that may relate to it.
 More information can be found on the :ref:`doc_godot_notifications` page.
 

getting_started/step_by_step/signals.rst

@@ -266,7 +266,7 @@ We need to do two operations to connect the nodes via code:
           listen to the Timer's "timeout" signal.
 
 We want to connect the signal when the scene is instantiated, and we can do that
-using the :ref:`Node._ready() <class_Node_method__ready>` built-in function,
+using the :ref:`Node._ready() <class_Node_private_method__ready>` built-in function,
 which is called automatically by the engine when a node is fully instantiated.
 
 To get a reference to a node relative to the current one, we use the method

tutorials/best_practices/godot_notifications.rst

@@ -4,7 +4,7 @@ Godot notifications
 ===================
 
 Every Object in Godot implements a
-:ref:`_notification <class_Object_method__notification>` method. Its purpose is to
+:ref:`_notification <class_Object_private_method__notification>` method. Its purpose is to
 allow the Object to respond to a variety of engine-level callbacks that may
 relate to it. For example, if the engine tells a
 :ref:`CanvasItem <class_CanvasItem>` to "draw", it will call
@@ -53,7 +53,7 @@ One can access all these custom notifications from the universal
   overridden by scripts.
 
   A classic example is the
-  :ref:`_init <class_Object_method__init>` method in Object. While it has no
+  :ref:`_init <class_Object_private_method__init>` method in Object. While it has no
   ``NOTIFICATION_*`` equivalent, the engine still calls the method. Most languages
   (except C#) rely on it as a constructor.
 

tutorials/inputs/inputevent.rst

@@ -74,35 +74,35 @@ received input, in order:
 2. Next if an embedded Window is focused, the event is sent to that Window and processed in
    the Windows Viewport and afterwards treated as handled. If no embedded Window is focused,
    the event is sent to the nodes of the current viewport in the following order.
-3. First of all, the standard :ref:`Node._input() <class_Node_method__input>` function
+3. First of all, the standard :ref:`Node._input() <class_Node_private_method__input>` function
    will be called in any node that overrides it (and hasn't disabled input processing with :ref:`Node.set_process_input() <class_Node_method_set_process_input>`).
    If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the event will
    not spread any more. This ensures that you can filter all events of interest, even before the GUI.
-   For gameplay input, :ref:`Node._unhandled_input() <class_Node_method__unhandled_input>` is generally a better fit, because it allows the GUI to intercept the events.
+   For gameplay input, :ref:`Node._unhandled_input() <class_Node_private_method__unhandled_input>` is generally a better fit, because it allows the GUI to intercept the events.
 4. Second, it will try to feed the input to the GUI, and see if any
    control can receive it. If so, the :ref:`Control <class_Control>` will be called via the
-   virtual function :ref:`Control._gui_input() <class_Control_method__gui_input>` and the signal
+   virtual function :ref:`Control._gui_input() <class_Control_private_method__gui_input>` and the signal
    "gui_input" will be emitted (this function is re-implementable by
    script by inheriting from it). If the control wants to "consume" the
    event, it will call :ref:`Control.accept_event() <class_Control_method_accept_event>` and the event will
    not spread any more. Use the :ref:`Control.mouse_filter <class_Control_property_mouse_filter>`
    property to control whether a :ref:`Control <class_Control>` is notified
-   of mouse events via :ref:`Control._gui_input() <class_Control_method__gui_input>`
+   of mouse events via :ref:`Control._gui_input() <class_Control_private_method__gui_input>`
    callback, and whether these events are propagated further.
-5. If so far no one consumed the event, the :ref:`Node._shortcut_input() <class_Node_method__shortcut_input>` callback
+5. If so far no one consumed the event, the :ref:`Node._shortcut_input() <class_Node_private_method__shortcut_input>` callback
    will be called if overridden (and not disabled with
    :ref:`Node.set_process_shortcut_input() <class_Node_method_set_process_shortcut_input>`).
    This happens only for :ref:`InputEventKey <class_InputEventKey>`,
    :ref:`InputEventShortcut <class_InputEventShortcut>` and :ref:`InputEventJoypadButton <class_InputEventJoypadButton>`.
    If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the
    event will not spread any more. The shortcut input callback is ideal for treating events that are intended as shortcuts.
-6. If so far no one consumed the event, the :ref:`Node._unhandled_key_input() <class_Node_method__unhandled_key_input>` callback
+6. If so far no one consumed the event, the :ref:`Node._unhandled_key_input() <class_Node_private_method__unhandled_key_input>` callback
    will be called if overridden (and not disabled with
    :ref:`Node.set_process_unhandled_key_input() <class_Node_method_set_process_unhandled_key_input>`).
    This happens only if the event is a :ref:`InputEventKey <class_InputEventKey>`.
    If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the
    event will not spread any more. The unhandled key input callback is ideal for key events.
-7. If so far no one consumed the event, the :ref:`Node._unhandled_input() <class_Node_method__unhandled_input>` callback
+7. If so far no one consumed the event, the :ref:`Node._unhandled_input() <class_Node_private_method__unhandled_input>` callback
    will be called if overridden (and not disabled with
    :ref:`Node.set_process_unhandled_input() <class_Node_method_set_process_unhandled_input>`).
    If any function consumes the event, it can call :ref:`Viewport.set_input_as_handled() <class_Viewport_method_set_input_as_handled>`, and the
@@ -112,10 +112,10 @@ received input, in order:
    enabled in :ref:`Project Settings <class_ProjectSettings_property_physics/common/enable_object_picking>`.
    In the case of a 3D scene if a :ref:`Camera3D <class_Camera3D>` is assigned to the Viewport, a ray
    to the physics world (in the ray direction from the click) will be cast. If this ray hits an object,
-   it will call the :ref:`CollisionObject3D._input_event() <class_CollisionObject3D_method__input_event>`
+   it will call the :ref:`CollisionObject3D._input_event() <class_CollisionObject3D_private_method__input_event>`
    function in the relevant physics object (bodies receive this callback by default, but areas do
    not. This can be configured through :ref:`Area3D <class_Area3D>` properties).
-   In the case of a 2D scene, conceptually the same happens with :ref:`CollisionObject2D._input_event() <class_CollisionObject2D_method__input_event>`.
+   In the case of a 2D scene, conceptually the same happens with :ref:`CollisionObject2D._input_event() <class_CollisionObject2D_private_method__input_event>`.
 
 When sending events to its child and descendant nodes, the viewport will do so, as depicted in
 the following graphic, in a reverse depth-first order, starting with the node at the bottom of
@@ -124,7 +124,7 @@ and SubViewports.
 
 .. image:: img/input_event_scene_flow.png
 
-This order doesn't apply to :ref:`Control._gui_input() <class_Control_method__gui_input>`, which uses
+This order doesn't apply to :ref:`Control._gui_input() <class_Control_private_method__gui_input>`, which uses
 a different method based on event location or focused Control.
 
 Since Viewports don't send events to other :ref:`SubViewports <class_SubViewport>`, one of the following
@@ -132,7 +132,7 @@ methods has to be used:
 
 1. Use a :ref:`SubViewportContainer <class_SubViewportContainer>`, which automatically
    sends events to its child :ref:`SubViewports <class_SubViewport>` after
-   :ref:`Node._input() <class_Node_method__input>` or :ref:`Control._gui_input() <class_Control_method__gui_input>`.
+   :ref:`Node._input() <class_Node_private_method__input>` or :ref:`Control._gui_input() <class_Control_private_method__gui_input>`.
 2. Implement event propagation based on the individual requirements.
 
 GUI events also travel up the scene tree but, since these events target

tutorials/io/binary_serialization_api.rst

@@ -453,7 +453,7 @@ For each property:
    Not all properties are included. Only properties that are configured with the
    :ref:`PROPERTY_USAGE_STORAGE<class_@GlobalScope_constant_PROPERTY_USAGE_STORAGE>`
    flag set will be serialized. You can add a new usage flag to a property by overriding the
-   :ref:`_get_property_list<class_Object_method__get_property_list>`
+   :ref:`_get_property_list<class_Object_private_method__get_property_list>`
    method in your class. You can also check how property usage is configured by
    calling ``Object._get_property_list`` See
    :ref:`PropertyUsageFlags<enum_@GlobalScope_PropertyUsageFlags>` for the

tutorials/io/saving_games.rst

@@ -376,7 +376,7 @@ approach for storing game state, and you can use it with the functions
 Note that not all properties are included. Only properties that are configured
 with the :ref:`PROPERTY_USAGE_STORAGE<class_@GlobalScope_constant_PROPERTY_USAGE_STORAGE>`
 flag set will be serialized. You can add a new usage flag to a property by overriding the
-:ref:`_get_property_list<class_Object_method__get_property_list>`
+:ref:`_get_property_list<class_Object_private_method__get_property_list>`
 method in your class. You can also check how property usage is configured by
 calling ``Object._get_property_list``.
 See :ref:`PropertyUsageFlags<enum_@GlobalScope_PropertyUsageFlags>` for the

tutorials/math/vector_math.rst

@@ -174,8 +174,8 @@ can find the position for step 2 by adding the velocity to the current position.
 
          In a typical 2D game scenario, you would have a velocity in pixels per
          second, and multiply it by the ``delta`` parameter (time elapsed since
-         the previous frame) from the :ref:`_process() <class_Node_method__process>`
-         or :ref:`_physics_process() <class_Node_method__physics_process>`
+         the previous frame) from the :ref:`_process() <class_Node_private_method__process>`
+         or :ref:`_physics_process() <class_Node_private_method__physics_process>`
          callbacks.
 
 Pointing toward a target

tutorials/physics/physics_introduction.rst

@@ -83,17 +83,17 @@ These nodes allow you to draw the shape directly in the editor workspace.
 Physics process callback
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-The physics engine runs at a fixed rate (a default of 60 iterations per second). This rate 
+The physics engine runs at a fixed rate (a default of 60 iterations per second). This rate
 is typically different from the frame rate which fluctuates based on what is rendered and
 available resources.
 
-It is important that all physics related code runs at this fixed rate. Therefore Godot 
+It is important that all physics related code runs at this fixed rate. Therefore Godot
 differentiates :ref:`between physics and idle processing <doc_idle_and_physics_processing>`.
-Code that runs each frame is called idle processing and code that runs on each physics 
-tick is called physics processing. Godot provides two different callbacks, one for each 
+Code that runs each frame is called idle processing and code that runs on each physics
+tick is called physics processing. Godot provides two different callbacks, one for each
 of those processing rates.
 
-The physics callback, :ref:`Node._physics_process() <class_Node_method__physics_process>`, 
+The physics callback, :ref:`Node._physics_process() <class_Node_private_method__physics_process>`,
 is called before each physics step. Any code that needs to access a body's properties should
 be run in here. This method will be passed a ``delta``
 parameter, which is a floating-point number equal to the time passed in
@@ -249,7 +249,7 @@ automatically be calculated by the physics engine.
 However, if you do wish to have some control over the body, you should take
 care - altering the ``position``, ``linear_velocity``, or other physics properties
 of a rigid body can result in unexpected behavior. If you need to alter any
-of the physics-related properties, you should use the :ref:`_integrate_forces() <class_RigidBody2D_method__integrate_forces>`
+of the physics-related properties, you should use the :ref:`_integrate_forces() <class_RigidBody2D_private_method__integrate_forces>`
 callback instead of ``_physics_process()``. In this callback, you have access
 to the body's :ref:`PhysicsDirectBodyState2D <class_PhysicsDirectBodyState2D>`,
 which allows for safely changing properties and synchronizing them with

tutorials/physics/ray-casting.rst

@@ -40,7 +40,7 @@ Accessing space
 Godot physics runs by default in the same thread as game logic, but may
 be set to run on a separate thread to work more efficiently. Due to
 this, the only time accessing space is safe is during the
-:ref:`Node._physics_process() <class_Node_method__physics_process>`
+:ref:`Node._physics_process() <class_Node_private_method__physics_process>`
 callback. Accessing it from outside this function may result in an error
 due to space being *locked*.
 
@@ -158,17 +158,17 @@ with Area3D, the boolean parameter ``collide_with_areas`` must be set to ``true`
  .. code-tab:: gdscript GDScript
 
         const RAY_LENGTH = 1000
-        
+
         func _physics_process(delta):
             var space_state = get_world_3d().direct_space_state
             var cam = $Camera3D
             var mousepos = get_viewport().get_mouse_position()
-        
+
             var origin = cam.project_ray_origin(mousepos)
             var end = origin + cam.project_ray_normal(mousepos) * RAY_LENGTH
             var query = PhysicsRayQueryParameters3D.create(origin, end)
             query.collide_with_areas = true
-            
+
             var result = space_state.intersect_ray(query)
 
 Collision exceptions
@@ -182,7 +182,7 @@ as shown in the following image:
 .. image:: img/raycast_falsepositive.webp
 
 To avoid self-intersection, the ``intersect_ray()`` parameters object can take an
-array of exceptions via its ``exclude`` property. This is an example of how to use it 
+array of exceptions via its ``exclude`` property. This is an example of how to use it
 from a CharacterBody2D or any other collision object node:
 
 .. tabs::
@@ -231,8 +231,8 @@ member variable. The array of exceptions can be supplied as the last argument as
 
     func _physics_process(delta):
         var space_state = get_world_2d().direct_space_state
-        var query = PhysicsRayQueryParameters2D.create(global_position, target_position, 
-            collision_mask, [self]) 
+        var query = PhysicsRayQueryParameters2D.create(global_position, target_position,
+            collision_mask, [self])
         var result = space_state.intersect_ray(query)
 
  .. code-tab:: csharp

tutorials/plugins/editor/3d_gizmos.rst

@@ -66,7 +66,7 @@ to 3.1+, you should go with the second approach.
 Simple approach
 ---------------
 
-The first step is to, in our custom gizmo plugin, override the :ref:`_has_gizmo()<class_EditorNode3DGizmoPlugin_method__has_gizmo>`
+The first step is to, in our custom gizmo plugin, override the :ref:`_has_gizmo()<class_EditorNode3DGizmoPlugin_private_method__has_gizmo>`
 method so that it returns ``true`` when the node parameter is of our target type.
 
 ::
@@ -80,7 +80,7 @@ method so that it returns ``true`` when the node parameter is of our target type
 
     # ...
 
-Then we can override methods like :ref:`_redraw()<class_EditorNode3DGizmoPlugin_method__redraw>`
+Then we can override methods like :ref:`_redraw()<class_EditorNode3DGizmoPlugin_private_method__redraw>`
 or all the handle related ones.
 
 ::
@@ -172,7 +172,7 @@ maybe because we want to have some state stored in each gizmo or because we are
 an old gizmo plugin and we don't want to go through the rewriting process.
 
 In these cases all we need to do is, in our new gizmo plugin, override
-:ref:`_create_gizmo()<class_EditorNode3DGizmoPlugin_method__create_gizmo>`, so it returns our custom gizmo implementation
+:ref:`_create_gizmo()<class_EditorNode3DGizmoPlugin_private_method__create_gizmo>`, so it returns our custom gizmo implementation
 for the Node3D nodes we want to target.
 
 ::

tutorials/plugins/editor/import_plugins.rst

@@ -100,7 +100,7 @@ Let's begin to code our plugin, one method at time:
         return "demos.sillymaterial"
 
 The first method is the
-:ref:`_get_importer_name()<class_EditorImportPlugin_method__get_importer_name>`. This is a
+:ref:`_get_importer_name()<class_EditorImportPlugin_private_method__get_importer_name>`. This is a
 unique name for your plugin that is used by Godot to know which import was used
 in a certain file. When the files needs to be reimported, the editor will know
 which plugin to call.
@@ -110,7 +110,7 @@ which plugin to call.
     func _get_visible_name():
         return "Silly Material"
 
-The :ref:`_get_visible_name()<class_EditorImportPlugin_method__get_visible_name>` method is
+The :ref:`_get_visible_name()<class_EditorImportPlugin_private_method__get_visible_name>` method is
 responsible for returning the name of the type it imports and it will be shown to the
 user in the Import dock.
 
@@ -124,7 +124,7 @@ descriptive name for your plugin.
         return ["mtxt"]
 
 Godot's import system detects file types by their extension. In the
-:ref:`_get_recognized_extensions()<class_EditorImportPlugin_method__get_recognized_extensions>`
+:ref:`_get_recognized_extensions()<class_EditorImportPlugin_private_method__get_recognized_extensions>`
 method you return an array of strings to represent each extension that this
 plugin can understand. If an extension is recognized by more than one plugin,
 the user can select which one to use when importing the files.
@@ -198,7 +198,7 @@ plugin:
     func _get_preset_count():
         return Presets.size()
 
-The :ref:`_get_preset_count() <class_EditorImportPlugin_method__get_preset_count>` method
+The :ref:`_get_preset_count() <class_EditorImportPlugin_private_method__get_preset_count>` method
 returns the amount of presets that this plugins defines. We only have one preset
 now, but we can make this method future-proof by returning the size of our
 ``Presets`` enumeration.
@@ -214,7 +214,7 @@ now, but we can make this method future-proof by returning the size of our
 
 
 Here we have the
-:ref:`_get_preset_name() <class_EditorImportPlugin_method__get_preset_name>` method, which
+:ref:`_get_preset_name() <class_EditorImportPlugin_private_method__get_preset_name>` method, which
 gives names to the presets as they will be presented to the user, so be sure to
 use short and clear names.
 
@@ -239,7 +239,7 @@ you do this you have to be careful when you add more presets.
                 return []
 
 This is the method which defines the available options.
-:ref:`_get_import_options() <class_EditorImportPlugin_method__get_import_options>` returns
+:ref:`_get_import_options() <class_EditorImportPlugin_private_method__get_import_options>` returns
 an array of dictionaries, and each dictionary contains a few keys that are
 checked to customize the option as its shown to the user. The following table
 shows the possible keys:
@@ -277,7 +277,7 @@ of options first and then change it based on the preset.
         return true
 
 For the
-:ref:`_get_option_visibility() <class_EditorImportPlugin_method__get_option_visibility>`
+:ref:`_get_option_visibility() <class_EditorImportPlugin_private_method__get_option_visibility>`
 method, we simply return ``true`` because all of our options (i.e. the single
 one we defined) are visible all the time.
 
@@ -288,7 +288,7 @@ The ``import`` method
 ---------------------
 
 The heavy part of the process, responsible for converting the files into
-resources, is covered by the :ref:`_import() <class_EditorImportPlugin_method__import>`
+resources, is covered by the :ref:`_import() <class_EditorImportPlugin_private_method__import>`
 method. Our sample code is a bit long, so let's split in a few parts:
 
 ::

tutorials/plugins/editor/making_plugins.rst

@@ -101,8 +101,8 @@ editor, and it must inherit from :ref:`class_EditorPlugin`.
 
 It's important to deal with initialization and clean-up of resources.
 A good practice is to use the virtual function
-:ref:`_enter_tree() <class_Node_method__enter_tree>` to initialize your plugin and
-:ref:`_exit_tree() <class_Node_method__exit_tree>` to clean it up. Thankfully,
+:ref:`_enter_tree() <class_Node_private_method__enter_tree>` to initialize your plugin and
+:ref:`_exit_tree() <class_Node_private_method__exit_tree>` to clean it up. Thankfully,
 the dialog generates these callbacks for you. Your script should look something
 like this:
 

tutorials/scripting/c_sharp/c_sharp_exports.rst

@@ -540,9 +540,9 @@ common exporting features which can be implemented with a low-level API.
 
 Before reading further, you should get familiar with the way properties are
 handled and how they can be customized with
-:ref:`_Set() <class_Object_method__set>`,
-:ref:`_Get() <class_Object_method__get>`, and
-:ref:`_GetPropertyList() <class_Object_method__get_property_list>` methods as
+:ref:`_Set() <class_Object_private_method__set>`,
+:ref:`_Get() <class_Object_private_method__get>`, and
+:ref:`_GetPropertyList() <class_Object_private_method__get_property_list>` methods as
 described in :ref:`doc_accessing_data_or_logic_from_object`.
 
 .. seealso:: For binding properties using the above methods in C++, see

tutorials/scripting/gdscript/gdscript_exports.rst

@@ -386,9 +386,9 @@ common exporting features which can be implemented with a low-level API.
 
 Before reading further, you should get familiar with the way properties are
 handled and how they can be customized with
-:ref:`_set() <class_Object_method__set>`,
-:ref:`_get() <class_Object_method__get>`, and
-:ref:`_get_property_list() <class_Object_method__get_property_list>` methods as
+:ref:`_set() <class_Object_private_method__set>`,
+:ref:`_get() <class_Object_private_method__get>`, and
+:ref:`_get_property_list() <class_Object_private_method__get_property_list>` methods as
 described in :ref:`doc_accessing_data_or_logic_from_object`.
 
 .. seealso:: For binding properties using the above methods in C++, see

tutorials/scripting/idle_and_physics_processing.rst

@@ -5,8 +5,8 @@ Idle and Physics Processing
 
 Games run in a loop. Each frame, you need to update the state of your game world
 before drawing it on screen. Godot provides two virtual methods in the Node
-class to do so: :ref:`Node._process() <class_Node_method__process>` and
-:ref:`Node._physics_process() <class_Node_method__physics_process>`. If you
+class to do so: :ref:`Node._process() <class_Node_private_method__process>` and
+:ref:`Node._physics_process() <class_Node_private_method__physics_process>`. If you
 define either or both in a script, the engine will call them automatically.
 
 There are two types of processing available to you:

tutorials/scripting/overridable_functions.rst

@@ -99,8 +99,8 @@ information, read the dedicated documentation:
     }
 
 Two more essential built-in node callback functions are
-:ref:`Node._unhandled_input() <class_Node_method__unhandled_input>` and
-:ref:`Node._input() <class_Node_method__input>`, which you use to both receive
+:ref:`Node._unhandled_input() <class_Node_private_method__unhandled_input>` and
+:ref:`Node._input() <class_Node_private_method__input>`, which you use to both receive
 and process individual input events. The ``_unhandled_input()`` method receives
 every key press, mouse click, etc. that have not been handled already in an
 ``_input()`` callback or in a user interface component. You want to use it for
@@ -138,7 +138,7 @@ To learn more about inputs in Godot, see the :ref:`Input section <toc-learn-feat
 
 There are some more overridable functions like
 :ref:`Node._get_configuration_warnings()
-<class_Node_method__get_configuration_warnings>`. Specialized node types provide
-more callbacks like :ref:`CanvasItem._draw() <class_CanvasItem_method__draw>` to
+<class_Node_private_method__get_configuration_warnings>`. Specialized node types provide
+more callbacks like :ref:`CanvasItem._draw() <class_CanvasItem_private_method__draw>` to
 draw programmatically or :ref:`Control._gui_input()
-<class_Control_method__gui_input>` to handle clicks and input on UI elements.
+<class_Control_private_method__gui_input>` to handle clicks and input on UI elements.

tutorials/ui/custom_gui_controls.rst

@@ -79,7 +79,7 @@ the minimum size will make sure your custom control is not squished by
 the other controls in the container.
 
 To provide this callback, just override
-:ref:`Control._get_minimum_size() <class_Control_method__get_minimum_size>`,
+:ref:`Control._get_minimum_size() <class_Control_private_method__get_minimum_size>`,
 for example:
 
 .. tabs::
@@ -130,7 +130,7 @@ when:
    :ref:`Control.focus_mode <class_Control_property_focus_mode>`.
 
 This function is
-:ref:`Control._gui_input() <class_Control_method__gui_input>`.
+:ref:`Control._gui_input() <class_Control_private_method__gui_input>`.
 Simply override it in your control. No processing needs to be set.
 
 .. tabs::