Template talk:Monsters in quest

Table style
I understand that different readers have different preferences about how to display information. Here's my proposal:
 * 1) make the monster table collapsed by default ✅
 * 2) split type and race columns so that column sorting can work ✅
 * 3) eliminate the text Type and Race from data rows ✅
 * 4) get rid of width 90% and just align left

Here's a quick mockup. -- Cru121 (Contribs • Message • Email ) 04:42, May 22, 2017 (EDT)


 * I don't mind adding some classes to the table to make it collapsed by default with an option to override that in user common css. I don't mind splitting those columns or replacing them with a single MM Type column.  I want to remove the Type:/Race: text.  I'm opposed to removing the set width and alignment as I was all of the tables to be consistent from page to page, but I would be willing make it flat out 100% width.  I'd also like to add a column to the table for the hnote## for the current quest.  Thoughts? ShoeMaker (Contribs&thinsp;•&thinsp;Message&thinsp;•&thinsp;Email ) 11:26, May 22, 2017 (EDT)
 * Three out of four is a great success :) TY --Cru121
 * Can we get the "Expand" link at the beginning of the line instead of the end? It's apparently been a month and I've only just now noticed that it's there, and have been assuming that stuff just hasn't been finished yet.  If it looked like it did on this page, with just "Monsters" and then "Expand" it'd be cool, but with having the top line of the table (Name, CR, etc.) showing, it'd be a lot more obvious at the beginning. - LrdSlvrhnd (Contribs • Message • Email ) 00:14, June 30, 2017 (EDT)
 * It's something that's part of the core CSS for MediaWiki itself. It would take A LOT of work to move it; although, it is possible to have it not collapsed by default or change other parts of it.  &#x1f45f;&thinsp;ShoeMaker (Contribs&thinsp;•&thinsp;Message&thinsp;•&thinsp;Email )&thinsp;&#x1f45f; 00:24, June 30, 2017 (EDT)
 * Bah, that's annoying. I'm guessing it's also not possible make it so it collapses the whole thing, including the upper row, or something similar?  IMHO, I don't think it's really all that necessary to have it collapsed by default otherwise; the wiki should be easily accessible for everyone, not just "those in the know" and/or observant.  Alternatively, can we make a note, either after the Monsters header (without actually being part of the header) or just under (or really, under the table), to "Expand list if desired"? - LrdSlvrhnd (Contribs • Message • Email ) 01:15, June 30, 2017 (EDT)
 * Well I personally find the monster list useless. But if most users find it interesting, I guess we should get rid of the collapsible part :( Anyway, I googled around and found this, not sure if it can help. --Cru121
 * I guess it's something I'd like to get more feedback on. I personally like to have it expanded.  Just as easy as it is to have it collapsed by default and expanded for certain users is it to have it expanded by default and collapsed for certain users.  Can someone ask for feedback on the forums, please, on whether people like it collapsed or not by default and indicated that whichever it is, logged in users can have it the other way if they choose with a little custom code.  I'm thinking that I'll make the custom code a gadget people can opt-in or opt-out of.  Thoughts? Feedback?  &#x1f45f;&thinsp;ShoeMaker (Contribs&thinsp;•&thinsp;Message&thinsp;•&thinsp;Email )&thinsp;&#x1f45f; 09:32, June 30, 2017 (EDT)
 * I'd prefer to have it expanded by default, also. My memory is shoddy enough that I often look at the monsters just to see if I need to make sure to have anything special, especially if it's a quest I haven't run much/in a while. - LrdSlvrhnd (Contribs • Message • Email ) 13:05, June 30, 2017 (EDT)
 * Has anyone asked for feedback on this topic on the forums yet? I'd love to get some feedback for what non-registered readers think so I can base the default on that and then write the script to change the default behavior for registered users as that's the best way to go about it.  &#x1f45f;&thinsp;ShoeMaker (Contribs&thinsp;•&thinsp;Message&thinsp;•&thinsp;Email )&thinsp;&#x1f45f; 13:35, June 30, 2017 (EDT)
 * Asked in -- DDOstream (Contribs • Message • Email ) 08:36, July 11, 2017 (EDT)
 * Cross posted to in .  &#x1f45f;&thinsp;ShoeMaker (Contribs&thinsp;•&thinsp;Message&thinsp;•&thinsp;Email )&thinsp;&#x1f45f; 11:27, July 11, 2017 (EDT)

Supporting hcrN field
Many monsters have the same base monster (same graphic, same MM, etc) but different CR in different quests, but are similar enough that it's inefficient to treat them as distinct monster entries.

I was hoping to modify the extraction template so that it can pull out first hcrN fields (where N matches habitatN) and then cr. However, in understanding the DPL I'm stuck on the 'include' line.


 * includematch: picks the instances to include
 * table: sets the column headings and the general table format
 * include: I was expecting to see a list of field names (as per Gamepedia help for DPL3 extension, table - spam filter prevents me linking to the DPL3 documentation directly), but instead it references, which I don't understand.

Any guidance, or is the DPL code hairy enough as it is?

&rArr; Nom (Contribs • Message • Email ) 10:42, March 9, 2021 (EST)

OK, I found [this page] which helps enormously. &rArr; Nom (Contribs • Message • Email ) 10:54, March 9, 2021 (EST)


 * Getting the monster CRs right was one of my first serious edits in the wiki years ago, the reason I got into DPL and templates and the reason I realized the futility of using logical arguments with the current administration (Talk:CR and color of monsters for each quest). The way I see it now is that attempting this change is pointless. Especially when most of the monsters do not have different CRs. The solution I've been applying so far is to make 2 different entries for the monster in the same page. I've already adjusted this template so that it only selects the template call that contains the correct habitat (that's what the "includematch" is about as you correctly noted). Another reason for this is that in 2016, the bot was unleashed on the monster pages to merge the CRs and of course it deleted a lot of monster CRs. So I would recommend to avoid doing something weird that  may not understand and then break. &rArr; Faltout (Contribs • Message • Email ) 19:02, March 9, 2021 (EST)

Implementation
Figured out how to do this. It's not easy (mostly because it's really difficult to pass parameters between templates), but it will work nicely for our purposes.

Replace the CR code in Template:Habitat phantom/sandbox with the following: style="text-align: center;"|

This code will search a matching habitat entry, and when it finds one will set out_cr to either the matching hcrN value or to the cr or to 'CRs missing'. It will return undefined output if there is no 'habitat' field, but that shouldn't happen.

Questions:
 * why does this template use a 'sandbox' phantom filter?
 * I believe could be %TITLE%

See example code on User:Nom/sandbox/autoextract

&rArr; Nom (Contribs • Message • Email ) 01:22, March 15, 2021 (EDT)

The following is a little cleaner: style="text-align: center;"|

"#vardefine" of empty string is a null definition, so this allows us to defer all error case handling the the end, resulting in an easier to understand function.

&rArr; Nom (Contribs • Message • Email ) 01:30, March 15, 2021 (EDT)
 * Note on the code: You need to check if hcrX is actually empty with an #if function.   &rArr; Faltout (Contribs • Message • Email ) 09:55, March 17, 2021 (EDT)
 * I don't think so. The '|' operator in the   dereference returns its contents (i.e. empty string ) if   is not defined.  #vardefine doesn't define the variable if the body resolves to empty string (after removing whitespace).  So if   is not defined, then   remains undefined.  I might have missed something, but I've tried to minimise unnecessary use of parser functions in order to maximise maintainability. &rArr; Nom (Contribs • Message • Email ) 23:40, March 17, 2021 (EDT)
 * The keyword being "undefined". If it exists but is left empty, then you have a problem. A reason for them appearing empty is people copy-pasting the templates from working pages and removing the extra values. And this has led to quite a few errors in the protected templates and we don't have someone dedicated to removing empty parameters. That's why in my coding I always use the #if to check for empty value instead. &rArr; Faltout (Contribs • Message • Email ) 08:08, March 18, 2021 (EDT)
 * I've run test code, and undefined in this context includes empty strings and/or strings containing only whitespace. As far as I can tell, your test code above is a no-op. &rArr; Nom (Contribs • Message • Email ) 00:56, April 3, 2021 (EDT)

vs.

First test:

Second test:

Do you see that one displays the cr while the other does not? Now if you replace  with the code I provided above, then both will display the default cr when hcr1 is empty OR undefined. &rArr; Faltout (Contribs • Message • Email ) 03:26, April 3, 2021 (EDT)

I see it now. It's actually because I forgot to put | on the end of the template parameter dereference to handle the undefined case. I thought I had tested that but must have missed it in the copy. &rArr; Nom (Contribs • Message • Email ) 08:11, April 3, 2021 (EDT)

Updated Implementation
I got annoyed with Template:Monsters in quest not showing the 'slayer' category for wilderness areas with slayer quests. So, to kill two birds with one stone:
 * Created Template:Monsters in quest with slayer (plus related infrastructure). This works mostly identically to Template:Monsters in quest, but also reads off the 'hslayN' field (see Template:Habitat slayer phantom) and adds a column for that field (see Template:Monsters in quest with slayer).
 * Added code in new template to support both 'hcrN' and 'hslayN'.
 * While doing this I figured out how to reproduce Faltout's bug (above), and fixed the evaluation code for 'hcrN' to handle the empty case correctly.
 * Updated The Storm Horns to use the new code:
 * Updated to use Template:Monsters in quest with slayer
 * Updated The Storm Horns to include this category link.
 * Updated most of the monsters with habitat == The Storm Horns to have a 'hslayN' entry.
 * Fixed pagename calculations to correctly handle being included as part of a 'Category:Monsters in ...' entry.

Known issues:
 * Cell vertical spacing is not minimal. I'd rather not compress everything onto a single line of code (because that makes both editing and change tracking very difficult).
 * Missing 'slay' field generates a warning (deliberate - same as missing CR warning), but this means that creatures that are not part of a slayer group need an explicit '-' or 'None' entry to keep the script happy.

Use the updated code when updating original Template:Habitat phantom.

&rArr; Nom (Contribs • Message • Email ) 08:11, April 3, 2021 (EDT)