Year of the Dragon: Through May 28th, claim free Expansion Pack (excluding Vecna Unleashed) or a Greater Elixir of Discovery! Speak to Xatheral in the Hall of Heroes.edit

Game mechanicsNewbie guideIn developmentDDO StoreSocial Media


ChallengesClassesCollectablesCraftingEnhancementsEpic DestiniesFavorFeats

GlossaryItemsMapsMonstersPlacesQuestsRacesReincarnationSkillsSpells


Please create an account or log in to build a reputation and unlock more editing privileges, and then visit DDO wiki's IRC Chat/Discord if you need any help!

Template talk:Monsters in quest

From DDO wiki
Jump to navigation Jump to search

Table style[edit]

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 Done
  2. split type and race columns so that column sorting can work Done
  3. eliminate the text Type and Race from data rows Done
  4. get rid of width 90% and just align left

Here's a quick mockup. --Cru121 (ContribsMessage) 04:42, May 22, 2017 (EDT)

Monsters
Name CR Type Race
Air Mephit Warrior (view) ♦14 ♠17 ●♦17 Type: Air Outsider Race: Mephit
Ice Mephit Warrior (view) ♦14 ♠17 ●♦17 Type: Air Outsider Race: Mephit
  • 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 • Message) 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 (ContribsMessage) 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.  👟 ShoeMaker (Contribs • Message) 👟 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 (ContribsMessage) 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?  👟 ShoeMaker (Contribs • Message) 👟 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 (ContribsMessage) 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.  👟 ShoeMaker (Contribs • Message) 👟 13:35, June 30, 2017 (EDT)

Quest monster table expanded or collapsed by default?[edit]

Support an option

Description

See #Table style section directly above for description and to add comments or add your comment in your |support_#_#= below.

Expanded by default

  1. -LrdSlvrhnd (ContribsMessage) 00:14, June 30, 2017 (EDT)
  2.  👟 ShoeMaker (Contribs • Message) 👟 09:32, June 30, 2017 (EDT)
  3. Saekee (Contribs • Message• DDO forums) 07-11-2017, 09:58 AM (EDT)
  4. YUTANG75 - 07-11-2017, 10:58 AM (EDT)
  5. EllisDee37 (Contribs • Message• DDO forums) 07-11-2017, 02:01 PM (EDT)
  6. Enoach - 07-11-2017, 03:32 PM (EDT)
  7. JonD - 07-11-2017, 05:22 PM (EDT)
  8. gnarledmaw - 07-12-2017, 01:31 AM (EDT)
  9. C-Dog (Contribs • Message• DDO forums) - 07-11-2017, 09:21 PM (EDT)

Collapsed by default

  1. --Cru121 (ContribsMessage) 04:42, May 22, 2017 (EDT)
  2. Gargoyle69 - 07-11-2017, 06:02 PM (EDT)

Summary

  • Option #1, Expanded by default, has an 81.82% support.
  • Option #2, Collapsed by default, has an 18.18% support.

Supporting hcrN field[edit]

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 {Monster/sandbox2¦Habitat phantom/sandbox}, which I don't understand.

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

Nom (ContribsMessage) 10:42, March 9, 2021 (EST)

OK, I found [this page] which helps enormously. Nom (ContribsMessage) 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 Kobold sneak (Contribs • Message) 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 Technical_13 (Contribs • Message) may not understand and then break. Faltout (ContribsMessage) 19:02, March 9, 2021 (EST)

Implementation[edit]

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;"|
{{#forargs: habitat
| key_index
| key_val
|
  {{#ifeq: {{#var:key_val}}
  | {{SUBPAGENAME}}
  | {{#vardefine:out_cr|
      {{{ hcr{{#var:key_index}}|
        {{{cr|{{Edit|{{{%TITLE%}}}|CRs missing!}} }}}
      }}}
    }}
  }}
}}{{#var:out_cr}}

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 {{{%TITLE%}}} could be %TITLE%

See example code on User:Nom/sandbox/autoextract

Nom (ContribsMessage) 01:22, March 15, 2021 (EDT)

The following is a little cleaner:

style="text-align: center;"|
{{#forargs: habitat
| key_index
| key_val
|
  {{#ifeq: {{#var:key_val}}
  | {{SUBPAGENAME}}
  | {{#vardefine:out_cr|{{{ hcr{{#var:key_index}}|}}} }}
  }}
}}{{#var:out_cr|
  {{{cr|
    {{Edit|{{{%TITLE%}}}|CRs missing!}}
  }}}
}}

"#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.

Nom (ContribsMessage) 01:30, March 15, 2021 (EDT)

  • Note on the code: You need to check if hcrX is actually empty with an #if function. {{#if: {{{hcr{{#var:key_index}}|}}} | {{{hcr}}} | {{{cr ...}}} }} Faltout (ContribsMessage) 09:55, March 17, 2021 (EDT)
    • I don't think so. The '|' operator in the hcrN dereference returns its contents (i.e. empty string) if hcrN is not defined. #vardefine doesn't define the variable if the body resolves to empty string (after removing whitespace). So if hcrN is not defined, then out_cr remains undefined. I might have missed something, but I've tried to minimise unnecessary use of parser functions in order to maximise maintainability. Nom (ContribsMessage) 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. Faltout (ContribsMessage) 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. Nom (ContribsMessage) 00:56, April 3, 2021 (EDT)

{{User:Nom/sandbox/autoextract/Template:Monster quest phantom|habitat1=Monsters in quest|hcr1=<!--empty-->|cr=15}} vs.
{{User:Nom/sandbox/autoextract/Template:Monster quest phantom|habitat1=Monsters in quest|cr=15}}

First test: %TITLE% |

| ? | ?

Second test: %TITLE% | 15 | ? | ?

Do you see that one displays the cr while the other does not? Now if you replace {{{ hcr{{#var:key_index}}|{{{cr|}}} }}} with the code I provided above, then both will display the default cr when hcr1 is empty OR undefined. Faltout (ContribsMessage) 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. Nom (ContribsMessage) 08:11, April 3, 2021 (EDT)

Updated Implementation[edit]

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:

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.

Nom (ContribsMessage) 08:11, April 3, 2021 (EDT)