Correct tutorials on evennia startapp use, which seems to have changed with time. Resolve #3287

docs/source/Concepts/Models.md

@@ -44,10 +44,11 @@ Here is how you add your own database table/models:
 
 1. In Django lingo, we will create a new "application" - a subsystem under the main Evennia program. For this example we'll call it "myapp". Run the following (you need to have a working Evennia running before you do this, so make sure you have run the steps in [Setup Quickstart](Getting- Started) first):
 
-        cd mygame/world
         evennia startapp myapp
+        mv myapp world  (linux)
+        move myapp world   (windows)
 
-1. A new folder `myapp` is created. "myapp" will also be the name (the "app label") from now on. We chose to put it in the `world/` subfolder here, but you could put it in the root of your `mygame` if that makes more sense. 1. The `myapp` folder contains a few empty default files. What we are interested in for now is `models.py`. In `models.py` you define your model(s). Each model will be a table in the database. See the next section and don't continue until you have added the models you want.
+1. A new folder `myapp` is created. "myapp" will also be the name (the "app label") from now on. We move it into the `world/` subfolder here, but you could keep it in the root of your `mygame` if that makes more sense. 1. The `myapp` folder contains a few empty default files. What we are interested in for now is `models.py`. In `models.py` you define your model(s). Each model will be a table in the database. See the next section and don't continue until you have added the models you want.
 1. You now need to tell Evennia that the models of your app should be a part of your database scheme. Add this line to your `mygame/server/conf/settings.py`file (make sure to use the path where you put `myapp` and don't forget the comma at the end of the tuple):
 
     ```
@@ -97,15 +98,15 @@ point for your models.
 
 ## Referencing existing models and typeclasses
 
-You may want to use `ForeignKey` or `ManyToManyField` to relate your new model to existing ones. 
+You may want to use `ForeignKey` or `ManyToManyField` to relate your new model to existing ones.
 
 To do this we need to specify the app-path for the root object type we want to store as a string (we must use a string rather than the class directly or you'll run into problems with models not having been initialized yet).
 
 - `"objects.ObjectDB"` for all [Objects](../Components/Objects.md) (like exits, rooms, characters etc)
-- `"accounts.AccountDB"` for [Accounts](../Components/Accounts.md). 
+- `"accounts.AccountDB"` for [Accounts](../Components/Accounts.md).
 - `"scripts.ScriptDB"` for [Scripts](../Components/Scripts.md).
 - `"comms.ChannelDB"` for [Channels](../Components/Channels.md).
-- `"comms.Msg"` for [Msg](../Components/Msg.md) objects. 
+- `"comms.Msg"` for [Msg](../Components/Msg.md) objects.
 - `"help.HelpEntry"` for [Help Entries](../Components/Help-System.md).
 
 Here's an example:
@@ -113,20 +114,20 @@ Here's an example:
 ```python
 from django.db import models
 
-class MySpecial(models.Model): 
+class MySpecial(models.Model):
     db_character = models.ForeignKey("objects.ObjectDB")
     db_items = models.ManyToManyField("objects.ObjectDB")
     db_account = modeles.ForeignKey("accounts.AccountDB")
 ```
 
-It may seem counter-intuitive, but this will work correctly: 
+It may seem counter-intuitive, but this will work correctly:
 
     myspecial.db_character = my_character  # a Character instance
     my_character = myspecial.db_character  # still a Character
 
-This works because when the `.db_character` field is loaded into Python, the entity itself knows that it's supposed to be a `Character` and loads itself to that form. 
+This works because when the `.db_character` field is loaded into Python, the entity itself knows that it's supposed to be a `Character` and loads itself to that form.
 
-The drawback of this is that the database won't _enforce_ the type of object you store in the relation. This is the price we pay for many of the other advantages of the Typeclass system. 
+The drawback of this is that the database won't _enforce_ the type of object you store in the relation. This is the price we pay for many of the other advantages of the Typeclass system.
 
 While the  `db_character` field fail if you try to store an `Account`, it will gladly accept any instance of a typeclass that inherits from `ObjectDB`, such as rooms, exits or other non-character Objects. It's up to you to validate that what you store is what you expect it to be.
 
@@ -225,4 +226,4 @@ To search your new custom database table you need to use its database *manager*
         self.caller.msg(match.db_text)
 ```
 
-See the [Beginner Tutorial lesson on Django querying](../Howtos/Beginner-Tutorial/Part1/Beginner-Tutorial-Django-queries.md) for a lot more information about querying the database.
+See the [Beginner Tutorial lesson on Django querying](../Howtos/Beginner-Tutorial/Part1/Beginner-Tutorial-Django-queries.md) for a lot more information about querying the database.

docs/source/Howtos/Web-Character-View-Tutorial.md

@@ -5,12 +5,18 @@
 
 In this tutorial we will create a web page that displays the stats of a game character. For this, and all other pages we want to make specific to our game, we'll need to create our own Django "app". We'll call our app `character`, since it will be dealing with character information. From your game dir, run
 
-    cd web 
     evennia startapp character
 
-This will create a new directory named `character` inside `mygame/web/`. We put it in `web/` to keep things tidy, but you could place it wherever you like. It contains all basic files that a Django app needs. 
+This will create a new directory named `character` inside `mygame`. To keep
+things tidy, let's move it into the `web/` subdirectory.
 
-Note that we will not edit all files in this new directory, many of the generated files are outside the scope of this tutorial.  
+    mv character web  (linux/mac)
+    move character web  (windows)
+
+We put it in `web/` to keep things tidy, but you could place it wherever you
+like. It contains all basic files that a Django app needs.
+
+Note that we will not edit all files in this new directory, many of the generated files are outside the scope of this tutorial.
 
 In order for Django to find our new web app, we'll need to add it to the `INSTALLED_APPS` setting. Evennia's default installed apps are already set, so in `server/conf/settings.py`, we'll just extend them:
 

docs/source/Howtos/Web-Help-System-Tutorial.md

@@ -18,12 +18,18 @@ The first step is to create our new Django *app*.  An app in Django can contain
 
 From your game directory, use the following commands:
 
-    cd web 
+    cd web
     evennia startapp help_system
 
+This creates a new folder `help_system` in your `mygame/` folder. To keep things
+tidy, let's move it to the `web/` folder:
+
+    mv help_system web  (linux)
+    move help_system web  (windows)
+
 > Note: calling the app "help" would have been more explicit, but this name is already used by Django.
 
-This will create a directory named `help_system` under `mygame/web/`. We put it there to keep all web-related things together, but you can organize however you like. Here's how the structure looks: 
+We put the new app under `web/`t o keep all web-related things together, but you can organize however you like. Here's how the structure looks:
 
     mygame/
         ...
@@ -211,7 +217,7 @@ But what if the user's not logged in?  Again, we have different solutions.  One
 The system should answer:
 
         Created new character anonymous. Use @ic anonymous to enter the game as this character.
-    
+
 So in our view, we could have something like this:
 
 ```python