consistency

docs/all-plugins/the-item-lookup-system.md

@@ -25,9 +25,9 @@ This looks completely meaningless, but it's actually really simple. A crafting r
 
 ## Keys Explained
 In each string is the key for an item. A key looks one of three ways:
-- A vanilla minecraft material: (eg `golden_apple`)
-- An item from another plugin: (eg `ecoitems:packmaster_tear`)
-- An exact item NBT tag: (eg `{id:"stone",Count:3,tag:{Name:"your name"}}`)
+- A vanilla minecraft material: (e.g. `golden_apple`)
+- An item from another plugin: (e.g. `ecoitems:packmaster_tear`)
+- An exact item NBT tag: (e.g. `{id:"stone",Count:3,tag:{Name:"your name"}}`)
 
 You may also have noticed the `?` in some of the items. This means 'try to use the first item, but if it doesn't exist, use the second item' You can chain these together, but they're actually only useful for me to provide integrations in default configs without breaking things for people who don't use all my plugins together.
 
@@ -41,7 +41,7 @@ When using exact item NBT, you can't use `?`. `||`, or other modifiers.
 Items can have modifiers applied to them in the key. For example, lets say you're configuring the GUI for EcoSkills. You want it to be a player head with a texture, but you're not sure how to do that, because it looks like you have to just specify a material. Actually, in all of my plugins, wherever it asks for a material, it's actually doing a lookup. You can specify any of the following modifiers to it:
 - **Enchantments:** You specify an enchantment by adding `<enchantment>:<level>` to the key, and you can chain these together
 - **Skull Texture:** If the material is a player head, you can specify the texture with `texture:<base64>`. A list of skulls and textures can be found [here](https://minecraft-heads.com/).
-- **Player Head:** If the material is a player head, you can specify a player using `head:<name>`. You can also use placeholders, eg: `head:%player%`
+- **Player Head:** If the material is a player head, you can specify a player using `head:<name>`. You can also use placeholders, e.g. `head:%player%`
 - **Reforge:** If you have reforges installed, you can specify the reforge by adding `reforge:<id>` to the key.
 - **Name:** You can specify the display name of an item with `name:<name>`. You can have multiple words by surrounding the name with quotes: `name:"Long Name"`
 - **Item Flags:** You can specify flags for the item to have, by dropping in any of [these values](https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/inventory/ItemFlag.html) (not case sensitive) 

docs/effects/configuring-an-effect.md

@@ -43,7 +43,7 @@ The example effect: 10% chance to spawn 10 soul particles in the centre of a dia
 
 **filters**: The list of filters to be applied on the trigger. (e.g. `blocks` filter on `mine_block` trigger, or `entities` filter on `melee_attack` trigger.)
 
-**conditions**: As well as each effect holder (eg Talisman, Reforge, Enchant) having its own conditions, you can specify
+**conditions**: As well as each effect holder (e.g. Talisman, Reforge, Enchant) having its own conditions, you can specify
 a list of effect-specific conditions that work in exactly the same way
 
 **mutators**: Mutate the data sent to the effect: you can change parameters such as the victim, the location, etc.
@@ -224,8 +224,8 @@ you only use placeholders with numeric values, as you will get weird behaviour o
 
 There are also extra placeholders passed in that you can use:
 
-`%trigger_value%`, `%triggervalue%`, `%trigger%`, `%value%`, `%tv%`, `%v%`, and `%t%`: The value passed by the trigger (
-e.g. the amount of damage dealt; see [here](https://plugins.auxilor.io/effects/all-triggers)).
+`%trigger_value%`, `%triggervalue%`, `%trigger%`, `%value%`, `%tv%`, `%v%`, and `%t%`: The value passed by the trigger 
+(e.g. the amount of damage dealt; see [here](https://plugins.auxilor.io/effects/all-triggers)).
 
 `%player%`: The player's name
 
@@ -259,115 +259,6 @@ If the victim is a player, you can supply any placeholder prefixed with `victim_
 
 `%location_world%`, `%loc_w%`, and `%world%`: The world name of the location
 
-
-
-
-## Effect Chains
-
-Effect chains are groups of effects that can be executed together. This is very useful if you want to create a
-chance-based effect with several components: chance is calculated independently on each trigger, so without chains,
-particles and messages could send when the effects don't activate, and vice-versa.
-
-Effect chains are also useful to re-use more complex logic, via custom arguments that you can specify.
-These work like regular placeholders, and you reference them in your chains with `%<id>%`, for example `%size%` if you
-had a size argument.
-
-You can create a chain in config, under the 'chains' section - which should look like this:
-
-```yaml
-chains:
-    - id: <chain id>
-      effects:
-          - <effect 1>
-          - <effect 2>
-          - <effect 3>
-```
-
-**Effects in chains do not need to specify triggers as they are triggered by the run_chain effect**
-
-You can add or remove as many chains as you want. Then, if you want to call a chain, use the `run_chain` effect, like
-this:
-
-```yaml
-id: run_chain
-args:
-    chance: 50 * (%player_health% / 20) # Example to demonstrate placeholders in config
-    cooldown: 2
-    chain: <chain id>
-triggers:
-    - melee_attack
-    - bow_attack
-    - trident_attack
-filters:
-    entities:
-        - zombie
-        - creeper charged
-        - skeleton
-```
-
-Custom arguments can be specified like this:
-
-```yaml
-id: run_chain
-args:
-    chain: <chain id>
-    chain_args:
-        strength: %player_y% * 100 # You can put anything you want, doesn't only have to be numbers - you can use strings too!
-        ... add whichever arguments you use in your chain
-```
-
-## Inline Chains
-
-If you don't want to re-use chains, or if you prefer having them specified directly under the effect, you can specify
-effects like this instead:
-
-```yaml
-effects:
-    - <effect 1>
-    - <effect 2>
-    - <effect 3>
-triggers:
-    - mine_block
-args:
-    every: 3
-```
-
-Inline chains also support custom arguments, just like regular chains.
-
-Effects in chains run isolated, so applying a mutator to one effect in the chain will apply it only to that effect -
-however, you can specify a mutator to the parent effect which will be applied to all
-effects in the chain. The same works for delays, e.g. if an effect in a chain has a delay of 2, it won't hold up other
-effects down the chain.
-
-Effect chains also support several run types:
-
-- **normal**: All effects in the chain will be ran, one after another
-- **cycle**: Only one effect will be ran, and it cycles through each effect each time the chain is ran
-- **random**: Only one effect will be ran, chosen at random on each execution
-
-To specify the run type, add the `run-type` argument into config:
-
-```yml
-effects:
-    - triggers:
-          - alt_click
-      effects:
-          - <effect 1>
-          - <effect 2>
-          - <effect 3>
-      args:
-          run-type: random
-          chance: 30
-... filters, mutators, etc
-```
-
-This is an alternative way of configuring your effects; you don't specify a top-level effect ID, instead you specify a
-list of effects to be called. This can be thought of as being more trigger-centric; multiple triggers to multiple
-effects straight away, no worrying about the underlying chain.
-
-These work exactly like inline chains (they are inline chains), so everything is still supported; run-type, custom
-arguments, etc.
-
 ## Load Weight
 
 All configs are loaded alphabetically by default. However, if you have a config that depends on