Template talk:UnitData

Module
I'm going to create a module to deprecate this. It will be created such that it is invoked like Tabbers are in the invocation now instead of having data being passed through Template:Enemy Info Tabber then passed through the unit data table template. This drastically decreases template argument size and post-expand include size, makes the page load faster, and makes section links work again (previously links to story sections did not work properly on pages with Enemy Info Tabber instead of direct &lt;tabber> because the browser would jump to the section, and then the enemy info would load, pushing the page down). Endilyn (talk) 21:56, 24 November 2018 (UTC)

To-do list discussion archive

 * Template:UnitData Will be replaced by Module:UnitData, see Template talk:UnitData and Module:UnitData/test for initial plans. Post suggestions, issues, changes, etc. to that plan here.
 * Field tests are done on Mystery Trial and Grounds of Wind: Wind 4. The former defines the units with, and queries them on the same page; this single query doesn't seem to incur a huge penalty. The latter performs just the query part for Battle 3. --HertzDevil (talk) 04:51, 18 July 2019 (UTC)
 * Documentation page is up. --HertzDevil (talk) 09:59, 18 July 2019 (UTC)


 * Internal slot orders and definitions for AI settings have been found, and mockups for wiki presentation are available at User:HertzDevil/sandbox/AI settings. For maps that use different settings across difficulties, decide whether to merge them manually with the Notes column, or present individual tables with a tabber. (we have Lua so we shouldn't need to worry about this yet)
 * Input exact levels for Lv. 40+ maps and units.
 * Come up with a design idea that displays Chain Challenge / Squad Assault stats in a more concise way, possibly deriving them directly in Template:UnitData.
 * A template shows:
 * then it executes UnitData with altered stats. I haven't figured out a system for it being able to pull the base map stats yet. Endilyn (talk) 19:43, 22 March 2019 (UTC)
 * Template:UnitData already calculates the base stats from the skills it pulls from the database, it should be possible to store the base stats instead of the calculated stats in (I don't think anything on the wiki queries those stats thus far). We also probably need a column for the canonical skill upgrades, the storing part is easy but the retrieval would be quite messy if the Lua-based replacement isn't ready. --HertzDevil (talk) 11:17, 28 May 2019 (UTC)
 * I think it's a good idea to store the base stats instead of final stats. Ideally the page input would be the base stats as well instead of the calculated stats, so that if a weapon's might is ever altered for instance the map page updates properly when the weapon page is updated, instead of having to update all map pages the weapon appears in. When the new enemy module is ready, is it possible for you to run a bot that can uncalculate stats while converting the old template to the new one? Endilyn (talk) 07:33, 29 May 2019 (UTC)
 * Same for cooldown counts I assume, i.e. using  instead of , especially considering cooldown counts did change once in 2.0.0. --HertzDevil (talk) 02:17, 30 May 2019 (UTC)
 * Yes, it is probably better to do a cd parameter instead of cdbonus. In Cargo, we can just store the default counts to be -1 like in the map definition files. Endilyn (talk) 21:54, 4 June 2019 (UTC)
 * Canonical skill upgrades are in, but we still need two extra fields before we can implement skill promotion,  and   (see User:HertzDevil/Reverse-engineering notes). I can't think of a clean way to add them here other adding up to 6 new template parameters in the various skill templates and Template:SkillDefinition. --HertzDevil (talk) 03:00, 7 June 2019 (UTC)
 * I also cannot think of a cleaner way, that is probably the best possible method. As a fallback, if the promotion data is missing for a skill on the wiki, it could display File:Passive No Image.png and  for passives, and maybe just "Unknown" for other skills. Endilyn (talk) 20:45, 2 July 2019 (UTC)


 * We can in theory dump the remaining fields from map unit definitions into the module; then the module (or whatever top-level module that eventually replaces Module:UnitData) will generate not only the unit lists but related contents like the AI settings table and reinforcement map displays as well. Some preliminary thoughts:
 * The  property indicates the unit is an ally unit.
 * The  property indicates the enemy unit uses the player version to calculate stats in derived maps.
 * Positions will continue to use the same format as Template:MapLayout parameters (,  etc.) since they are concise enough for manual input. They will be stored into the database.
 * AI settings will be specified using a nested table like . Since this can be tedious when done manually, there needs a way to specify default settings for all units. The output format is based on Template:EnemyAITable, but the settings won't be stored because no other templates or modules need them (as long as this table is emitted next to the map units).
 * Reinforcement settings will be similarly specified using something like  or  . At the minimum the database should know whether a unit is an initial unit or a reinforcement. Derived maps will most likely need some form of knowledge about the exact reinforcement settings of every unit.
 * Template:MapLayout has been migrated to Lua, so it can be invoked through . For reinforcements units are grouped according to their spawn settings, just like what has always been done. The initial map display, which sits in the infobox, shall query  and fill out the initial units automatically; the player positions will still have to be manually specified.
 * We will also need to store the map difficulty into as well, they are needed for querying the proper map definitions (I imagine this is difficult for the current template-based approach). One last point: derived units shouldn't be stored into the database unless there is a good reason to query them directly. --HertzDevil (talk) 10:17, 16 June 2019 (UTC)
 * An idea is that the first unit has  specified, and the AI settings are filled in for every unit afterwards except for units that have their own   parameter.   is being stored so that a specfic instance of a map can be queried, even if two different instances of a map have the same difficulty. (Example: Tempest Trials have more than one Lunatic mode)  Storing derived units may be useful for statistical analysis (ex: what is the average spd of PvE units?), and they could be stored with a   property to prevent accidental querying, but if it's too much trouble then they should just be dropped. Endilyn (talk) 20:45, 2 July 2019 (UTC)
 * I can't think of a situation where we need such statistical queries on derived enemy stats (even normal enemy stats).
 * alone should suffice; strictly speaking, the difficulty is a property of a scenario rather than a map. The other alternative is to store the full map ID (e.g.,  ) and base queries around that rather than the tab names, since they are more stable. --HertzDevil (talk) 09:21, 4 July 2019 (UTC)
 * Currently Module:UnitData/test/doc/Bows: Special Training is able to group units into their reinforcement types and display the corresponding reinforcement maps. The entire map image, which is just a regular MapLayout with starting spots and units stripped, is passed to the entry point of the module, and then another MapLayout superimposes the units on top of it directly, this time inside the module. It is not perfect, but already reduces a lot of manual input and still remains faster than the real deal. At the moment I cannot think of a better solution that does not involve storing terrain information into the Cargo database. --HertzDevil (talk) 21:39, 15 July 2019 (UTC)
 * Currently Module:UnitData/test/doc/Bows: Special Training is able to group units into their reinforcement types and display the corresponding reinforcement maps. The entire map image, which is just a regular MapLayout with starting spots and units stripped, is passed to the entry point of the module, and then another MapLayout superimposes the units on top of it directly, this time inside the module. It is not perfect, but already reduces a lot of manual input and still remains faster than the real deal. At the moment I cannot think of a better solution that does not involve storing terrain information into the Cargo database. --HertzDevil (talk) 21:39, 15 July 2019 (UTC)