Merge pull request #9 from TerXIII/main

Additional examples

ref/atom/movable/var/screen_loc.md

@@ -109,10 +109,17 @@ items, you should not use the full `window.control` ID, just the
 [id](/ref/skin/param/id.md) of the control itself. Map controls
 should always have a unique `id`.
 
+### Invalid screen locs
+Attempting to add an object to the client's screen with an invalid
+screen loc string will produce a runtime error. However, an empty,
+or null screen loc will produce no such error. A screen object can be
+prevented from drawing on the screen by temporarily emptying its screen_loc,
+but will retain its precedence in the screen list.
+
 > [!TIP] 
 > **See also:**
 > +   [HUD / screen objects](/ref/notes/HUD.md) 
 > +   [layer var (atom)](/ref/atom/var/layer.md) 
 > +   [screen var (client)](/ref/client/var/screen.md) 
 > +   [view var (client)](/ref/client/var/view.md) 
-> +   [map_format var (world)](/ref/world/var/map_format.md) 
+> +   [map_format var (world)](/ref/world/var/map_format.md) 

ref/datum/proc/Del.md

@@ -5,7 +5,7 @@
 
 **When:**
 +   Called when the object is destroyed, for example by using the `del`
-    instruction.
+    instruction, or during garbage collection.
 
 **Default action:**
 +   Delete the object. The contents of atomic objects are also destroyed
@@ -19,9 +19,9 @@ to be called at that time, you should explicitly call it from
 
 > [!NOTE]
 > **Always** call `..()` at the end of this
-> proc if you override it.
+> proc if you override it. Not doing so will prevent the object from being destroyed.
 
 > [!TIP] 
 > **See also:**
 > +   [del proc](/ref/proc/del.md) 
-> +   [garbage collection](/ref/DM/garbage.md) 
+> +   [garbage collection](/ref/DM/garbage.md) 

ref/notes/gliding.md

@@ -28,7 +28,22 @@ than `world.fps`, it will be scaled appropriately.
 Whether an object glides or jumps is based on how far it moves relative to its
 `step_size` value, which by default is a full tile width. If the
 movement goes too far past `step_size` in the X or Y directions, it\'s
-no longer a glide. 
+no longer a glide.
+
+To achieve smooth gliding, glide_size should be set to `step_size / ticks`,
+where ticks is the number of world ticks that the movement should be gliding for.
+This can be calculated `max(ceil(step_time / world.tick_lag),1)`. To achieve smooth
+gliding in both pixel movement or tile movement modes, you can create a simple wrapper
+around step() to set up your glide_size:
+
+```dm
+atom/movable
+    proc
+        Step(Dir=src.dir, Dist=src.step_size, Delay=world.tick_lag)
+            step_size = Dist
+            glide_size = step_size / max( ceil( Delay / world.tick_lag ) , 1 )
+            return step(src,Dir)
+```
 
 The `animate_movement` var can be used to
 control the way in which an object glides, or suppress gliding
@@ -50,4 +65,4 @@ gliding on an atom\'s `glide_size` value.
 
 > [!TIP] 
 > **See also:**
-> +   [Pixel movement](/ref/notes/pixel-movement.md) 
+> +   [Pixel movement](/ref/notes/pixel-movement.md) 

ref/operator/path/..md

@@ -17,22 +17,89 @@ path from the point of reference.
 ### Example:
 
 ```dm
- area var/area north_exit south_exit east_exit west_exit
-Entered(O) O << name return ..() Castle Main_Gate north_exit =
-.Castle_Entryway south_exit = .Moat_Bridge Castle_Entryway south_exit =
-.Main_Gate Moat_Bridge north_exit = .Main_Gate south_exit =
-.Village/Guard_Post Village Guard_Post north_exit = .Castle/Moat_Bridge
-south_exit = .Square Square north_exit = .Guard_Post //handle movement
-client/Move(Dest,Dir) var/area/room = usr.loc if(istype(room)) //in a
-room switch(Dir) if(NORTH) Dest = room.north_exit if(SOUTH) Dest =
-room.south_exit if(EAST) Dest = room.east_exit if(WEST) Dest =
-room.west_exit return ..() //set the starting position for new logins
-mob/Login() if(!loc) Move(locate(/area/Castle/Main_Gate)) return ..()
+area
+    var/area
+        north_exit
+        south_exit
+        east_exit
+        west_exit
 
+    Entered(O)
+        O << name
+        return ..()
+
+    Castle
+        Main_Gate
+            north_exit = .Castle_Entryway
+            south_exit = .Moat_Bridge
+        Castle_Entryway
+            south_exit = .Main_Gate
+        Moat_Bridge
+            north_exit = .Main_Gate
+            south_exit = .Village/Guard_Post
+    Village
+        Guard_Post
+            north_exit = .Castle/Moat_Bridge
+            south_exit = .Square
+        Square
+            north_exit = .Guard_Post
+
+//handle movement
+client/Move(Dest,Dir)
+    var/area/room = usr.loc
+    if(istype(room)) //in a room
+        switch(Dir)
+            if(NORTH) Dest = room.north_exit
+            if(SOUTH) Dest = room.south_exit
+            if(EAST)  Dest = room.east_exit
+            if(WEST)  Dest = room.west_exit
+    return ..()
+
+//set the starting position for new logins
+mob/Login()
+    if(!loc) Move(locate(/area/Castle/Main_Gate))
+    return ..()
+```
+
+The dot operator can also be used to navigate the type tree at compile-time.
+One (.) operator will begin at the current compile-time path node.
+Two (..) will specify the parent of the current path.
+Three (...) will specify the grandparent of the current path.
+Each further . operator will move one level further up.
+
+```dm
+turf
+    child1
+        .grandchild1 //full path: /turf/child1/grandchild1
+    child2
+        ..child3 //full path: /turf/child3
+        ...datum1 //full path: /datum1
 ```
 
+You can also separate these with path operators to make them more readable:
+
+```dm
+turf
+    child1
+        ./grandchild1
+    child2
+        ../child3
+        ../../datum1
+```
+
+The same is true for referencing paths at compile-time:
+
+```dm
+turf
+    child1
+        var
+            child_path = .grandchild1
+            sibling_path = ..child2
+        grandchild1
+    child2
+```
 
 > [!TIP] 
 > **See also:**
 > +   [/ path operator](/ref/operator/path//.md) 
-> +   [: path operator](/ref/operator/path/:.md) 
+> +   [: path operator](/ref/operator/path/:.md)