Event config.

docs/gettingstarted/eventconfiguration.md

@@ -0,0 +1,45 @@
+The Anatomy of an Event Configuration
+=====================================
+
+Now that we understand what events are, let's talk about how they are processed. Each socket layer has their own Event Configuration (with the exception of Chats, which all share the same Event Configuration). CCI does the hard work of breaking down a Stream Event into an Event, understands its type, and then passes it to an Event Configuration to be processed. These Event Configurations are what I commonly refer to as a "config", and these are saved in your profile folder as JSON files.
+
+Let's take a look at an Event Configuration as it appears in the Editor. In this example, we used the default Event Configuration generated for Chat:
+
+![](./images/eventconfiguration/eventconfig.png){: class="img_center"}
+<br />
+<br />
+
+| Reminder |
+|--------|
+| The left window, the navigator, is only for navigation. You cannot manipulate any of its Objects. That has to be done on the right side, the contents window. |
+
+Similar to our screenshot of the Editor from earlier, now, the Event Configuration has been selected on the left side, by the top. The Contents window on the right now shows the fields of this Object.
+
+Very quickly, you can see the full tree of this Event Configuration on the left, and that this Event Configuration has two Configurations, and no Events on init, on the right.
+
+As Chat's Event Configuration is shared between Twitch and YouTube, one Configuration is used for Twitch, and one Configuration is used for YouTube. For the purposes of this guide, we will be focusing on Twitch's Configuration, the first one in the Navigator.
+
+Twitch chat's stream events generally fall under two categories, a `message` and an `action`. `message` type Stream Events are usually the normal messages you see in chat, and sometimes, channel rewards that contain text. Differentiating the two will be explained later. `action` type Stream Events are when a user does `/me` before sending a message into Twitch chat.
+
+CCI processes the Stream Event to determine which platform it's from, and what type it is, and then passes this to the Event Configuration, which automatically filters this and then tests it against the Config Events. Here you can see that both `message` and `action` only have one Config Event attached. 
+
+Let's have a look at the Config Event for `message`:
+
+![](./images/eventconfiguration/configevent.png){: class="img_center"}
+<br />
+<br />
+
+There's a lot to take in here, but I want you to focus on three things: `conditions`, `outcomes`, `allowsOtherEventsToTrigger`. 
+
+`conditions` are a list of "conditions" that need to be met for this Config Event to trigger. Having no conditions also causes the Config Event to trigger. When the Config Event triggers, it triggers the outcomes in `outcomes`. Both conditions and outcomes have their own special fields to modify their behaviour, but we won't go into detail here. In this instance, since there are no conditions, any chat message triggers the ToastOutcome, which causes a Toast to pop up with the user's name and message.
+
+This is where it gets a little complicated (as if it wasn't already), the first Config Event for type `message` is tested, and if it triggers, CCI considers this as a job well done, and stops there. If the Config Event doesn't trigger, eg the conditions aren't met, or it is on cooldown, the next Config Event in the list is tested. CCI works on a top to bottom principle, meaning it tries from the top and works downwards. This applies for Config Events, Conditions, Outcomes, and most other things.
+
+So, if this Config Event triggers, CCI stops there, we call this "short circuiting". The Config Events after this aren't tested at all and we stop processing. This is where `allowsOtherEventsToTrigger` comes in. Enabling this flag, aka turning it to `true`, will continue the processing even after this Config Event triggers. 
+
+"*But why?*". There are many different applications for this. You might want a Config Event to handle all incoming chat messages, before letting other Config Events process this, for example. "*But why not just do that all the time?*". That, is a waste of resources, and we all know how intensive playing MC Modded can be, so lets not do that.
+
+So, in summary, the flow:
+`Stream Event -> Event -> Event Configuration -> Configuration -> Config Event -> Conditions & Outcomes`
+
+This outlines the basics of how an Event Configuration works. There are more advanced applications for these, but these will be detailed elsewhere. Next, we will detail on how to handle an Event.

docs/gettingstarted/events.md

@@ -1,7 +1,9 @@
 Dissecting an Event
 ===================
 
-The way CCI works, is it receives Stream Events, breaks it down, and passes it along to you in a way you can understand, to be passed into events. An important attribute of this, are what we call variables.
+Events are, in its simplest form, a standard way for CCI to pass information to you in a way you can understand and process.
+
+The way CCI works, is it receives Stream Events, breaks it down, and converts it into an event, to be passed to you. An important attribute of this, are what we call variables.
 
 ## Variables
 

docs/gettingstarted/index.md

@@ -23,7 +23,8 @@ Throughout these docs there will be a couple of mentions of similarly sounding p
 | Phrase | Definition |
 |--------------|-------|
 | Stream Event | These are events that happen on stream. Subscriptions, cheers, chat messages, etc |
-| Event | These are events configured in CCI to act on different things, including Stream Events. These contain conditions, outcomes, etc. More on that later. |
+| Event | These are stream events that are processed and passed on to you to process. More on this later. |
+| Config Event | These are events configured in CCI to act on the aforementioned Events. These contain conditions, outcomes, etc. More on that later. |
 | <br/> |  |
 | Mod Config   | The mod configuration file used to configure the mod. These contain your socket keys and should never be shown to others.  |
 | Config | The configuration files CCI uses to understand what to do with your Stream Events. These collectively form Events and are saved in JSON files. |

docs/index.md

@@ -17,16 +17,10 @@ CCI works on being primarily [Object-oriented](https://en.wikipedia.org/wiki/Obj
 
 CCI connects to a variety of services using an array of methods, [Socket.IO](https://socket.io/), Websockets, or manually polling. The following services are supported:
 
-**Socket.IO**  
-* [Streamlabs](https://streamlabs.com/)  
-* [StreamElements](https://streamelements.com/)  
-<br />
-
-**Websocket**  
-* [Twitch Chat](https://www.twitch.tv/)  
-<br />
-
-**Polling**  
-* [YouTube Chat](https://www.youtube.com/)  
+| Method | Service |
+|---|---|
+| **Socket.IO**  | [Streamlabs](https://streamlabs.com/)<br/>[StreamElements](https://streamelements.com/)  |
+| **Websocket**  | [Twitch Chat](https://www.twitch.tv/)  |
+| **Polling**    | [YouTube Chat](https://www.youtube.com/)    |
 
 More layers of support may be added depending on the demand and the ease of integration. Request them on the [GitHub](https://github.com/iChun/ContentCreatorIntegration-IssuesAndDocumentation)!

mkdocs.yml

@@ -10,6 +10,7 @@ pages:
       - YouTube Chat: 'gettingstarted/socketkey/youtubechat.md'
     - The CCI Editor: 'gettingstarted/editor.md'
     - Dissecting an Event: 'gettingstarted/events.md'
+    - The Anatomy of an Event Configuration: 'gettingstarted/eventconfiguration.md'
   - Components:
     - Event Configuration & Configuration: 'components/eventconfig.md'
     - Event: 'components/event.md'
@@ -25,6 +26,7 @@ site_name: Content Creator Integration Documentation
 markdown_extensions:
   - admonition
   - smarty
+  - sane_lists
   - attr_list
   - pymdownx.superfences
   - pymdownx.highlight: