Update IMPL_DETAILS.md

docs/IMPL_DETAILS.md

@@ -1,7 +1,7 @@
-#Eluna features
+# Eluna features
 This article contains information about features and important notes regarding Eluna.
 
-##Settings
+## Settings
 Eluna has some settings in the server configuration file.
 It is important that you use the new configuration file that you get from compiling after adding Eluna. If the new configuration file is not used you will not receive any error log or output to console.
 
@@ -11,13 +11,13 @@ The configuration file includes at least the following settings:
 - configure script folder location
 - configure Eluna logging settings
 
-##Reloading
+## Reloading
 To make testing easier it is good to know that Eluna scripts can be reloaded by using the command `.reload eluna`.
 However this command should be used for development purposes __ONLY__. If you are having issues getting something working __restart__ the server.
 
 It is important to know that reloading does not trigger for example the login hook for players that are already logged in when reloading.
 
-##Script loading
+## Script loading
 Eluna loads scripts from the `lua_scripts` folder by default. You can configure the folder name and location in the server configuration file.
 Any hidden folders are not loaded. All script files must have an unique name, otherwise an error is printed and only the first file found is loaded.
 
@@ -27,13 +27,13 @@ Any file having `.ext` extension, for example `test.ext`, is loaded before norma
 Instead of the ext special feature however it is recommended to use the basic lua `require` function.
 The whole script folder structure is added automatically to the lua require path so using require is as simple as providing the file name without any extension for example `require("runfirst")` to require the file `runfirst.lua`.
 
-##Automatic conversion
+## Automatic conversion
 In C++ level code you have types like `Unit` and `Creature` and `Player`.
 When in code you have an object of type `Unit` you need to convert it to a `Creature` or a `Player` object to be able to access the methods of the subclass.
 
 In Eluna this is automatic. All objects are automatically converted to the correct type and you will always have full access to all member functions of an object.
 
-##Storing userdata
+## Storing userdata
 Storing userdata objects over time that are memory managed by C++ is a bad idea.
 For example you should never save a player to a global variable and then try access it in a timed event. The reason is that the player object in C++ is a pointer to an object that C++ can delete at any time. When time passes the player may have logged out and using the pointer after player object no longer exists can be catastrophic.
 
@@ -42,7 +42,7 @@ Instead of storing the object itself you can use store guids `player:GetGUID()`
 
 Any userdata object that is memory managed by lua is safe to store over time. These objects include but are not limited to: query results, worldpackets, uint64 and int64 numbers.
 
-##Userdata metamethods
+## Userdata metamethods
 All userdata objects in Eluna have tostring metamethod implemented.
 This allows you to print the player object for example and to use `tostring(player)`.
 
@@ -68,17 +68,17 @@ gob:CustomFunc("test2")
 
 It is recommended that in normal code these global tables and their names (variables starting with capital letters like Player, Creature, GameObject, Spell..) are avoided so they are not unintentionally edited or deleted causing other scripts possibly not to function.
 
-##Database
+## Database
 Database is a great thing, but it has it's own issues.
 
-###Querying
+### Querying
 Database queries are slow. The whole server has to wait for the script to fetch the data from disk before continuing. Compared to reading cache or RAM reading from disk is the same as going to the moon to fetch the data (no pun intended).
 
 Depending on what you need, prefer database Execute over Query when not selecting anything from the database. Database Executes are made asynchronously and they will not keep the server waiting.
 
 Move all database queries possible to the script loading, server startup or similar one time event and use cache tables to manage the data in scripts.
 
-###Types
+### Types
 __Database types should be followed strictly.__
 Mysql does math in bigint and decimal formats which is why a simple select like `SELECT 1;` actually returns a bigint.
 If you fetch a bigint or decimal using a function for a smaller type it is possible the value is read incorrectly.