Resync all links and fix issues with auto-relink

docs/source/Concept/Async-Process.md

@@ -90,7 +90,7 @@ line quite pointless for processing any data from the function. Instead one has
 - `at_err_kwargs` - an optional dictionary that will be fed as keyword arguments to the `at_err`
   errback.
 
-An example of making an asynchronous call from inside a [Command](Commands) definition:
+An example of making an asynchronous call from inside a [Command](Component/Commands) definition:
 
 ```python
     from evennia import utils, Command
@@ -139,7 +139,7 @@ sleep.
 ```
 
 This will delay the execution of the callback for 10 seconds. This function is explored much more in
-the [Command Duration Tutorial](Command-Duration).
+the [Command Duration Tutorial](Howto/Command-Duration).
 
 You can also try the following snippet just see how it works:
 

docs/source/Concept/Banning.md

@@ -114,14 +114,14 @@ is not what you want in this case.
 
 - **cboot mychannel = thomas** -- Boot a subscriber from a channel you control
 - **clock mychannel = control:perm(Admin);listen:all();send:all()** -- Fine control of access to
-your channel using [lock definitions](Locks).
+your channel using [lock definitions](Component/Locks).
 
 Locking a specific command (like `page`) is accomplished like so: 
 1. Examine the source of the command. [The default `page` command class](
 https://github.com/evennia/evennia/blob/master/evennia/commands/default/comms.py#L686) has the lock
 string **"cmd:not pperm(page_banned)"**. This means that unless the player has the 'permission'
 "page_banned" they can use this command. You can assign any lock string to allow finer customization
-in your commands. You might look for the value of an [Attribute](Attributes) or [Tag](Tags), your
+in your commands. You might look for the value of an [Attribute](Component/Attributes) or [Tag](Component/Tags), your
 current location etc.
 2. **perm/account thomas = page_banned** -- Give the account the 'permission' which causes (in this
 case) the lock to fail.

docs/source/Concept/Building-Permissions.md

@@ -2,7 +2,7 @@
 
 
 *OBS: This gives only a brief introduction to the access system. Locks and permissions are fully
-detailed* [here](Locks).
+detailed* [here](Component/Locks).
 
 ## The super user
 
@@ -17,7 +17,7 @@ but one superuser.
 
 Whereas permissions can be used for anything, those put in `settings.PERMISSION_HIERARCHY` will have
 a ranking relative each other as well. We refer to these types of permissions as *hierarchical
-permissions*. When building locks to check these permissions, the `perm()` [lock function](Locks) is
+permissions*. When building locks to check these permissions, the `perm()` [lock function](Component/Locks) is
 used. By default Evennia creates the following hierarchy (spelled exactly like this):
 
 1. **Developers** basically have the same access as superusers except that they do *not* sidestep

docs/source/Concept/Command-System.md

@@ -1,9 +1,9 @@
 # Command System
 
-- [Commands](Commands) 
-- [Command Sets](Command-Sets)
-- [Command Auto-help](Help-System#command-auto-help-system)
+- [Commands](Component/Commands) 
+- [Command Sets](Component/Command-Sets)
+- [Command Auto-help](Component/Help-System#command-auto-help-system)
 
 See also:
-- [Default Command Help](Default-Command-Help)
-- [Adding Command Tutorial](Adding-Command-Tutorial)
+- [Default Command Help](Component/Default-Command-Help)
+- [Adding Command Tutorial](Howto/StartingTutorial/Adding-Command-Tutorial)

docs/source/Concept/Custom-Protocols.md

@@ -5,9 +5,9 @@
 their own custom client protocol.*
 
 
-A [PortalSession](Sessions#Portal-and-Server-Sessions) is the basic data object representing an
+A [PortalSession](Component/Sessions#Portal-and-Server-Sessions) is the basic data object representing an
 external
-connection to the Evennia [Portal](Portal-And-Server) -- usually a human player running a mud client
+connection to the Evennia [Portal](Component/Portal-And-Server) -- usually a human player running a mud client
 of some kind.  The way they connect (the language the player's client and Evennia use to talk to
 each other) is called the connection *Protocol*. The most common such protocol for MUD:s is the
 *Telnet* protocol. All Portal Sessions are stored and managed by the Portal's *sessionhandler*.
@@ -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](Concept/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).
@@ -219,11 +219,11 @@ in our case means sending "foo" across the network.
 ### Receiving data 
 
 Just because the protocol is there, does not mean Evennia knows what to do with it. An
-[Inputfunc](Inputfuncs) must exist to receive it. In the case of the `text` input exemplified above,
+[Inputfunc](Component/Inputfuncs) must exist to receive it. In the case of the `text` input exemplified above,
 Evennia alredy handles this input - it will parse it as a Command name followed by its inputs. So
 handle that you need to simply add a cmdset with commands on your receiving Session (and/or the
 Object/Character it is puppeting). If not you may need to add your own Inputfunc (see the
-[Inputfunc](Inputfuncs) page for how to do this.
+[Inputfunc](Component/Inputfuncs) page for how to do this.
 
 These might not be as clear-cut in all protocols, but the principle is there. These four basic
 components - however they are accessed - links to the *Portal Session*, which is the actual common

docs/source/Concept/Guest-Logins.md

@@ -10,16 +10,16 @@ Guest accounts are turned off by default. To activate, add this to your `game/se
     GUEST_ENABLED = True
 
 Henceforth users can use `connect guest` (in the default command set) to login with a guest account.
-You may need to change your [Connection Screen](Connection-Screen) to inform them of this
+You may need to change your [Connection Screen](Component/Connection-Screen) to inform them of this
 possibility. Guest accounts work differently from normal accounts - they are automatically *deleted*
 whenever the user logs off or the server resets (but not during a reload). They are literally re-
 usable throw-away accounts.
 
 You can add a few more variables to your `settings.py` file to customize your guests:
 
-- `BASE_GUEST_TYPECLASS` - the python-path to the default [typeclass](Typeclasses) for guests.
+- `BASE_GUEST_TYPECLASS` - the python-path to the default [typeclass](Component/Typeclasses) for guests.
 Defaults to `"typeclasses.accounts.Guest"`.
-- `PERMISSION_GUEST_DEFAULT` - [permission level](Locks) for guest accounts. Defaults to `"Guests"`,
+- `PERMISSION_GUEST_DEFAULT` - [permission level](Component/Locks) for guest accounts. Defaults to `"Guests"`,
 which is the lowest permission level in the hierarchy.
 - `GUEST_START_LOCATION` - the `#dbref` to the starting location newly logged-in guests should
 appear at. Defaults to `"#2` (Limbo).

docs/source/Concept/Internationalization.md

@@ -43,7 +43,7 @@ Alternatively you might have the language but find the translation bad ... You a
 improve the situation!
 
 To start a new translation you need to first have cloned the Evennia repositry with GIT and
-activated a python virtualenv as described on the [Getting Started](Getting-Started) page. You now
+activated a python virtualenv as described on the [Getting Started](Setup/Getting-Started) page. You now
 need to `cd` to the `evennia/` directory. This is *not* your created game folder but the main
 Evennia library folder. If you see a folder `locale/` then you are in the right place. From here you
 run:

docs/source/Concept/Messagepath.md

@@ -25,7 +25,7 @@ The client sends data to Evennia in two ways.
  - When first connecting, the client can send data to the server about its
  capabilities. This is things like "I support xterm256 but not unicode" and is
  mainly used when a Telnet client connects. This is called a "handshake" and
- will generally set some flags on the [Portal Session](Portal-And-Server) that
+ will generally set some flags on the [Portal Session](Component/Portal-And-Server) that
  are later synced to the Server Session. Since this is not something the player
  controls, we'll not explore this further here.
  - The client can send an *inputcommand* to the server. Traditionally this only
@@ -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](Concept/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.
@@ -73,7 +73,7 @@ it belongs. This is then sent over the AMP connection.
 ### ServerSessionHandler (ingoing)
 
 On the Server side, the AMP unpickles the data and associates the session id with the server-side
-[Session](Sessions). Data and Session are passed to the server-side `SessionHandler.data_in`. This
+[Session](Component/Sessions). Data and Session are passed to the server-side `SessionHandler.data_in`. This
 in turn calls `ServerSession.data_in()`
 
 ### ServerSession (ingoing)
@@ -101,7 +101,7 @@ not found, an error will be raised.
 
 ### Inputfunc
 
-The [Inputfunc](Inputfuncs) must be on the form `func(session, *args, **kwargs)`. An exception is
+The [Inputfunc](Component/Inputfuncs) must be on the form `func(session, *args, **kwargs)`. An exception is
 the `default` inputfunc which has form `default(session, cmdname, *args, **kwargs)`, where `cmdname`
 is the un-matched inputcommand string.
 
@@ -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](Concept/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/New-Models.md

@@ -7,7 +7,7 @@ sufficient for most use cases. But if you aim to build a large stand-alone syste
 your storage requirements into those may be more complex than you bargain for. Examples may be to
 store guild data for guild members to be able to change, tracking the flow of money across a game-
 wide economic system or implement other custom game systems that requires the storage of custom data
-in a quickly accessible way. Whereas [Tags](Tags) or [Scripts](Scripts) can handle many situations,
+in a quickly accessible way. Whereas [Tags](Component/Tags) or [Scripts](Component/Scripts) can handle many situations,
 sometimes things may be easier to handle by adding your own database model.
 
 ## Overview of database tables
@@ -81,7 +81,7 @@ you put `myapp` and don't forget the comma at the end of the tuple):
         evennia migrate
 
 This will add your new database table to the database. If you have put your game under version
-control (if not, [you should](Version-Control)), don't forget to `git add myapp/*` to add all items
+control (if not, [you should](Coding/Version-Control)), don't forget to `git add myapp/*` to add all items
 to version control.
 
 ## Defining your models
@@ -113,7 +113,7 @@ We create four fields: two character fields of limited length and one text field
 maximum length. Finally we create a field containing the current time of us creating this object.
 
 > The `db_date_created` field, with exactly this name, is *required* if you want to be able to store
-instances of your custom model in an Evennia [Attribute](Attributes). It will automatically be set
+instances of your custom model in an Evennia [Attribute](Component/Attributes). It will automatically be set
 upon creation and can after that not be changed. Having this field will allow you to do e.g.
 `obj.db.myinstance = mydatastore`. If you know you'll never store your model instances in Attributes
 the `db_date_created` field is optional.

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](Concept/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:
 
@@ -16,9 +16,9 @@ has a standardized internal form: a tuple with a string, a tuple and a dict:
 
 This is often referred to as an *inputcommand* or *outputcommand*, depending on the direction it's
 traveling. The end point for an inputcommand, (the 'Evennia-end' of the message path) is a matching
-[Inputfunc](Inputfuncs). This function is called as `cmdname(session, *args, **kwargs)` where
+[Inputfunc](Component/Inputfuncs). This function is called as `cmdname(session, *args, **kwargs)` where
 `session` is the Session-source of the command. Inputfuncs can easily be added by the developer to
-support/map client commands to actions inside Evennia (see the [inputfunc](Inputfuncs) page for more
+support/map client commands to actions inside Evennia (see the [inputfunc](Component/Inputfuncs) page for more
 details).
 
 When a message is outgoing (at the 'Client-end' of the message path) the outputcommand is handled by
@@ -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](Concept/Custom-Protocols).
 
 ## Sending and receiving an OOB message
 
@@ -59,7 +59,7 @@ drop any other types of outputfuncs.
 you turn off telnet completely and only rely on the webclient, you should never rely on non-`text`
 OOB messages always reaching all targets.
 
-[Inputfuncs](Inputfuncs) lists the default inputfuncs available to handle incoming OOB messages. To
+[Inputfuncs](Component/Inputfuncs) lists the default inputfuncs available to handle incoming OOB messages. To
 accept more you need to add more inputfuncs (see that page for more info).
 
 ## Supported OOB protocols

docs/source/Concept/Soft-Code.md

@@ -90,5 +90,5 @@ Adding advanced and flexible building commands to your game is easy and will pro
 satisfy most creative builders. However, if you really, *really* want to offer online coding, there
 is of course nothing stopping you from adding that to Evennia, no matter our recommendations. You
 could even re-implement MUX' softcode in Python should you be very ambitious. The
-[in-game-python](Dialogues-in-events) is an optional
+[in-game-python](Contrib/Dialogues-in-events) is an optional
 pseudo-softcode plugin aimed at developers wanting to script their game from inside it.

docs/source/Concept/TextTags.md

@@ -4,7 +4,7 @@
 This documentation details the various text tags supported by Evennia, namely *colours*, *command
 links* and *inline functions*.
 
-There is also an [Understanding Color Tags](Understanding-Color-Tags) tutorial which expands on the
+There is also an [Understanding Color Tags](Howto/Understanding-Color-Tags) tutorial which expands on the
 use of ANSI color tags and the pitfalls of mixing ANSI and Xterms256 color tags in the same context.
 
 ## Coloured text
@@ -23,7 +23,7 @@ equipment by people who are blind or have otherwise diminished eyesight.
 
 So a good rule of thumb is to use colour to enhance your game but don't *rely* on it to display
 critical information. If you are coding the game, you can add functionality to let users disable
-colours as they please, as described [here](Manually-Configuring-Color).
+colours as they please, as described [here](Howto/Manually-Configuring-Color).
 
 To see which colours your client support, use the default `@color` command. This will list all
 available colours for ANSI and Xterm256 along with the codes you use for them. You can find a list
@@ -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](Concept/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](Concept/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.
 
@@ -269,7 +269,7 @@ errors if desired).
 Note that whereas the function should accept `**kwargs`, keyword inputs are *not* usable in the call
 to the inlinefunction. The `kwargs` part is instead intended for Evennia to be able to supply extra
 information. Currently Evennia sends a single keyword to every inline function and that is
-`session`, which holds the [serversession](Sessions) this text is targeted at. Through the session
+`session`, which holds the [serversession](Component/Sessions) this text is targeted at. Through the session
 object, a lot of dynamic possibilities are opened up for your inline functions.
 
 The `settings.INLINEFUNC_MODULES` configuration option is a list that decides which modules should

docs/source/Concept/Web-Features.md

@@ -42,7 +42,7 @@ Example: To override or modify `evennia/web/website/template/website/index.html`
 add/modify `mygame/web/template_overrides/website/index.html`.
 
 The detailed description on how to customize the website is best described in tutorial form. See the
-[Web Tutorial](Web-Tutorial) for more information.
+[Web Tutorial](Howto/StartingTutorial/Web-Tutorial) for more information.
 
 ### Overloading Django views
 
@@ -103,7 +103,7 @@ you will also log all requests in `mygame/server/logs/http_requests.log`.
 
 Evennia comes with a MUD client accessible from a normal web browser. During
 development you can try it at `http://localhost:4001/webclient`. 
-[See the Webclient page](Webclient) for more details.
+[See the Webclient page](Component/Webclient) for more details.
 
 
 ## The Django 'Admin' Page

docs/source/Concept/Zones.md

@@ -23,7 +23,7 @@ Many MUD codebases hardcode zones as part of the engine and database.  Evennia d
 distinction due to the fact that rooms themselves are meant to be customized to any level anyway.
 Below is a suggestion for how to implement zones in Evennia.
 
-All objects in Evennia can hold any number of [Tags](Tags). Tags are short labels that you attach to
+All objects in Evennia can hold any number of [Tags](Component/Tags). Tags are short labels that you attach to
 objects. They make it very easy to retrieve groups of objects. An object can have any number of
 different tags. So let's attach the relevant tag to our forest:
 
@@ -47,7 +47,7 @@ Henceforth you can then easily retrieve only objects with a given tag:
 
 The tagging or aliasing systems above don't instill any sort of functional difference between a
 magical forest room and a normal one - they are just arbitrary ways to mark objects for quick
-retrieval later. Any functional differences must be expressed using [Typeclasses](Typeclasses).
+retrieval later. Any functional differences must be expressed using [Typeclasses](Component/Typeclasses).
 
 Of course, an alternative way to implement zones themselves is to have all rooms/objects in a zone
 inherit from a given typeclass parent - and then limit your searches to objects inheriting from that