Add a reference to the Data paths doc in the Step by step guide (#3605)

getting_started/step_by_step/filesystem.rst

@@ -21,9 +21,9 @@ included. If a resource has sub-resources that are built-in, the resource is
 saved in a single file together with all the bundled sub-resources. For
 example, a font resource is often bundled together with the font textures.
 
-The Godot file system avoids using metadata files. Existing asset managers and VCSs are better than
-anything we can implement, so Godot tries its best to play along with SVN,
-Git, Mercurial, Perforce, etc.
+The Godot file system avoids using metadata files. Existing asset managers and VCSs 
+are better than anything we can implement, so Godot tries its best to play along 
+with SVN, Git, Mercurial, Perforce, etc.
 
 Example of file system contents:
 
@@ -38,21 +38,21 @@ Example of file system contents:
 project.godot
 -------------
 
-The project.godot file is the project description file, and it is always found at
-the root of the project. In fact, its location defines where the root is. This
+The ``project.godot`` file is the project description file, and it is always found 
+at the root of the project. In fact, its location defines where the root is. This
 is the first file that Godot looks for when opening a project.
 
 This file contains the project configuration in plain text, using the win.ini
-format. Even an empty project.godot can function as a basic definition of a blank
-project.
+format. Even an empty ``project.godot`` can function as a basic definition of 
+a blank project.
 
 Path delimiter
 --------------
 
 Godot only supports ``/`` as a path delimiter. This is done for
 portability reasons. All operating systems support this, even Windows,
-so a path such as ``c:\project\project.godot`` needs to be typed as
-``c:/project/project.godot``.
+so a path such as ``C:\project\project.godot`` needs to be typed as
+``C:/project/project.godot``.
 
 Resource path
 -------------
@@ -62,7 +62,7 @@ cumbersome and non-portable. To solve this problem, the special path
 ``res://`` was created.
 
 The path ``res://`` will always point at the project root (where
-project.godot is located, so ``res://project.godot`` is always
+``project.godot`` is located, so ``res://project.godot`` is always
 valid).
 
 This file system is read-write only when running the project locally from
@@ -73,9 +73,11 @@ read-only and writing will no longer be permitted.
 User path
 ---------
 
-Writing to disk is still needed for tasks such as saving game
-state or downloading content packs. To this end, the engine ensures that there is a
-special path ``user://`` that is always writable.
+Writing to disk is still needed for tasks such as saving game state or 
+downloading content packs. To this end, the engine ensures that there is a
+special path ``user://`` that is always writable. This path resolves 
+differently depending on the OS the project is running on. Local path 
+resolution is further explained in :ref:`doc_data_paths`.
 
 Host file system
 ----------------
@@ -93,14 +95,14 @@ moving assets around (renaming them or moving them from one path to another insi
 the project) will break existing references to these assets. These references will
 have to be re-defined to point at the new asset location.
 
-To avoid this, do all your move, delete and rename operations from within Godot, on the FileSystem
-dock. Never move assets from outside Godot, or dependencies will have to be
-fixed manually (Godot detects this and helps you fix them anyway, but why
+To avoid this, do all your move, delete and rename operations from within Godot, on 
+the FileSystem dock. Never move assets from outside Godot, or dependencies will have 
+to be fixed manually (Godot detects this and helps you fix them anyway, but why
 go the hard route?).
 
 The second is that, under Windows and macOS, file and path names are case insensitive.
-If a developer working in a case insensitive host file system saves an asset as "myfile.PNG",
-but then references it as "myfile.png", it will work fine on their platform, but not
+If a developer working in a case insensitive host file system saves an asset as ``myfile.PNG``,
+but then references it as ``myfile.png``, it will work fine on their platform, but not
 on other platforms, such as Linux, Android, etc. This may also apply to exported binaries,
 which use a compressed package to store all files.