User talk:FeralKitty/Broadswipes - Revision history

FeralKitty: Pro and con of using (ability) name as a key

2021-09-24T07:53:09Z

Pro and con of using (ability) name as a key

← Older revision		Revision as of 07:53, 24 September 2021
Line 46:		Line 46:

	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. --[[User:FeralKitty\|FeralKitty]] ([[User talk:FeralKitty\|talk]]) 18:34, 21 September 2021 (PDT)		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. --[[User:FeralKitty\|FeralKitty]] ([[User talk: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 <code>assets/data/effects/bear/bearArmSwipe.json</code> (and its text is in <code>assets/text/effects/bear/bearArmSwipe.properties</code>).

			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 <nowiki>{{Description\|assets/text/effects/warrior/guard.properties}}</nowiki> would not be as intuitive or convenient as <nowiki>{{Description\|Guardian}}</nowiki>. (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. --[[User:FeralKitty\|FeralKitty]] ([[User talk:FeralKitty\|talk]]) 00:53, 24 September 2021 (PDT)

FeralKitty: Self-maintaining pages will limit what we might arbitrarily explain within the tooltip.

2021-09-22T01:35:40Z

Self-maintaining pages will limit what we might arbitrarily explain within the tooltip.

← Older revision		Revision as of 01:35, 22 September 2021
Line 42:		Line 42:

	What other approaches or improvements would you suggest, to help keep pages up-to-date, consistent, and/or useful? [[User:FeralKitty\|FeralKitty]] ([[User talk:FeralKitty\|talk]]) 13:15, 17 September 2021 (PDT)		What other approaches or improvements would you suggest, to help keep pages up-to-date, consistent, and/or useful? [[User:FeralKitty\|FeralKitty]] ([[User talk: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. --[[User:FeralKitty\|FeralKitty]] ([[User talk:FeralKitty\|talk]]) 18:34, 21 September 2021 (PDT)

FeralKitty: How might we keep pages up-to-date? Suggestions welcome!

2021-09-17T20:15:36Z

How might we keep pages up-to-date? Suggestions welcome!

New page

__TOC__

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:

<pre>{{Description|Broadswipes}}
{{Tooltips|Broadswipes}}
{{Formulas|Broadswipes}}
== Upgrade ==
{{Description|Broadswipes+}}
{{Tooltips|Broadswipes+}}
{{Formulas|Broadswipes+}}</pre>

== * 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: <nowiki>[[Broadswipes/description]]</nowiki> 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.

== A related categorization goal ==

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? [[User:FeralKitty|FeralKitty]] ([[User talk:FeralKitty|talk]]) 13:15, 17 September 2021 (PDT)