Megami Tensei Wiki

Centralized skill data for stat templates

Forum page

4,386pages on
this wiki
Add New Page
Forums: Index > The Cathedral > Centralized skill data for stat templates

As you can see in my horrible recent edits, I'm testing Lua module to handle skill data in stat box, you can see the result in template:SMTstats/sandbox. So you only need to give the (exact) skill name and then Lua module will fetch the cost, effect and level data of specific skill to the stat template. The reason I use Lua rather than wiki parser function (#switch:) is simply because Lua loads faster. If you don't know Lua or any program language (I don't know much either and I troubled someone skillful in Wikipedia before making Module:Skills works correctly), you can still help manage skill data tables like module:Skills/SMT1. It should be very straightforward to replicate another table for other games. We can only start modifying each stat template when the skill data table module is ready. -- Inpursuit (talk)

that's pretty cool, i didn't know stuff like that could be done; it'll make things a lot easier than having to add them all in manually on every demon's page (though the levels/ranks at which they're learned will still need to be done manually), which will make making changes hell of a lot easier (eg, we could change the Devil Summoner and Devil Children templates to show more than just the skill names with very little additional work). while it would theoretically be possible to do this with #switch, it'd be an extremely poor and crude way to do it since you'd have to input every single skill's details into the template for every Skill input (so for SMT1 you'd need 3 copies of every skill, and 6 copies for SMT2), which would make it an incredibly lengthy mess. i'll start working on the module:skills/game pages soon. Tathra (talk) 17:17, January 10, 2015 (UTC)

Even though SMT3 stat template with Module:Skills seemingly works well, this is not the ultimate result I want. What I have in mind is to get rid of the Skill# and Level# parameters completely like this:


I know someone is doing this already in Wikipedia like this module but I can't replicate it due to my limited knowledge of Lua. Anyone who knows better are appreciated to help implement it. Thank you. -- Inpursuit (talk) 04:09, January 15, 2015 (UTC)

is such a thing necessary? i mean, sure it sounds like a cool idea, but we already have thousands of pages and probably tens of thousands of stat templates, all of which would need to be changed to support the new implementation.
lets compare it to the other 2 wiki-wide changes (requiring basically eveyr page to be edited or affecting basically every page) in the past few years - adding categories through stat templates and now adding skills through the lua module.
categories through stat templates:
effect - if categories are changed (like changing "category:megami ibunroku persona demons" to "category:persona demons" or "category:cult of gaia" to "category:ring of gaea") they only need to be changed at the template itself, then the changes automatically happen the next time each individual page is edited.
required work - all 'hard' categories (categories added directly to the pages) which are already added by a template must be deleted
skills through lua module:
effect - skills are all added to the pages from one list; if skill descriptions need changed, like if SMTII or if... get localized, only the one list needs to be changed rather than every single demon's page.
required work - make the list pages and update the templates, and any pages which have skills which aren't on the list due to misspelling or having the wrong input ("SkillAG1" instead of "Skill1") need to be updated. deleting Costs and Effects already on the pages isn't a requirement, but they're unnecessary and can just be removed the next time the page is edited. a far better implementation than was used for the categories by template, but implementing something similar for it would be easy since just the templates would need updated now.
what would be the benefits of changing the way skills are input? would it be worth the amount of work required to properly implement it? both types of inputs would have to be acceptable until all invokations of a template were changed (eg, the old P1 resistances style has to stay working until all the P1 demons and personas get updated to the new style, showing each resistance individually), so what would be the incentive to change them?
don't get me wrong, i'm not saying its a bad thing; it'd be cool to have it as an option and would probably turn out to be useful in other places, and could be used for any new stat templates that get created, but i just don't see it being worth the amount of work required to implement it for Skills. Tathra (talk) 22:41, January 15, 2015 (UTC)
I am fully aware of the work required for executing my thought, even though we can ask wikia staff for bot operation. At least I hope this would be feasible for Persona 5 and subsequent SMT games. My concern is that the traditional wiki parser functions increases the article template size. In the extreme case, the server/wiki software would refuse to load the resultant page (but still possible to be edited) when template size is too large. The issue is not instantly obvious to every user because whether a page would show also depends on the user's internet connection speed: the slower the more likely the page won't show with tons of parser functions involved. In any case, letting Lua module handle the if/switch logics allows articles with stat templates to load much faster, which is especially helpful for articles of demons like Cerberus and Jack Frost which have high amount of appearance in the series. -- Inpursuit (talk) 23:11, January 15, 2015 (UTC)
About the SMT3 boss stats, actually they have mp cost as well, so mana drain strategy works on them (as well as DDSAT1 but not 2). The problem is in the same time, their physical skills don't cost HP so this is a dilemma whether we should show the cost or not. -- Inpursuit (talk) 23:11, January 15, 2015 (UTC)
yeah, faster loading times would be worth the work, especially since some of the pages are already so long as to be problematic. it looks like it uses javascript like the MediaWiki stuff, but i don't know anything about JS; if i dig in to reference materials and start trying to learn it though i'm usually a pretty fast learner, so i'll see what i can do to help (i want to update the module to support fusion skills anyway). let me think on the boss skill costs thing for a bit; an argument for not showing them is that bosses can use different versions of spells with lower or no cost or just effectively have infinite MP, but in games where MP draining is a valid tactic then they need to be shown; the best i have right now is using the if to display something like <abbr title="Physical skills have no cost">Cost</abbr> for bosses, but there might be a better way. another zero-cost version of the physical skills used by bosses (like Berserk and Berserk* or something similar) could just be added to the list, but hopefully there's a better way to go about it. Tathra (talk) 23:32, January 15, 2015 (UTC)
i think i've got it.

{{#if:{{{Skill1|}}}|{{#invoke:Skills|row|{{#if:{{{Boss|}}}|{{#switch:{{{Skill1|}}}|phys skill|phys skill|phys skill|etc= r01 |#default= r11}}}}|SMT3|{{{Skill1|}}} }} }}

this should do it. you'd have to list all the physical skills that are used by bosses (which hopefully isn't too many since each Skill line would have to have this), but then if its marked as a boss and uses a physical skill, it wouldn't show the cost, but would show the cost for everything else. if there's a lot of physical skills that are used by Nocturne bosses though, it'd end up being so long that it'd probably be better to go with something simpler. Tathra (talk) 05:38, January 17, 2015 (UTC)
I edited module:Skills and template:SMTNstats so now all enemies' physical skills will span across the "cost" and "effect" column if "enemy" parameter is checked. If you don't like it I can modify module:Skills again so the cost of all physical skills are listed "0" when "enemy" is checked. -- Inpursuit (talk) 06:43, January 17, 2015 (UTC)
Strong Void Drains Repels Weak
- - - - -
List of Skills
Skill Cost Effect
Agidyne 10 MP Heavy fire damage to one foe.
Blight Small physical damage and 20% poison to all foes.
High accuracy. Power related to user's max HP.
Dragon Eye 1 MP Grants user's team four blinking turn icons. (Enemy-only)

Stats templates by LuaEdit

I have made some major progress in module:Skills/sandbox that the new stats functions (SMT1 and P4 so far) can pretty much replace their template counterpart which means that they will load faster. You can see the actual result in template:SMTstats/testcases, although I think the sandbox templates need to be tested exhaustively to make sure they are bug-free (when used correctly, that is.) The template transclusion markups in articles can remain unchanged, except for the markups in the list of skills which must be alternated to cope with the new format. The reason I don't assign specific parameter names (e.g. Skill1, Skill2, Level2) for each skill is because the new format allows you to input skills as much as possible without worrying if there are insufficient skill entry parameters. The new design is practically unlimited, all you do is to write the next skill on a new line. If you need to add learning level, just add BACKSLASH and then level figure like this: \innate. That's it.

I understand the new list of skill format requires tremendous amount of time and effort to revise the current transcluding articles. We can either request wikia staff's assist for mass edit run by bot (or WP:AWB). The other option is to do nothing and save it for P5 which seems the stats system won't stray too far from P3/4. -- Inpursuit (talk) 13:26, January 30, 2015 (UTC)

Known issues
  • No Scribunto equivalence of "#ifexist" to check if an article exists on this wiki. This has been officially confirmed by wikia staff. You also can't simply type the full #ifexist syntax into the module, it won't be processed and the full code of the ifexist will be shown directly in the article.
Finally I have included most stats templates into module:Skills/sandbox. I exclude {{Gun}}, {{Sword}}, {{SMT9stats}}, {{20XXstats}}, {{P5stats}}, because Gun and Sword don't involve skill list, SMT9 and 20XX are very inaccessible (for both playability and availability) and I doubt anyone today would bother to look for any rom or emulator. P5 simply lacks substantial stats information by now. The testcases page compares the usage between module and legacy template so if you have trouble of converting the existing demon articles you can check it and report if there is missing of crucial parameter. Even though the module code is in the sandbox page, {{stats}} which invokes the sandbox module isn't. We can apply the sandbox module to the main module only when the conversion of all demon articles are done. -- Inpursuit (talk) 03:57, February 24, 2015 (UTC)

I wish to address this before Inpursuit goes on further. First of all, this work is really commendable. It is easy and convenient, having the stats template invoke data from an existing centralized database. Not only has it meant we reduce the article size, meaning that loading times are indeed faster, but also from an editor's perspective, this means we have a consistent wording for all our skills descriptions.

But, I have some issues, first with the sudden change of template design, and second with the lack of a user guide. And by the looks of it, not only are we moving to a centralized database, we're also moving to centralized stats template. Inpursuit's building of the unified stats template will mean that all the varied by-game stats templates will be scrunched into one - and there are things to consider.

In the past, our templates have been consistent in their design - and that's the overarching policy. And I wish for that to continue, even as Inpursuit continue to redesign it. I do admit, the bar graph is a really cool idea - that the games in the series use a vertical bar graph makes it a nice shoutout. But if we want to implement them, it should be applied consistently, and that it should complement the whole design of the template, color and all.

Then there's the lack of user guidance for this implementation. We use to have coding guide for the stats, each of them, so that user know what the parameters are and what inputs to write in. Users of the Wikia skin can just pick the templates out from the edit box, and input the data in the form. It's a pretty straightforward process. I observe right now that the input guide is all over the place, and we haven't even consider how to implement categories for enemies with special properties: Bosses, Specific spinoff Game appearances etc.

So these are the two questions I'm putting forward to Inpursuit: 1. How can we make a consistent clean redesign for the stats template? and 2. How shall we write the userguide for the templates? Please lay out all your plans so that we can get this project done sooner rather than later. BLUER一番 21:33, March 4, 2015 (UTC)

I apologize for the lack of documentation. The reasons for that are the module is still undergoing debugging (requires more applications in more demons' pages to study if any error may occur), also because the most important differences between the legacy stats templates and the new module-based stats template are: 1) the first parameter which defines the game style (e.g. smt1, p3, pq). 2) the list of skill entry format. Otherwise the other parameters like race, level, strength, etc. are pretty much the same. The principle of the new stats template is to minimize editor's burden of knowledge when updating demon's stats.
Regarding the infobox style, Nocturne was the only game I wanted to modify the general color scheme. The colors of the rest are mostly the same or at least consistent to mediawiki:Common.css (for reason not known to me, giten and childmessiah have different color schemes between common.css and stat templates). As for the HP/MP colored bar of Nocturne and SJ, the new style references the actual in-game UI to make the figures easier distinguishable, but the design can be removed if not well-received. Generally the new design is not set in stone and can keep improving. -- Inpursuit (talk) 01:37, March 5, 2015 (UTC)
Good job on the documentation! It might need some more guidance on the list of game codes usable, but maybe we can start retiring the rest of the individual game stats templates. BLUER一番 08:15, March 7, 2015 (UTC)
the stat bars look pretty good, i like it. they're used in practically every megaten game though, so nearly all of them should use that style. imo they look better without space between them (the smt3 bars look better than the smt1 ones). Tathra (talk) 02:02, March 9, 2015 (UTC)
I set greater "line-height" for bars of smt1/2/3/if because there are 6 (instead of 5 of smt3/sj/4) stats which use bar in the GUI. If I apply the same bar dimension of smt3/sj/4, it's either the vertical height of those 6 stats have to be squeezed more or the height of the table cells next to the stat bars section will be lengthened even more which is uglier IMO.
I didn't apply the stat bar to all games also because I'm not 100% sure about the max stat figure which is crucial in calculating the actual width of the bar. -- Inpursuit (talk) 07:18, March 12, 2015 (UTC)

I'm asking for help here since the Lua script is too complicated for me to understand and edit it myself, but there's a minor error in the P1 template. "Item Drop" and "Return" are linking to "List of Persona Items", which doesn't exist, instead of List of Megami Ibunroku Persona Items. G.A.S.A (talk) 19:56, March 27, 2015 (UTC)

I simply created the redirect page of List of Persona Items because it's a valid name as well. -- Inpursuit (talk) 00:08, March 28, 2015 (UTC)

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.