User talk:FeralKitty/Broadswipes
What I hope is for different types of pages to be (more) self-maintained by using (pre-processed*) information from the json/properties files.
For example, descriptions, tooltips, damage formulas, etc. could be up-to-date, as updates get released, by using templates instead of hardcoding the description or tooltip:
{{Description|Broadswipes}}
{{Tooltips|Broadswipes}}
{{Formulas|Broadswipes}}
== Upgrade ==
{{Description|Broadswipes+}}
{{Tooltips|Broadswipes+}}
{{Formulas|Broadswipes+}}
* How this could be done (pre-processing)
- All-in-one approach: some key/value hash or switch statement or 'grep' that pulls the corresponding info from a single description file.
- Update one file with all the descriptions, each time an update is released.
- Subpages: [[Broadswipes/description]] with description for Broadswipes, and the page (or template) simply transcludes the description.
- Pre-processing updates hundreds of files via bot.
- Needs Main space sub-pages enabled.
Where might these files reside?
- Outside the wiki, and we use a widget?
- More overhead
- Less familiar to wiki contributors
- Within the wiki, and we use templates and/or subpages.
Do we even pre-process files?
- Yes. Less overhead each time page is viewed.
- No. Extract data from the json and reformat, each time.
- Cache. Extract data from the json and reformat, once, then cache result.
All these approaches require different amounts of time, and if something breaks, who fixes it?
Off the top of my head, I'd say that pre-processing once, then keeping data inside the wiki, is the more reliable approach, and would let any contributor fix an issue by editing the template or subpage.
Make it easier or possible to see which abilities use potency, bonus damage, etc.
What other approaches or improvements would you suggest, to help keep pages up-to-date, consistent, and/or useful? FeralKitty (talk) 13:15, 17 September 2021 (PDT)
Avoid adding ", minimum 1"
In order for the pages to be self-maintaining as damage/formulas change, we would need to avoid arbitrarily adding comments to the damage line. E.g., x damage, minimum 1. This is probably fine, since (A) it mirrors the game tooltip (which doesn't mention that the ability does minimum damage), and (B) the collapsed formula contains that detail. --FeralKitty (talk) 18:34, 21 September 2021 (PDT)
Pro and con of wiki using (ability) name as key
Wildermyth keeps information about an ability in a specific file. For example, the Beartouched Swipes ability's code is in assets/data/effects/bear/bearArmSwipe.json (and its text is in assets/text/effects/bear/bearArmSwipe.properties).
Although the game uses a unique filename for an ability, that doesn't necessarily mean that an ability's in-game name is also unique. For example, there is a warrior ability named Guardian, but there are also three monster abilities named Guardian (each with a different description and usage).
While using the unique filename as the key would let us refer to the specific (warrior) Guardian ability blurb that we want, the downside is that {{Description|assets/text/effects/warrior/guard.properties}} would not be as intuitive or convenient as {{Description|Guardian}}. (Using the filename would also require a second parameter to specify which (base or upgraded) blurb was returned.)
Since we want anyone to be able to contribute, I think it's more important for the markup to be easier to understand and edit, so I'm leaning toward using the (hero) ability name as a key, and weeding out or dealing with duplicates in some different manner. --FeralKitty (talk) 00:53, 24 September 2021 (PDT)
