rel links actually fixed

docs/pages/2_CLI.md

@@ -39,7 +39,7 @@ Options:
 
 ## The `init` command
 
-As explained in the previous page, the `init` command aims to help the author create a stub for their iffinity project. It covers the required fields of the [configuration file](/config/) (as well as a bit more), and optionally creates an example game as a template. It is heavily inspired by the behavior of `npm init`. Note that it is preferable to run `ifc init` in a newly created, empty directory.
+As explained in the previous page, the `init` command aims to help the author create a stub for their iffinity project. It covers the required fields of the [configuration file]({{ site.baseurl }}/config/) (as well as a bit more), and optionally creates an example game as a template. It is heavily inspired by the behavior of `npm init`. Note that it is preferable to run `ifc init` in a newly created, empty directory.
 
 ## The `compile` command
 

docs/pages/3_Story.md

@@ -31,14 +31,14 @@ A snippet is nothing more than an HTML tag with the following structure:
 
 An exhaustive list of all possible snippet attributes follows:
  - `name`: The name of the snippet. Must be unique throughout the story. This attribute is **required** for every snippet.
- - `tags`: A list of space-separated tags for the snippet. See the [tags](/tags/) page for more information. This attribute is not required.
+ - `tags`: A list of space-separated tags for the snippet. See the [tags]({{ site.baseurl }}/tags/) page for more information. This attribute is not required.
  - `scripts`: A list of **semicolon-separated** JavaScript files that will run every time the snippet is shown. The scripts will run **in the order the are listed**, and also **inside the same EJS scope**. This attribute is not required.
  - `styles`: A list of **semicolon-separated** CSS files to be applied on this snippet. The styles will be applied **in the order the are listed**. This attribute is not required.
  - `start`: This attribute indicates that the snippet is **the entry point** of the story (i.e., the first "page" the player will see). In every story, **exactly one snippet must have this attribute**.
 
-For more information on the `scripts` and `styles` attribute, see the [relevant wiki page](/scripts-styles/).
+For more information on the `scripts` and `styles` attribute, see the [relevant wiki page]({{ site.baseurl }}/scripts-styles/).
 
-The content of the snippet is plain-old HTML, where the author can also inject JavaScript code via the [EJS template engine](/ejs/).
+The content of the snippet is plain-old HTML, where the author can also inject JavaScript code via the [EJS template engine]({{ site.baseurl }}/ejs/).
 
 ### Snippet links
 
@@ -72,7 +72,7 @@ The iffinity compiler replaces all `[[<custom text>||<id and classes>]]` (note t
 Do you wish to proceed to the next room [[with your sword||#sword.proceed]] or [[leave it behind||#no-sword.proceed]]?
 ```
 
-These links will be replaced by `<a>` tags by the compiler (which also happens with the 2 previous types). However, the first will have `id="sword"`, the second one will have `id="no-sword"`, while both of them will have `class="proceed"`. By organizing your links this way, you could then write some simple [code in the snippet](/ejs/) to introduce a state change:
+These links will be replaced by `<a>` tags by the compiler (which also happens with the 2 previous types). However, the first will have `id="sword"`, the second one will have `id="no-sword"`, while both of them will have `class="proceed"`. By organizing your links this way, you could then write some simple [code in the snippet]({{ site.baseurl }}/ejs/) to introduce a state change:
 
 ```js
 <%
@@ -85,7 +85,7 @@ These links will be replaced by `<a>` tags by the compiler (which also happens w
 %>
 ```
 
-This way, the player will navigate to the "Next Room" snippet regardless, but the `s.SWORD` variable will be `true` or `false`, depending on what they clicked. This is a powerful mechanism to simplify the structure of your snippets and introduce state changes without messing with your snippet organization. Note, however, that these are **dead links**. This means that it is **your responsibility** to change the snippet (if so desired), via the `showSnippet()` method of the `story` variable. See the [author API page](/author-api/) for more information.
+This way, the player will navigate to the "Next Room" snippet regardless, but the `s.SWORD` variable will be `true` or `false`, depending on what they clicked. This is a powerful mechanism to simplify the structure of your snippets and introduce state changes without messing with your snippet organization. Note, however, that these are **dead links**. This means that it is **your responsibility** to change the snippet (if so desired), via the `showSnippet()` method of the `story` variable. See the [author API page]({{ site.baseurl }}/author-api/) for more information.
 
 ### HTML shorthands
 

docs/pages/4_Config.md

@@ -52,7 +52,7 @@ Every field that has an `?` after its name means that it is optional. All other
 
 Every field that has a type of `StringOrStringArray` can either be a single file (e.g. `scripts.story = "story.js"`) or a list of files (e.g. `scripts.story = ["story1.js", "story2.js"]`. The following apply to all fields of the `StringOrStringArray` type:
 1. They are applied **in order**. This means that a JS script will run after all the previous in the same list have run, and that a CSS stylesheet will override all properties defined in previous stylesheets in the same list (that it also defines).
-2. For JS scripts: They run **in the same EJS scope** (except for the library scripts, see below), so subsequent scripts in a list have access to variables/functions etc defined in the previous scripts of the same list. This facilitates the author to further break down their logic in smaller parts if they see fit, without having to always use the story state `s` for [intra-level](/scripts-styles/) script communication.
+2. For JS scripts: They run **in the same EJS scope** (except for the library scripts, see below), so subsequent scripts in a list have access to variables/functions etc defined in the previous scripts of the same list. This facilitates the author to further break down their logic in smaller parts if they see fit, without having to always use the story state `s` for [intra-level]({{ site.baseurl }}/scripts-styles/) script communication.
 
 A breakdown of all configuration fields follows:
 
@@ -65,16 +65,16 @@ A breakdown of all configuration fields follows:
    - `repository`: The repository of the story. This field is optional.
      - `type`: The type of the repository (e.g. `git`)
      - `url`: The URL of the repository.
- - `libraries`: This field contains the paths to the libraries that the story uses. These are scripts that will be added to the `head` tag of the output HTML. Note that these scripts **have no access to the [author API](/author-api/)**.
+ - `libraries`: This field contains the paths to the libraries that the story uses. These are scripts that will be added to the `head` tag of the output HTML. Note that these scripts **have no access to the [author API]({{ site.baseurl }}/author-api/)**.
    - `scripts`: The paths to the JavaScript libraries.
    - `styles`: The paths to the CSS libraries.
  - `scripts`: This field contains the paths to the scripts that the story uses.
-   - `story`: The path(s) to the [story script(s)](/scripts-styles/#the-story-scriptsstylesheets).
-   - `global`: The path(s) to the [global script(s)](/scripts-styles/#the-global-scripts).
-   - `tags`: A list of tag rules and the associated paths to the scripts that they correspond to. See the page about [the tag system](/tags/) for more information.
+   - `story`: The path(s) to the [story script(s)]({{ site.baseurl }}/scripts-styles/#the-story-scriptsstylesheets).
+   - `global`: The path(s) to the [global script(s)]({{ site.baseurl }}/scripts-styles/#the-global-scripts).
+   - `tags`: A list of tag rules and the associated paths to the scripts that they correspond to. See the page about [the tag system]({{ site.baseurl }}/tags/) for more information.
  - `styles`: This field contains the paths to the stylesheets that the story uses.
-   - `story`: The path(s) to the [story stylesheet(s)](/scripts-styles/#the-story-scriptsstylesheets).
-   - `tags`: A list of tag rules and the associated paths to the stylesheets that they correspond to. See the page about [the tag system](/tags/) for more information.
+   - `story`: The path(s) to the [story stylesheet(s)]({{ site.baseurl }}/scripts-styles/#the-story-scriptsstylesheets).
+   - `tags`: A list of tag rules and the associated paths to the stylesheets that they correspond to. See the page about [the tag system]({{ site.baseurl }}/tags/) for more information.
  - `validation`: See the following section.
 
 ## Source HTML validation

docs/pages/5_EJS.md

@@ -52,9 +52,9 @@ You can interpolate JavaScript values using the `<%- ... %>` EJS tags (same as b
 
 Every code you write inside EJS tags has access to the following variables created by iffinity:
 
- - `story`: The [story object](/author-api/#the-story-object)
- - `snippet`: The current [snippet object](/author-api/#the-snippet-object)
+ - `story`: The [story object]({{ site.baseurl }}/author-api/#the-story-object)
+ - `snippet`: The current [snippet object]({{ site.baseurl }}/author-api/#the-snippet-object)
  - `s`: The story state object (shorthand for the `story.state` field)
  - `f`: The story functions object (shorthand for the `story.funcs` field)
 
-Note that the only way to have variables/computations etc escape a certain EJS segment and live on is to store them in the story state `s`. For functions, the pseudo-variable `f` is recommended (shorthand for the `story.funcs` field). The only difference between `s` and `f` is that `s` is serialized by the `save()` method of the `Story` object, so functions won't survive this. For more information, see the page on [the author API](/author-api/).
+Note that the only way to have variables/computations etc escape a certain EJS segment and live on is to store them in the story state `s`. For functions, the pseudo-variable `f` is recommended (shorthand for the `story.funcs` field). The only difference between `s` and `f` is that `s` is serialized by the `save()` method of the `Story` object, so functions won't survive this. For more information, see the page on [the author API]({{ site.baseurl }}/author-api/).

docs/pages/6_API.md

@@ -5,12 +5,12 @@ permalink: /author-api/
 nav_order: 6
 ---
 
-iffinity exposes an API to the author's JavaScript code, both inside EJS segments, as well as to the [story, global and snippet scripts](/scripts-styles/).
+iffinity exposes an API to the author's JavaScript code, both inside EJS segments, as well as to the [story, global and snippet scripts]({{ site.baseurl }}/scripts-styles/).
 
 As explained previously, any code you write inside EJS tags has access to the following variables created by iffinity:
 
- - `story`: The [story object](/author-api/#the-story-object)
- - `snippet`: The current [snippet object](/author-api/#the-snippet-object)
+ - `story`: The [story object]({{ site.baseurl }}/author-api/#the-story-object)
+ - `snippet`: The current [snippet object]({{ site.baseurl }}/author-api/#the-snippet-object)
  - `s`: The story state object (a pseudo-variable; shorthand for the `story.state` field)
  - `f`: The story functions object (a pseudo-variable; shorthand for the `story.funcs` field)
 

docs/pages/7_Scripts_Styles.md

@@ -7,11 +7,11 @@ nav_order: 7
 
 On of the greatest strengths of the iffinity engine is that it allows the author to organize their scripts and styles however they desire, using the configuration file.
 
-iffinity features a hierarchical system to organize the code of a project. There are 4 levels/types of scripts/styles. With the exception of the libraries, all other levels have access to the [author API](/author-api/), as well as to jQuery and EJS. Higher to lower, these levels are the following:
+iffinity features a hierarchical system to organize the code of a project. There are 4 levels/types of scripts/styles. With the exception of the libraries, all other levels have access to the [author API]({{ site.baseurl }}/author-api/), as well as to jQuery and EJS. Higher to lower, these levels are the following:
 
 ## The library scripts/stylesheets
 
-These files are defined in the `libraries.{scripts,styles}` fields of the configuration file. They are JS/CSS files that are appended to the `<head>` of the output HTML. They have no access to the [author API](/author-api/). These can be external libraries (like jQuery) or custom user libraries.
+These files are defined in the `libraries.{scripts,styles}` fields of the configuration file. They are JS/CSS files that are appended to the `<head>` of the output HTML. They have no access to the [author API]({{ site.baseurl }}/author-api/). These can be external libraries (like jQuery) or custom user libraries.
 
 ## The story scripts/stylesheets
 
@@ -23,7 +23,7 @@ These are JS script files that are defined in the `scripts.global` field of the
 
 ## Tag-specific scripts/stylesheets
 
-These files are defined in the `{scripts,styles}.tags` fields of the configuration file. They are JS/CSS files that are associated with a specific tag rule. Each entry of the `{scripts,styles}.tags` arrays is an object with 2 fields, a tag rule (`{scripts,styles}.tags[i].rule`) and some associated scripts (`{scripts,styles}.tags[i].files`). Only the snippets whose tags satisfy the tag rule will have those files. For more information, see the page on iffinity's [tag system](/tags/). Not that the tag-specific scripts **run before any snippet-specific scripts** and that the tag-specific stylesheets **override any styles of higher levels**.
+These files are defined in the `{scripts,styles}.tags` fields of the configuration file. They are JS/CSS files that are associated with a specific tag rule. Each entry of the `{scripts,styles}.tags` arrays is an object with 2 fields, a tag rule (`{scripts,styles}.tags[i].rule`) and some associated scripts (`{scripts,styles}.tags[i].files`). Only the snippets whose tags satisfy the tag rule will have those files. For more information, see the page on iffinity's [tag system]({{ site.baseurl }}/tags/). Not that the tag-specific scripts **run before any snippet-specific scripts** and that the tag-specific stylesheets **override any styles of higher levels**.
 
 ## Snippet-specific scripts/stylesheets
 
@@ -45,4 +45,4 @@ Maybe you have a snippet that is a highly stylized, logic-heavy minigame? Snippe
 
 ## Injected scripts
 
-These are code segments injected in the snippet via the EJS template system. For more information, see the [relevant page](/ejs/).
+These are code segments injected in the snippet via the EJS template system. For more information, see the [relevant page]({{ site.baseurl }}/ejs/).