Fixed all errors in doc building

docs/source/Concept/Concept-Overview.md

@@ -4,26 +4,26 @@ This documentation cover more over-arching concepts of Evennia, often involving
 
 ## General concepts
 
-- [Asynchronous processing](Async-Process)
-- [On Soft-Code](Soft-Code)
-- [Using MUX as standard for default commands](Using-MUX-as-a-Standard)
+- [Asynchronous processing](./Async-Process)
+- [On Soft-Code](./Soft-Code)
+- [Using MUX as standard for default commands](./Using-MUX-as-a-Standard)
 
 ## Access 
 
-- [Permissions](Building-Permissions)
-- [Banning](Banning)
+- [Permissions](./Building-Permissions)
+- [Banning](./Banning)
 
 ## Extending the Server 
-- [Custom Protocols](Custom-Protocols)
-- [Bootstrap](Bootstrap-&-Evennia)
-- [Creating new models](New-Models)
+- [Custom Protocols](./Custom-Protocols)
+- [Bootstrap](./Bootstrap-&-Evennia)
+- [Creating new models](./New-Models)
 
 ## Text processing
 
-- [Change the language of the server](Internationalization)
-- [Server text-encoding](Text-Encodings)
-- [Text tags](TextTags)
+- [Change the language of the server](./Internationalization)
+- [Server text-encoding](./Text-Encodings)
+- [Text tags](./TextTags)
 
 ## Web features
 
-- [Web features](Web-Features)
+- [Web features](./Web-Features)

docs/source/Concept/Custom-Protocols.md

@@ -27,7 +27,7 @@ You <->
             InputFunc  
 ```
 
-(See the [Message Path](Messagepath) for the bigger picture of how data flows through Evennia). The
+(See the [Message Path](./Messagepath) for the bigger picture of how data flows through Evennia). The
 parts that needs to be customized to make your own custom protocol is the `Protocol + PortalSession`
 (which translates between data coming in/out over the wire to/from Evennia internal representation)
 as well as the `InputFunc` (which handles incoming data).

docs/source/Concept/Messagepath.md

@@ -34,7 +34,7 @@ The client sends data to Evennia in two ways.
  the client may send commands based on a timer or some trigger.
 
 Exactly how the inputcommand looks when it travels from the client to Evennia
-depends on the [Protocol](Custom-Protocols) used:
+depends on the [Protocol](./Custom-Protocols) used:
  - Telnet: A string. If GMCP or MSDP OOB protocols are used, this string will
  be formatted in a special way, but it's still a raw string. If Telnet SSL is
  active, the string will be encrypted.
@@ -175,7 +175,7 @@ In the *ServerSessionhandler*, the keywords from the `msg` method are collated i
 This will intelligently convert different input to the same form. So `msg("Hello")` will end up as
 an outputcommand `("text", ("Hello",), {})`.
 
-This is also the point where [Inlinefuncs](TextTags#inline-functions) are parsed, depending on the
+This is also the point where [Inlinefuncs](./TextTags#inline-functions) are parsed, depending on the
 session to receive the data. Said data is pickled together with the Session id then sent over the
 AMP bridge.
 

docs/source/Concept/OOB.md

@@ -8,7 +8,7 @@ window pane.
 ## Briefly on input/outputcommands
 
 Inside Evennia, all server-client communication happens in the same way (so plain text is also an
-'OOB message' as far as Evennia is concerned). The message follows the [Message Path](Messagepath).
+'OOB message' as far as Evennia is concerned). The message follows the [Message Path](./Messagepath).
 You should read up on that if you are unfamiliar with it. As the message travels along the path it
 has a standardized internal form: a tuple with a string, a tuple and a dict:
 
@@ -26,7 +26,7 @@ a matching *Outputfunc*. This is responsible for converting the internal Evennia
 form suitable to send over the wire to the Client. Outputfuncs are hard-coded. Which is chosen and
 how it processes the outgoing data depends on the nature of the client it's connected to. The only
 time one would want to add new outputfuncs is as part of developing support for a new Evennia
-[Protocol](Custom-Protocols).
+[Protocol](./Custom-Protocols).
 
 ## Sending and receiving an OOB message
 

docs/source/Concept/TextTags.md

@@ -37,7 +37,7 @@ available in all but the most ancient mud clients. The ANSI colours are **r**ed,
 first letter except for black which is abbreviated with the letter **x**. In ANSI there are "bright"
 and "normal" (darker) versions of each color, adding up to a total of 16 colours to use for
 foreground text. There are also 8 "background" colours. These have no bright alternative in ANSI
-(but Evennia uses the [Xterm256](TextTags#xterm256-colours) extension behind the scenes to offer
+(but Evennia uses the [Xterm256](./TextTags#xterm256-colours) extension behind the scenes to offer
 them anyway).
 
 To colour your text you put special tags in it. Evennia will parse these and convert them to the
@@ -76,7 +76,7 @@ set bright/normal explicitly.  Technically, `|h|!G` is identical to `|g`.
 
 > Note: The ANSI standard does not actually support bright backgrounds like `|[r` - the standard
 only supports "normal" intensity backgrounds.  To get around this Evennia instead implements these
-as [Xterm256 colours](TextTags#xterm256-colours) behind the scenes. If the client does not support
+as [Xterm256 colours](./TextTags#xterm256-colours) behind the scenes. If the client does not support
 Xterm256 the ANSI colors will be used instead and there will be no visible difference between using
 upper- and lower-case background tags.