User:Aldyron/Sandbox/Monster Manual experiment

Reasoning
Personally, I'd much prefer a Monster Manual in single table form, rather than multiple tables form. In fact, I have a spreadsheet on my computer laid out that way. That makes certain browsing patterns more practical. Let's see if wiki tables could fit the bill as well. I'll explain how I use it if and when I get it in shape.

Moreover, I'm a big fan of "a single source" wherever and whenever possible and practical. This comes from theory and practice: whenever any kind of database gets duplicated even partially, the (possibly multiple) duplicates soon start misaligning. That leads to people (say, me) often finding out-of-sync data, usually without even realizing it, and the efforts to maintain the several copies of the data likely becomes too onerous. I consider this the zeroth law of database handling: always strive for single-source, never duplicate unless indispensable, always consolidate if not unpractical.

Finally, as a wikibeginner, I need practice in a lot of fields. I'm going to use this as a starting/stumbling point in order to find out what I need to learn about wiki software. :-) That's why I'm doing this by myself instead of making requests to my senior fellow editors. As soon as I have something resembling publish-ready, I'll tap people on the shoulder.

It all started when I decided to go hunting every Rust Monster in the game...

Table, hand-crafted
The table itself is looking good.

Labeled Section Transclusion
Labeled Section Transclusion doesn't work (yet?). Labeling sections in the template doesn't seem to propagate the markup to the actual pages, so lst can't work. I'm not sure if it's impossible or just me being a newbie: seems to imply it cannot work, while  seems to imply that it can, since I'm not interested in dynamic tags. The jargon is too new to me, I'm not sure about the practical meaning of those sentences. Besides, I suspect the sanitizer isn't my ally, as far as lst is concerned.

Anyway, head's full of lst, I'm stuck in a loop of the same three ideas, so time to switch to something else for the time being, in order to clear up the slate.

Will give Dynamic Page List a try.

Dynamic Page List
Unless something ugly shows up during tests, dpl definitely looks like the way to go. I'm halfway there already, in a few minutes' time. Strange, I was expecting something like the 90-90 rule, but I'm more in a 50% work in 1% time, 50% in 179% situation. :-) Fact is, the more I study dpl, the grander ideas I get.

I may need a template to map kind to volume. Update: done, User:Aldyron/Sandbox/Template Mm kind to volume

I may need a phantom template or two in order to sub-query.

include then format together to pull content then create content for the same row. Works both for static data (pointless, but not in every scenario) and for dynamic data.

It just occurred to me that dpl makes it possible to write quite an array of "diagnostic" tables. I'l try to concoct a few.

[http://semeb.com/dpldemo/index.php?title=DPL:FAQ#A.29_A_table_of_page_meta-data.3B FAQ / How do I create tabular output? / A) A table of page meta-data]

Test table / A2: putting the link into the second column

DPL:Manual - General Usage and Invocation Syntax / Characters with special meaning

Diagnostics
Try to make sorting order stricter.

Update: tough luck.

Monster Manual table (hand-crafted): current state
What follows is my experimentation to reformat and expand Mm export by hand (for now) into a shape more suitable to me and, I believe, to anyone else. I'm now pretty much satisfied with the result, as far as both (minimal) aesthetics and end-user functionality go.

Why change?
I'll explain why I changed certain aspects of the original Mm export table. It's only right that I start by saying I appreciate the hard work of those that came before me, whose results I based my efforts on. Never in my mind was present the idea to lower their images to raise mine. Nonetheless, I believe there's room for improvement, which I hope to promote by means of the following notes.

Column headers
First off, the column headers.
 * "MM kind" instead of "Type / Race". The naming convention nazi in me is at work here. I try to strictly follow the D&D 3.5 naming scheme. Every time I'm in doubt, I ask myself: "What would the Sage recommend? What would Sean K. Reynolds comment?" You know, the Sage, Skip Williams, the one who wrote the D&D FAQ... Sean K. Reynolds, co-author of several books in the 3.5 line, the 3.6 line and more... Several man-years' worth of work went inside the decisions that make up the naming scheme, there's a reason for every name, and it stood the test of time. That kind of streamlining alone solved several year-long problems. I consider it 99.5% flawless. With that in mind, note that in this column we have entries that are not types (e.g. "Human": creatures with the Humanoid type and the Human subtype) nor races (e.g. "Flesh Golem": creatures with the Construct type and no subtype, which do not breed - I hope! - thus do not qualify as a race). Besides, several monsters are listed under headings which (to a naming convention nazi) are the wrong ones (e.g. "Undead Bilge Rat": a creature with the Undead type and no subtype, which is listed under "Rat": creatures with the Animal type and no subtype). No problem with that per se, but at this point I frown at the sight of either "Type" or "Race" at the top of the column. All things considered, the best alternative column header I could think of was "kind of creature as listed in the Monster Manual", in short "MM kind". Come to think of it, I might as well put it in the legend. Come to think of it, we've got no legend, might be good to add one. :-)
 * A similar reasoning lead me to "MM category" (additional column, see next section). Entries that are not types (e.g. "Player Races", "Misc."). I'm pretty unsatisfied with this one, since it clashes with the wiki's Categories and could cause confusion. That's why I prefixed it with "MM". If you have a better alternative, please suggest.

Additional columns
I added some columns: MM category, Volume, Level (nominal heroic normal quest level) and Pack (need-to-buy adventure pack or free-to-play). The former two were already available right before each table, so adding them to each table makes little sense, until you join all the tables together to form one single table. This one table is sortable, that is, you can click on the headers in several ways and rearrange the table on the fly, the way you need it. Here are some use cases, consider them as starting ideas.
 * I am hunting every Rust Monster in the game. What's the next one I'm missing? Sort by MM kind, plus maybe Name if I'm feeling systematic.
 * Oh, good, I've slain Blight in The Sunken Sewer. Since I'm already here, what else can I find here? Sort by Habitat, plus maybe MM category + MM kind + Name if I'm feeling systematic.
 * By the way, there's Ruin (spider) over there, also in The Sunken Sewer, and the link color tells me its page doesn't exist. I'll write it. And shoot a picture.
 * Say, I've noticed both Slyssaris and Warlock Slyssaris are listed in The Sunken Sewer. Chances are they're actually the same monster and one of the entries should be struck from DDO wiki. Let's find him and check what the focus orb calls him, we'll strike the other one.
 * Just out of curiousity, how many kinds of Player Races are there in the monster manual? Sort by MM category + MM kind.
 * Blast, now that I've lost my VIP status (Turbine account, not DDO wiki), I'm a Premium player, and I have also lost access to Monster Manual Volumes after Volume I. What monsters *can* I hunt now? Sort by Volume.
 * Uh, as a Premium player, I also have to pay for adventure packs. OK, I'll buy The Vale of Twilight. What monsters can I hunt in The Vale of Twilight content and in Free To Play content? Sort by Volume + Pack (or Pack + Volume, as preferred).
 * OK, I'm a VIP again, so I've regained access to all my previous monsters. Now I want to take it easy with my level 28 character, I want to hunt lowest-level monsters first. Sort by Level (which admittedly is quest level, not monster level, but you're unlikely to find level 22 monsters in a level 3 quest anyway).

Ordering
The presentation order of the columns: I shifted the monster name to the third position, so now you have MM category, then MM kind, then Name, which is just the (user interface-enforced) order you must follow when accessing a certain monster in the in-game Monster Manual window. Open to argument, anyway.

What's next?
Now the hard part: I'll try semi-automatic compilation from single-monster pages.

Update: even better, it looks like fully automatic compilation is possible and relatively easy, certainly much easier than I initially thought.

The table itself
For testing purposes, rows are just a subset of the original table (with my modifications).

'WARNING! You're in my sandbox. This is *not* the Mm export, it's just an experiment. You are advised *not* to rely on the data you find here, which I could purposefully alter (even making it wrong) in order to experiment with formatting, coding and other wikiful things.'

Legend
 * MM category: taxon of the first taxonomic rank you find when accessing this monster in the in-game Monster Manual window; mostly equivalent to D&D creature type
 * MM kind: taxon of the second taxonomic rank etc.; mostly equivalent to D&D creature race, type+subtype or specific subset
 * Name: identifies this monster either as a generic creature belonging to a most specific subset of its kind or a unique, named creature
 * Habitat: where you can find this monster; usually one or more Quests, Wilderness adventure areas and/or hostile public areas
 * Level: as far as applicable, nominal level of this monster's habitat when played at heroic normal difficulty
 * Pack: either Free To Play or the Adventure Pack you need to buy in order to access this monster's habitat
 * Volume: which Monster Manual Volume this monster kind is listed in (currently P for Prologue, 1 for Vol. I, 2 for Vol. II, 3 for Vol. III)
 * Monster Manual: (to do)

'WARNING! You're in my sandbox. This is *not* the Mm export, it's just an experiment. You are advised *not* to rely on the data you find here, which I could purposefully alter (even making it wrong) in order to experiment with formatting, coding and other wikiful things.'

Test section lst - please ignore
test section 1 should follow:

MM type section should follow:

test section 2 should follow:

Monster Manual table (dpl-generated): current state
|uses          = Template:Infobox-monster The uses parameter constrains page selection to those using the appropriate template, in this case Template:Infobox-monster; this is likely redundant, given the include parameter's behaviour.

|category      = Troglodyte race monsters The category parameter constrains page selection to those belonging to the appropriate categories, in this case Category:Troglodyte race monsters (to limit server load during tests).

|category      = Fiendish Troglodyte sub-race monsters Idem; makes the previous category parameter redundant, but I want to limit the page selection even more since I'm starting tests that are potentially heavy CPU-wise (don't think so, but you can never be too prudent); keep this and you're expecting twelve-ish records, strike this to see fifty-ish.

|addpagecounter = true The addpagecounter and addpagesize parameters add the corresponding page metadata to each record's available output fields; it does *not* add them to the corresponding final output row; useless to the monster manual: I only included them here to test the feature for future reference.
 * addpagesize   = true

|include       = {infobox-monster}:type:MM type:%PAGE%:habitat:MM type The include parameter, with those subparameters, adds the corresponding page data (extracted from the specified template data in each page) and metadata to each record's *and* row's output fields; the second MM type field will be transformed later.

|format        = ,,¶¦Static data 1¶¦%COUNT%¶¦Static data 2¶¦%SIZE%, The format parameter, with those subparameters, adds the corresponding static data (mostly pointless, but it can have its uses in limited cases: I only included them here to test the feature for future reference) and metadata to each final output row's *rightmost* output fields; this, being specified in the third subparameter, will not be overridden by the table parameter.

|table         = class="wikitable sortable",-,Category,MM kind,Name,Habitat,Volume,Static header 1,Count,Static header 2,Size The table parameter, with those subparameters, sets up a sortable wikitable with the appropriate column headers; overrides the format parameter except for its third subparameter; columns' amount and order is defined (here) by the include and format parameters; article title (default first column) is skipped in order to have it in the third column.

|tablerow      = %%,%%,%%,%%,align="center"¦²{User:Aldyron/Sandbox/Template Mm kind to volume¦%%}²,%%,align="center" data-sort-type="number"¦%%,%%,align="center" data-sort-type="number"¦%% The tablerow parameter, with those subparameters, uses a template to map kind to volume and specifies formats (arguably) appropriate for each column.

Test section diagnostics
I used to make lots of mistakes; so, in order to catch my own mistakes, I've become a bit of a consistency nazi. The following sortable table should make it easy to identify monsters in need of some tidying-up for consistent properties, both individually and as part of a database. Currently limited to Category:Troglodyte race monsters for testing purposes.