WARFRAME Wiki
Advertisement
WARFRAME Wiki
Photo-4
“It's taking longer than I calculated.”
This page is actively being worked on and may not be completely correct. Please assist in making this page accurate. See WARFRAME Wiki:Research on ways to perform research on this game. Click here to add more info.

Design document for improving the Maximization calculator for Abilities. Currently they are informally sunsetted and will not be frequently updated or have continued maintenance on them.

Readers can discuss this topic on WARFRAME Wiki talk:Maximization Calculator.

Last updated: Fri, 22 Dec 2023 21:10:00 +0000 (UTC) by User:Cephalon Scientia

Current Implementation[]

Current calculators use Template:WFmax for adding input form (<div id="maximization_table_{{{1|}}}">) and output display (<div id="maximization_{{{2|}}}">) HTML and JS script on MediaWiki:Maximization.js for interactive elements. All of the relevant ability data used for the calculator is stored on MediaWiki:Maximization.js which means that non-admin editors cannot readily update values without going through an administrator.

Issues[]

  • Ability data is not readily accessible by readers and editors, violating the principle of open data that we strive for as a publicly editable wiki.
    • Thus it is not scalable to apply to new content or changes to WARFRAME. Often times calculators are outdated because the people who care cannot update these values or unsure where to update them.
      • This issue goes beyond the calculator project and applies wiki-wide. There is a high barrier to entry in wiki editing, especially on this wiki, due to the usage of complex templates, Lua scripts, and data that go way beyond simple text markup. Think there needs to be a community-wide effort to upskill readers to become editors, but that implies a job function rather than a hobby activity. Wiki editing is time consuming and not a traditional medium for entertainment. It takes a special type of individual to be passionate about information sharing, community collaboration, and public service.
  • Bloated script. On any given ability article, all of the additional ability data will never be used, using up reader bandwidth.
  • No support for internationalization and localization; cannot scale to non-English users.
  • Doesn't explore the use of data-* attributes to store resultant ability data. Could potentially help with scalability.
  • Vanilla MediaWiki does not have a good infrastructure for developing interactive widgets or applets, especially those that interface with databases based on the open data model.

Alternative Solutions[]

Module Database Model[]

There was an attempt at porting some of MediaWiki:Maximization.js data to a module Module:Maximization/data. Though there are few issues with this approach:

  • 21:08, 22 December 2023 (UTC) update: We can store JSON native data on pages that have the JSON content model like NightwaveActs.json. There is now native support to read JSON data from pages within Lua modules via mw.loadJsonData() which will allow data to be accessed in Lua.

  • How would JS interface with data stored in Lua tables? There is currently no infrastructure in place that allows the conversion of Lua tables to JSON.
    • Would have to import a Lua to JSON converter before being able to access the data in JS. This means that the client would have do lots of overhead work before being able to perform any calculations:
      • First, they have to convert the data to a JS-readable format.
      • Second, they have to interpret strings that store formulas to callable functions or arithmetic operations through some awkward RegEx or string manipulation.
    • A creative solution would involve using MediaWiki's Action API to fetch the string JSON result of a Lua module function call that converts Lua tables to a JSON string through Module:JSON. Client JS would still have to execute a JSON.parse() to read the JSON string.
      • Unsure if we can cut the middleman and just store data as native JSON like with NightwaveActs.json. Action API doesn't seem to have the option to fetch page content when the content model is in JSON. Would have to fetch JSON using query param ?action=raw. Still issue of loading more data than necessary when executing script.
    • There is a Lua VM implemented in JS to allow Lua code to be interpreted in client-side JS: https://github.com/fengari-lua/fengari and https://github.com/fengari-lua/fengari-web. Unsure if this can be used in a MediaWiki context.

  • Is there a universal data schema that can apply to all abilities in the game despite their complex interactions and implementation with ability attributes and augments?
    • Explore Polish notation when defining formulas? Lisp-like expressions?
    • Vanilla JS has a Function() constructor that we could use to store calculation logic in data. This way we can have custom editor-defined formulas to calculate stats.

Modifying Static Values On Ability Articles[]

We can have the calculator modify static values that already exist on all ability articles within Template:AbilityU10.3 arguments. A quick, hacky approach would to use RegEx to extract number values to be manipulated by the calculator. Though this wouldn't work for stats that deviate from the multiplicative calculation (Final Stat = Base Stat * (1 + Ability Modifier Bonus)). Would have to explicitly define those calculations somewhere, either on the article (within HTML attribute) or in a separate centralized location (like a Lua module).

This approach would store raw ability data on individual ability articles (within templates) instead of having them in a centralized repository. Ideally, we should have both raw ability data and ability stat formulas in one location for editors.

Discussions[]

Advertisement