Added skills documentation, mod syntax documentation

docs/addingMods.md

@@ -69,10 +69,12 @@ Our example is fairly simple, as some mod forms will slightly alter mod names an
 
   If you're missing something, you can also see what is unable to be parsed: ![Unparsed Mods](https://i.imgur.com/RiIH0u4.png)
 
+- All mods get converted to lower case before getting parsed, so when adding a new one make sure it's also lowercase.
+
 - When adding a mod, see if you can add a new flag, or mod tag, before adding it to `specialModList`.  It makes the code much cleaner overall.
 
 - When a mod changes, keep in mind backwards compatibility.  Since mods in most builds contain just the raw mod text, and are not tied to the underlying mod from GGG's data, we need to keep old mod wordings intact so those keep working on older builds.  This is especially true for mods that have gone legacy (i.e. can still exist in game)
 
 ### Miscellaneous
 
-There are a few flags you might see attached to mods that are defined in [this section](https://github.com/PathOfBuildingCommunity/PathOfBuilding/blob/master/src/Modules/ModParser.lua#L3662).  These have to do with enemy or minion modifiers, or mods that don't directly affect the player.
+There are a few flags you might see attached to mods that are defined in [this section](https://github.com/PathOfBuildingCommunity/PathOfBuilding/blob/master/src/Modules/ModParser.lua#L3662).  These have to do with enemy or minion modifiers, or mods that don't directly affect the player.

docs/addingSkills.md

@@ -0,0 +1,46 @@
+Skills in Path of Building are generated from what is called a template file.  These template files are used when exporting data from the ggpk and can be found [here](../src/Export/Skills).  While this tutorial will focus on the [combined data files](../src/Data/Skills) know that any changes will be overwritten unless added to the template files.  The script that combines these template files with the game data can be found [here](../src/Export/Scripts/skills.lua)
+
+## Template files
+
+A template file for a new skill can consist of the following directives, which tell the export script what to put in the final file.
+
+### #skill grantedEffectId [displayName]
+This directive initializes all the data for the skill and emits the skill header.  `grantedEffectId` matches up with the name defined in the ggpk, in the `GrantedEffects` table.  `displayName` is optional, but can override the display name from the game data if needed
+
+### #flags
+Sets the base flags for an active skill, like projectile, attack, or minion, for example
+
+### #mods
+This directive does nothing but ensure the mods that come with the skill are included after exporting.  This will almost always be included
+
+### #baseMod
+This directive is used when there are mods associated with the skill that don't come in the statMap (see the statMap section below)
+
+### #noGem
+This directive is used when a new skill doesn't have a gem associated with it.  Skills from uniques are some that fall in this category
+
+## Combined data
+
+The most important tables constructed from the game data are the `stats` table, and the `levels` table.  Taking a look at just one row in `levels`, there will be a list of numbers, followed by named entries, such as `levelRequirement`, `damageEffectiveness`, etc.  Each of these stats are mapped to a mod in Path of Building either via `SkillStatMap.lua`, or if the stat is specific to this particular skill (e.g. `spectral_helix_rotations_%` would only apply to Spectral Helix) in `skillStatMap` in this same table.  The corresponding mod will have `nil` in place of its normal value, and that value instead comes from this row in the `levels` table.  Notice that not all of the stats have a number in the first part of the `levels` row.  These extra stats are usually for booleans/flags that are always true.
+
+Notice how these stat numbers don't really align with damage numbers in any meaningful way for active skills.  The stat numbers are interpolated by the numbers in the corresponding position in the `statInterpolation` table in the same row.
+* 1 means take the number as-is.  This is the most common interpolation
+* 2 means apply a linear interpolation: `statValue = round(prevStat + (nextStat - prevStat) * (actorLevel - prevReq) / (nextReq - prevReq))`
+* 3 means apply an effectiveness interpolation.  Take this formula for current effectiveness and multiply by the gem level: `(3.885209 + 0.360246 * (actorLevel - 1)) * (grantedEffect.baseEffectiveness or 1) * (1 + (grantedEffect.incrementalEffectiveness or 0)) ^ (actorLevel - 1)` 
+
+The code for this can be found in `CalcTools.lua` starting [here](../src/Modules/CalcTools.lua#L166)
+
+## Adding skills
+
+1. Add `#skill grantedEffectId` to the appropriate template file for the skill
+2. Add `#mods` below that
+3. [Export the skills](../CONTRIBUTING.md#exporting-ggpk-data-from-path-of-exile) to combine it with the game data
+4. If there are stats in the `stats` table that aren't recognized already in `SkillStatMap.lua`, add a `statMap` table to the template file to map them properly to a mod.
+5. Add other mods via `#baseMod` if needed.
+
+## Adding minions
+
+The minion itself has to be added to `Minion.txt`.  This file uses different directives to construct the data, but the most important ones are `#monster monsterVariety monsterName`, `#limit modName`, and `#emit`. `monsterVariety` uses the Id from `MonsterVarieties`, while `monsterName` will be referenced in the skill gem.  `#limit` sets a limit on summoned monsters based on a multiplier calculated elsewhere on the character, and `#emit` works similarly to the `#mods` directive on skills.
+The only extra thing that needs to be added to the base skill is a table called `minionList` that contains the names of all the minions that skill can summon (`monsterName` from the previous step).
+Some minions have skills of their own.  These skills can be added like any other skill to `minion.txt`.
+

docs/modSyntax.md

@@ -0,0 +1,64 @@
+This syntax is used all over the codebase, but there are two locations that hold the majority of them: [ModParser](../tree/master/src/Modules/ModParser.lua) and [Skill Stats](../tree/master/src/Data/SkillStatMap.lua).
+
+The standard format of a mod looks like this: `mod(ModName, ModType, Value, source, modFlags, keywordFlags, extraTags)`  See the function declaration [here](../tree/master/src/Modules/ModTools.lua#L20-L46)
+
+### ModName
+Used as a key, so you can reference this mod elsewhere in PoB.  Can really be anything, but look around the codebase to find ones you need (e.g. "Damage", "Life", "PhysicalDamageGainAsLightning", etc)
+### ModType
+- "BASE": used for flat values that add to other base values (e.g. Flat added damage, flat life, flat evasion)
+- "INC": used for increased and reduced mods that stack additively.  Use a negative value to represent "reduced".
+- "MORE": used for more and less mods that stack multiplicatively.  Use a negative value to represent "less".
+- "OVERRIDE": used when you want to ignore any calculations done on this mod and just use the value (e.g. "your resistances are 78%" from Loreweave)
+- "FLAG": used for conditions.  Value will be true/false when this type is used.
+### Value
+This represents the raw value of the mod.  When it's used in the skills to map from the skill data, this will be `nil`, as it pulls the number from the gem based on the level.
+### Source
+This is where the mod comes from.  Often it will be automatically filled in, coming from a tree node, gem, or item.  If you do need to specify it for some reason, it's a string, and you can use "Tree:[nodeId]" as a special value to show a tree inset on hover.
+### Mod Flags
+These are bitwise flags that say what the mod can apply to.  See a full list [here](../tree/master/src/Data/Global.lua) under `ModFlag`.  If you want to use several flags at once, make use of `bit.bor` and `bor` (ModParser.lua uses this alias) to combine them.  When combined, all of the flags have to match.  If you only need one to match, use the "ModFlagOr" tag instead.
+### Keyword Flags
+These function similarly to the mod flags, and use the `KeywordFlag` group in `Global.lua`.  These are usually based off of the flags on the gem itself. If you want to use several flags at once, make use of `bit.bor` and `bor` (ModParser.lua uses this alias) to combine them.  When combined, only one of the flags has to match.  If you need them all to match, use the "KeywordFlagAnd" tag instead. 
+### Extra Tags
+Often a mod will only apply under certain conditions, apply multiple times based on other stats, etc.  The syntax for that depends heavily on the first parameter, "type".  There can be an infinite number of these tags at the end of a mod, so multiple can apply at one time.  Some parameters, like `actor` or `neg` can be used on all of the types.  Below are different types and the other parameters they need to function.
+
+* Condition: Used for conditions on the player that need to be in place before the mod applies (e.g. CritRecently, Shocked, etc.)
+    * var: Contains the name of the condition
+    * neg: (defaults to false) Boolean that negates the condition
+    * In order to set a condition, use "Condition:[name]" as a FLAG mod
+* ActorCondition: Used for conditions on an enemy or a minion.
+    * var: Contains the name of the condition
+    * neg: (defaults to false) Boolean that negates the condition
+    * actor: Can be "enemy" or "parent".  "parent" is used when giving a mod to a minion that is based on a condition on the player (its controller).  e.g. `mod("MinionModifier", "LIST", { mod = mod("Damage", "INC", num, { type = "ActorCondition", actor = "parent", var = "HavePhysicalGolem" }) }, { type = "SkillType", skillType = SkillType.Golem }),`
+* Multiplier: Multiplies the mod by this variable
+    * var: mod to multiply by
+    * limit: The maximum number the mod can go up to
+    * limitTotal: boolean that changes the behavior of limit to apply after multiplication.  Defaults to false.
+* MultiplierThreshold: Similar to a condition that only applies when the variable is above a specified threshold
+    * var: name of the mod
+    * threshold: number to reach before the mod applies
+* PerStat: Similar to Multiplier, but is used for character stats instead of arbitrary multiplier like number of sockets
+    * stat: The stat to multiply by
+    * div: Defaults to 1.  Divide by this number after calculation, rounding down.  Useful for mods that say "per 5 strength", for example
+* StatThreshold: Similar to MultiplierThreshold
+    * stat: The name of the stat
+    * threshold: number to reach before the mod applies
+* PercentStat: Used for mods based on percentages of other stats (e.g. Agnostic)
+    * stat: The name of the stat
+    * percent: value of the percent
+* SkillType: This type is for mods that affect all skills of a certain type
+    * skillType: An enum value in Global.lua
+* SkillName: Similar to SkillType, but specifies the name of the skill, usually for enchantments
+    * skillName: The English name of the skill (e.g. "Decoy Totem")
+* GlobalEffect: This is used largely for buffs and curses that affect actors even when it's not the main skill
+    * effectType: Can be "Guard", "Buff", "Debuff", "Aura", "AuraDebuff", "Curse".  These apply to you, you, enemies, you + minions, enemies, and enemies, respectively
+    * effectName: String to specify where the global effect comes from
+    * effectEnemyCond: Specify a condition so this mod applies to the enemy when that condition is fulfilled
+    * effectStackVar: Multiplies the mod by this variable (usually another mod)
+    * modCond: Apply the mod when the actor has this condition
+    * unscaleable: boolean that determines whether this buff can be scaled by buff effect
+* DistanceRamp: A rare type that is used on skills and effects that do different things at different distances from the character
+    * ramp: Numbers to multiply the mod by at different distances.  e.g. `ramp = {{35,0},{70,1}}` means the mod does nothing at 35 units, but has its full value at 70 units.
+* ModFlagOr: Used when you only need one ModFlag to match, e.g. `["with axes or swords"] = { flags = ModFlag.Hit, tag = { type = "ModFlagOr", modFlags = bor(ModFlag.Axe, ModFlag.Sword) } },` needs `Hit`, but can use either of the other two flags
+    * modFlags: Use `bor` as if you were adding ModFlags normally
+* KeywordFlagAnd: Used when you need all of the KeywordFlags to match
+    * keywordFlags: Use `bor` as if you were adding KeywordFlags normally