overspend1/PathOfBuilding
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix dead documentation links and refactor to use relative links (#4543)

Browse Source 
* FIX: Fix broken links and convert full ones to relative

* FIX: Remove confusing(?) double qoutes and unnecessary(?) brackets
This commit is contained in:
Paliak
2022-07-10 12:51:05 +02:00
committed by GitHub
parent 5750d0f28b
commit 8fe32d6d5f
2 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/addingMods.md
View File

@@ -1,7 +1,7 @@
In this tutorial, we'll step through the logic in `ModParser.lua`. This module takes care of parsing mods from any item, passive node, or pantheon in the game. This won't be comprehensive, since there are many patterns, and a lot of examples to work off of. If you'd like to follow along, the code starts [here](https://github.com/PathOfBuildingCommunity/PathOfBuilding/blob/master/src/Modules/ModParser.lua#L3453). Having a good understanding of [Lua patterns](https://www.lua.org/pil/20.2.html) will also be invaluable here (If you know regex, patterns will be similar, but less powerful and a different syntax).
In this tutorial, we'll step through the logic in `ModParser.lua`. This module takes care of parsing mods from any item, passive node, or pantheon in the game. This won't be comprehensive, since there are many patterns, and a lot of examples to work off of. If you'd like to follow along, the code starts [here](../src/Modules/ModParser.lua#L3453). Having a good understanding of [Lua patterns](https://www.lua.org/pil/20.2.html) will also be invaluable here (If you know regex, patterns will be similar, but less powerful and a different syntax).
#### Jewels
The first mods parsed are mods from jewels with a radius. Jewels with a radius care about the nodes around them. Since PoB doesn't know where these jewels will be placed when parsing the mod, a function is prepared for when the jewel has access to this information. Any variable data are passed along much like other mods via pattern capture (i.e. anywhere you see `cap1`, `cap2`, etc., corresponds to a captured number from the Lua pattern) See [`CalcSetup.buildModListForNode()`](https://github.com/PathOfBuildingCommunity/PathOfBuilding/blob/master/src/Modules/CalcSetup.lua#L76) for the code that handles actually calling the function to modify any nodes. There are several helper functions specific to each type of jewel, but they all boil down to this function (which can be used on its own, when necessary):
The first mods parsed are mods from jewels with a radius. Jewels with a radius care about the nodes around them. Since PoB doesn't know where these jewels will be placed when parsing the mod, a function is prepared for when the jewel has access to this information. Any variable data are passed along much like other mods via pattern capture (i.e. anywhere you see `cap1`, `cap2`, etc., corresponds to a captured number from the Lua pattern) See [`CalcSetup.buildModListForNode()`](../src/Modules/CalcSetup.lua#L76) for the code that handles actually calling the function to modify any nodes. There are several helper functions specific to each type of jewel, but they all boil down to this function (which can be used on its own, when necessary):
- `function(node, out, data)`
- `node`: The node that is being affected within the radius. Can use things like `node.type` to determine notable or keystone, for example
- `out`: Instance of `ModListClass`, used for altering or replacing the mod originally on the node
@@ -17,24 +17,24 @@ There are 4 categories of jewels that have a helper function:
- `factor`: If the conversion shouldn't apply the full value, apply this factor instead
- Jewels that modify themselves based on stats allocated in their radius
- `getPerStat(dst, modType, flags, stat, factor)`
- The first three parameters correspond to name, modType, and flags in the [mod syntax](https://github.com/PathOfBuildingCommunity/PathOfBuilding/wiki/How-does-the-Mod-syntax-work%3F), where only `ModFlag`s are used
- The first three parameters correspond to name, modType, and flags in the [mod syntax](./modSyntax.md), where only `ModFlag`s are used
- `stat`: The stat we're multiplying the `dst` stat by
- `factor`: If the stats aren't 1:1, use this factor to change that
- Jewels that modify themselves based on stats unallocated in their radius. This uses the same `getPerStat` function as above.
- Threshold jewels, which give stats after 40 of that stat is reached in their radius
- `getThreshold(attrib, name, modType, value, ...)`
- `attrib`: The attribute we need to reach a threshold for
- The rest of the parameters are covered in the [mod syntax](https://github.com/PathOfBuildingCommunity/PathOfBuilding/wiki/How-does-the-Mod-syntax-work%3F)
- The rest of the parameters are covered in the [mod syntax](./modSyntax.md)
- Cluster jewels, which parse simply what mods to add to their nodes and which notables to add as well.
### Scanning for matching text
The next steps all use the `scan` function to match text. It looks for the "earliest and longest match from the [given] pattern list". If a match is found, it returns the value from the list, the remaining unmatched text, and any captures associated with the matched pattern. For example, passing in "15% increased fire damage", and a table containing the key "^(%d+)%% increased" would return the value corresponding to the key, "fire damage", and 15.
The next steps all use the `scan` function to match text. It looks for the earliest and longest match from the given pattern list. If a match is found, it returns the value from the list, the remaining unmatched text, and any captures associated with the matched pattern. For example, passing in "15% increased fire damage", and a table containing the key "^(%d+)%% increased" would return the value corresponding to the key, "fire damage", and 15.
### Special mods - `specialModList`
This is the largest list of `ModParser` and it's a catch-all for mods that don't fit a standard format (and aren't numerous enough to change the parsing logic to accommodate their format). If the mod has a component captured via Lua pattern, a function can be used to capture the number(s) or other captured text. E.g. `["lose ([%d%.]+) mana per second"] = function(num) return { mod("ManaDegen", "BASE", num) } end,`
Otherwise everything in this list can be done using the standard [mod syntax](https://github.com/PathOfBuildingCommunity/PathOfBuilding/wiki/How-does-the-Mod-syntax-work%3F)
Otherwise everything in this list can be done using the standard [mod syntax](./modSyntax.md)
***
## Parts of a "standard mod"
@@ -61,7 +61,7 @@ Finally we look through `modNameList` and match the remainder of our line on `["
# Putting it all together #
Our example is fairly simple, as some mod forms will slightly alter mod names and values to be compatible with with names used elsewhere in PoB. Regardless, once we have the mod name, type, value, and tags, we can combine them all into a mod as defined in the [mod syntax](https://github.com/PathOfBuildingCommunity/PathOfBuilding/wiki/How-does-the-Mod-syntax-work%3F).
Our example is fairly simple, as some mod forms will slightly alter mod names and values to be compatible with with names used elsewhere in PoB. Regardless, once we have the mod name, type, value, and tags, we can combine them all into a mod as defined in the [mod syntax](./modSyntax.md).
## Important notes and tips ##
@@ -77,4 +77,4 @@ Our example is fairly simple, as some mod forms will slightly alter mod names an
### 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](../src/Modules/ModParser.lua#L3662). These have to do with enemy or minion modifiers, or mods that don't directly affect the player.

6
docs/modSyntax.md
View File

@@ -1,6 +1,6 @@
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).
This syntax is used all over the codebase, but there are two locations that hold the majority of them: [ModParser](../src/Modules/ModParser.lua) and [Skill Stats](../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)
The standard format of a mod looks like this: `mod(ModName, ModType, Value, source, modFlags, keywordFlags, extraTags)` See the function declaration [here](../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)
@@ -16,7 +16,7 @@ This represents the raw value of the mod. When it's used in the skills to map f
### 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.
These are bitwise flags that say what the mod can apply to. See a full list [here](../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