User:Mindtheblob/notes

I'm sorry you feel that way. I think everybody involved here sees the value of having a bot update the game data for the wiki. The issue seems to be more with the presentation of said data. And to a lesser extent, some underlying differences in views on the wikis purpose.

I started writing some thoughts on this yesterday.

Theme Pieces

I think a sub section for every theme piece has merit and consistency, but admittedly, the scrolling through of repetition of related abilities will not please the reader, as has been discussed here. The difference to the game UI being, that instead of clicking on information one by one, the information is displayed in its entirety without reader choice, control, or filtering.

Perhaps there could still be some way of finding a middle ground?

Has separating effects (abilities) given by themePiece aspects into its own section of a theme page below theme pieces been discussed? There, they could be displayed once by effect id, requirements, and the current tool tips, which I feel are perfectly excellent.

Since these theme related abilities are effects of aspects, first given with theme pieces, then targeted with theme piece aspects, I wouldn't see it breaking the logic of the code to have a) a separate sections for abilities and b) some disclosure for dependent theme piece combinations. If and when any given effect requires [x, y, z, å] theme piece aspects. An effect like bearHug is given in either arm, but it won't be enabled until the aspect requirements of the effect are met in the effect's targets.

Non-existent upgrades

In my opinion, the foreseeable more confusing matter has to do with non-existent upgrades. Showing a Thorn Lash+ when there isn't such a thing in the game files is confusing to the reader, as well as any future wiki contributor.

So take the botanical upgrades, since there is no ability upgrade aspect along the lines of theme_vine_upgrade nor is there any hint towards anything of the sort present or being planned for in the formulae of the theme's abilities, I don't quite see the case for it to exist in the wiki presentation, except for anticipating it based on a pattern.

But anticipating based on patterns in current presentation doesn't feel like the purpose of a game wiki. A case can be made to guard for future changes, but even this relies on the assumption that patterns will not be broken. Take the one-upgrade-per-theme -pattern. There is nothing restricting other theme piece related abilities and their upgrades to being added.

It's perfectly possible to add a leap ability for bear legs, and have a separate upgrade for it alongside of the Bear Swipes+ (theme_bear_upgrade) upgrade (tried this out today just to be sure :snappingturtle:). But it's not something we're going to anticipate.

The best possible scenario would be for the automated code to know how to validate an upgrade aspect as related to a theme piece's ability effect, and thus be worthy of an upgrade mention and tooltip. For common and class skills this won't be a problem because the upgraded ability is already specified in the upgrade aspect .json under "upgradeForAbility", which the theme upgrades lack.

But could there be a workaround? For example, since we know upgrade aspect id's appear in ability effects as part of formulae, could this knowledge be applied as something of the sort to be used to validate that an upgrade aspect does in fact modify an effect? (There might be exceptions where this does not apply?)

But if that is difficult to implement, I think a better scenario is to not present non-existent upgrades, whether that is done by commenting out or other means.

I agree it is beneficial to the reader to know there is no upgrade, but displaying these non-upgrades, to my eye at least, dilutes the purpose. It's more akin to showing non-facts than hiding facts. That being said, if a bot is able to find a new upgrade and implement it accordingly, well that's just awesome.