Update references to private class methods across the docs

Author: YuriSizov

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,15 +124,15 @@ 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
 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.
 
 ::