Merge pull request #107576 from Elip100/patch-1

Docs: Fix typo and spacing in vector coordinates

doc/classes/InstancePlaceholder.xml

@@ -5,7 +5,7 @@
 	</brief_description>
 	<description>
 		Turning on the option [b]Load As Placeholder[/b] for an instantiated scene in the editor causes it to be replaced by an [InstancePlaceholder] when running the game, this will not replace the node in the editor. This makes it possible to delay actually loading the scene until calling [method create_instance]. This is useful to avoid loading large scenes all at once by loading parts of it selectively.
-		The [InstancePlaceholder] does not have a transform. This causes any child nodes to be positioned relatively to the [Viewport] from point (0,0), rather than their parent as displayed in the editor. Replacing the placeholder with a scene with a transform will transform children relatively to their parent again.
+		[b]Note:[/b] Like [Node], [InstancePlaceholder] does not have a transform. This causes any child nodes to be positioned relatively to the [Viewport] origin, rather than their parent as displayed in the editor. Replacing the placeholder with a scene with a transform will transform children relatively to their parent again.
 	</description>
 	<tutorials>
 	</tutorials>

doc/classes/PhysicsServer2D.xml

@@ -1124,7 +1124,7 @@
 			Constant to set/get a body's inertia. The default value of this parameter is [code]0.0[/code]. If the body's inertia is set to a value [code]<= 0.0[/code], then the inertia will be recalculated based on the body's shapes, mass, and center of mass.
 		</constant>
 		<constant name="BODY_PARAM_CENTER_OF_MASS" value="4" enum="BodyParameter">
-			Constant to set/get a body's center of mass position in the body's local coordinate system. The default value of this parameter is [code]Vector2(0,0)[/code]. If this parameter is never set explicitly, then it is recalculated based on the body's shapes when setting the parameter [constant BODY_PARAM_MASS] or when calling [method body_set_space].
+			Constant to set/get a body's center of mass position in the body's local coordinate system. The default value of this parameter is [code]Vector2(0, 0)[/code]. If this parameter is never set explicitly, then it is recalculated based on the body's shapes when setting the parameter [constant BODY_PARAM_MASS] or when calling [method body_set_space].
 		</constant>
 		<constant name="BODY_PARAM_GRAVITY_SCALE" value="5" enum="BodyParameter">
 			Constant to set/get a body's gravity multiplier. The default value of this parameter is [code]1.0[/code].

doc/classes/TileMapPattern.xml

@@ -5,7 +5,7 @@
 	</brief_description>
 	<description>
 		This resource holds a set of cells to help bulk manipulations of [TileMap].
-		A pattern always start at the [code](0,0)[/code] coordinates and cannot have cells with negative coordinates.
+		A pattern always starts at the [code](0, 0)[/code] coordinates and cannot have cells with negative coordinates.
 	</description>
 	<tutorials>
 	</tutorials>

doc/classes/Tween.xml

@@ -66,7 +66,7 @@
 			tween.TweenProperty(sprite, "position", Vector2.Zero, 1.0f);
 		[/csharp]
 		[/codeblocks]
-		In the example above, all children of a node are moved one after another to position (0, 0).
+		In the example above, all children of a node are moved one after another to position [code](0, 0)[/code].
 		You should avoid using more than one [Tween] per object's property. If two or more tweens animate one property at the same time, the last one created will take priority and assign the final value. If you want to interrupt and restart an animation, consider assigning the [Tween] to a variable:
 		[codeblocks]
 		[gdscript]

doc/classes/UndoRedo.xml

@@ -22,7 +22,7 @@
 			undo_redo.create_action("Move the node")
 			undo_redo.add_do_method(do_something)
 			undo_redo.add_undo_method(undo_something)
-			undo_redo.add_do_property(node, "position", Vector2(100,100))
+			undo_redo.add_do_property(node, "position", Vector2(100, 100))
 			undo_redo.add_undo_property(node, "position", node.position)
 			undo_redo.commit_action()
 		[/gdscript]

doc/classes/XRAnchor3D.xml

@@ -5,7 +5,7 @@
 	</brief_description>
 	<description>
 		The [XRAnchor3D] point is an [XRNode3D] that maps a real world location identified by the AR platform to a position within the game world. For example, as long as plane detection in ARKit is on, ARKit will identify and update the position of planes (tables, floors, etc.) and create anchors for them.
-		This node is mapped to one of the anchors through its unique ID. When you receive a signal that a new anchor is available, you should add this node to your scene for that anchor. You can predefine nodes and set the ID; the nodes will simply remain on 0,0,0 until a plane is recognized.
+		This node is mapped to one of the anchors through its unique ID. When you receive a signal that a new anchor is available, you should add this node to your scene for that anchor. You can predefine nodes and set the ID; the nodes will simply remain on [code](0, 0, 0)[/code] until a plane is recognized.
 		Keep in mind that, as long as plane detection is enabled, the size, placing and orientation of an anchor will be updated as the detection logic learns more about the real world out there especially if only part of the surface is in view.
 	</description>
 	<tutorials>

doc/classes/XRServer.xml

@@ -30,7 +30,7 @@
 			<param index="1" name="keep_height" type="bool" />
 			<description>
 				This is an important function to understand correctly. AR and VR platforms all handle positioning slightly differently.
-				For platforms that do not offer spatial tracking, our origin point (0, 0, 0) is the location of our HMD, but you have little control over the direction the player is facing in the real world.
+				For platforms that do not offer spatial tracking, our origin point [code](0, 0, 0)[/code] is the location of our HMD, but you have little control over the direction the player is facing in the real world.
 				For platforms that do offer spatial tracking, our origin point depends very much on the system. For OpenVR, our origin point is usually the center of the tracking space, on the ground. For other platforms, it's often the location of the tracking camera.
 				This method allows you to center your tracker on the location of the HMD. It will take the current location of the HMD and use that to adjust all your tracking data; in essence, realigning the real world to your player's current position in the game world.
 				For this method to produce usable results, tracking information must be available. This often takes a few frames after starting your game.