Template talk:Drops table row

Qualifiers

Template doesn't recognize items with qualifiers, such as Hoof (16 copper) on the Veteran Crazed Harathi Trampler page. —Ventriloquist 23:55, 10 February 2017 (UTC)

It also needs an option to add rarity for items that can drop that are either rare or masterwork but have one page such as Charred Back Warmer. - Do_odleplex 00:01, 11 February 2017 (UTC)

You can now add one of these items by adding #item1 or |rarity=Rare to the name, it will then render properly, example:

{{Drops table header|show-levels=n}}
{{Drops table row|Charred Back Warmer#item1}}
{{Drops table row|Charred Back Warmer|rarity=Rare}}
|}

Name	Type	Rarity	Quantity
Charred Back Warmer	Back item	DMasterwork	1
Charred Back Warmer	Back item	ERare	1

The first example links to the subobject as well, but changing the item link via rarity param would require the template to check if the rarity param is set and subobjects exist beforehand. I don't think this is necessary, so this is my current solution for this. —Nefastu 00:02, 15 February 2017 (UTC)

Lovely, thanks again! - Do_odleplex 00:41, 15 February 2017 (UTC)

Rarity stuff again

More item rarity shenanigans, but specifically related to champ bags. If there's more than one type of an exotic champ bag(specifically: Deluxe Gear Box, Elaborate Ritualist Bag, Embroidered Belt Pouch, Embroidered Coin Purse, Embroidered Saddlebag, Fallen Adventurer's Backpack, Gilded Strongbox, Heirloom Seed Pouch, Oversized Rucksack or Shell Pouch) it goes a little nuts:

Name	Type	Rarity	Quantity
Gilded Strongbox	Container	FExotic	1

But if you do the #item5 it does this:

Name	Type	Rarity	Quantity
Gilded Strongbox	Container	FExotic	1

And unfortunately, that's not a shield. =< - Do_odleplex 18:47, 17 February 2017 (UTC)

For multiple same rarity values I can add a bit to the template to ignore additional entries of the same type. For the shield issue: that is something that is buried in other templates. I can put in an override parameter so one can simply do |type=Container, but I will look at the other templates in a few hours again if it is easily fixable so it will automatically create the correct values. —Nefastu 19:11, 17 February 2017 (UTC)

If you can set it up so the first thing you said works, I'd think that would probably be all that's needed. Reason being, if it's set up like that so that the champ bags only list one, then I don't have to use the item number, and the item number would just be used for dungeon bosses' loot where there are only two items. - Do_odleplex 19:19, 17 February 2017 (UTC)

Looks like it works now. I've added a new talk section over at {{Item variant table row}} to know more about why Shield is the default value for subobjects. You can, however, select a specific rarity by |rarity=xyz now without having to worry about multiple rarity entries. —Nefastu 02:03, 18 February 2017 (UTC)

Lovely, thank you! - Do_odleplex 02:07, 18 February 2017 (UTC)

I've updated {{Item variant table row}}, since there were no replies. It looks like item types of subobjects are now correctly created. —Nefastu 14:11, 27 February 2017 (UTC)

Quantity centred?

Would it not look better if the Quantity column figures were centred? (currently default to left-aligned) --Wolfie (talk|contribs) 23:09, 19 February 2017 (UTC)

Agreed. —Ventriloquist 23:11, 19 February 2017 (UTC)

Text length

Is it possible to have a defined length for event titles(or some of the longer collection titles) so they wrap around and don't stretch the table out? - Do_odleplex 23:09, 25 March 2017 (UTC)

I added a width parameter to the header template, so you can now add something like |width=y (defaults to 250px) or |witdh=1234 to prevent table stretching. —Nefastu 01:03, 26 March 2017 (UTC)

Can we make the text collapsible? People can expand it if they really need to know the requirement.--Relyk ~ talk < 01:23, 26 March 2017 (UTC)

Sure we can. Now the question is: remove the parameter and use the collapsed variant for all event/collection items? —Nefastu 14:20, 26 March 2017 (UTC)

Would it be considered heresy if we just let the text wrap?--Relyk ~ talk < 14:47, 26 March 2017 (UTC)

Template update

This template is sorely in need of an update. It has useful parameters such as location, event, and collection, but they are not saved as properties to be able to be accessed later by {{dropped by}}. I propose adding subobjects to this template to hold these useful information. --BuffsEverywhere (talk) 07:49, 22 September 2021 (UTC)

Yes.

Regarding technical details:

• Can we reuse any properties from for example rewards item template or should we create new? Probably new ones.
• This template uses the parameter rarity to get an item variant. Should we store the rarity too, or should we just store the id related to the rarity (i.e. store general item name, store dropped item id, comparable to rewards item template). Rarity is kinda vague, I prefer exact ids.

For example:

{{#subobject: item{{#var:counter}}
| Drops item = <item>
| Dropped by = <NPC>
| Has dropped item id = <item id based on {{{id|}}} or {{{rarity|}}}>
| Has dropped item chance = <chance> <!-- Needed? -->
| Has dropped item quantity = <quanity>
| Has level requirement = <level>
| Located in = <location>
| Is dropped during event = <event>
| Is dropped during collection = <collection>
}}

Overall quite straight forward, but the parameter rarity makes it a little bit tricky. --Tolkyria (talk) 08:52, 22 September 2021 (UTC)

Is the rarity parameter actually needed? While it may be more work to look up the specific id vs. specifiying a rarity it would be more accurate for containers with mulitple exotic variants e.g. Embroidered Coin Purse#Variants. Seems like an ID/subobject is generally a better fit. —Kvothe (talk) 12:20, 22 September 2021 (UTC)

I would think that the ID would be much more useful especially in the case of items like the Gilded Strongbox with massive amounts of variants. Otherwise, would drop chance be similar to Template:Rewarded by in it being either "possible" or "guaranteed" or would it be a percentage? Sunlion (talk) 12:36, 22 September 2021 (UTC)

Exactly, Kvothe and Sunlion. But for me the problem is that the rarity parameter is used ~500 times (in total ~8000 usages on ~2000 pages), so too much to just ignore it but also a little bit too much to get rid of it easily. Thus, no idea yet how to deal with the rarity parameter properly.

I doubt that we can get reasonable precentages anyways, so it would be just a "possible" or "guaranteed", if that even makes sense here. --Tolkyria (talk) 12:52, 22 September 2021 (UTC)

Bots most likely wouldn't work, so it'd have to be case-by-case. Possibly we could include the rarity parameter as basically being deprecated with functionality remaining while we work on fixing them? And that sounds good for the chance param. I would set "possible" to default, since most items would be like that with possibly a few legendary achievement items as exceptions. Sunlion (talk) 12:58, 22 September 2021 (UTC)

One other thing: possibly we could take a look at Template:Drop query table to see if there's anything we could salvage from that? Sunlion (talk) 13:06, 22 September 2021 (UTC)

I think we should not support the rarity parameter. Sunlion already replaced a bunch with the id parameter, and I think we should continue getting rid of it.

Drop table is actually a query template and not a storage template. I've since moved it so it's less confusing.

I suggest the following property names: Is dropped during event and Is dropped during collection. I don't see any reason not to reuse Located in; we use it for vendor subobject locations too. --BuffsEverywhere (talk) 05:25, 23 September 2021 (UTC)

Sounds very good. The default level is already called in the header, we just need to add the default location there too. What about inheriting them with a #var from the infobox instead of calling it with #show? In the drops table row we could support multiple location separated with ";" (using #arraymap) instead only one as we currently do, however not sure where and if we need this. --Tolkyria (talk) 08:09, 23 September 2021 (UTC)

I'm not a fan of cross-template vars because it's a pain to track down where they are defined/used if updates need to be made. I don't know where we would need multiple locations but I suppose it can't hurt to have it just in case. --BuffsEverywhere (talk) 09:30, 23 September 2021 (UTC)

As you like. Offtopic: But to be precise that's not true anymore. Have you tried an insource: "#var:<variable name>" search yet? The current search can't be compared to the old one, so fast, so exact, so powerful, for example try this. --Tolkyria (talk) 10:12, 23 September 2021 (UTC)

(Reset indent) The SMW storage type has been shifted from a page-stored property to a SMW subobject by BuffsEverywhere. This way we are storing:

• the specific NPC level for this dropped item rather than using the global NPC level from the infobox (much more accurate)
• same with the specific location
• possible event or collection involvement

I minimally adjusted the query template Dropped by to maintain the previous functionality, still missing are:

• Displaying collection/event in the query template Dropped by
• Dealing with the properties based on the parameter status in query template Dropped by, i.e. mostly "historical".
• What to do with item drop chance possible or guaranteed?
• Adjust the general query template Drop query table.
• Edit: Deal with the parameter rarity by removing and replacing it with an exact item id. See this parameter check (don't forget to change the offset to 500, 1000 and 1500 to view all 1996 pages).

Furthermore, I marked the template Drops as depracted, it was only used by 13 pages which we replaced with the Drops table row template. Since it simply stores only Drops item, the results in Dropped by would be incomplete now, overall I think that we should not keep using the template Drops. --Tolkyria (talk) 23:04, 24 September 2021 (UTC)

• Oof, that's a lot of pages with the rarity parameter. I could add support for it again, because it makes editing easier and in most cases it doesn't matter which exact exotic variant is dropped (for example).
• Should Dropped by display the collection/events in their own column or in the first column like this template? I'm leaning toward copying this template.
• I think a note should be displayed if a drop is guaranteed.
• There's an issue with Dropped by showing duplicate rows if an npc drops multiple variants, see Charred Back Warmer.
• Wow, that search keyword is really cool! I'll keep it in mind. --BuffsEverywhere (talk) 06:45, 25 September 2021 (UTC)

Which id do you want to select when the rarity parameter is set, especially if there are more than one? For me this parameter cannot consistenly provide any valid information. Okay, the duplicate results were suppressed before our changes, now due the subobject storing the appear twice; however after introducing and storing the ids there we could show the rarity. Otherwise, we could suppress it by adding:
{{#ifeq: {{#var:last_NPC}}|{{{<!-- NPC result format parameter-->|}}}|<!-- do not show -->|<!-- show -->{{#vardefine:last_NPC|{{{<!-- NPC result format parameter-->|}}}}}[..]}}.

Displaying additional information below should be fine, at least it's less work as it can be done on the fly and needs no check before.

Not sure about the guaranteed yet, do we have examples where we actually need it? --Tolkyria (talk) 08:27, 27 September 2021 (UTC)

That's true if there are multiple variants with the same rarity. However, there are some items which simply have one of each rarity and that is where the rarity parameter would be handy. And it would reduce the tedious need to completely eliminate the rarity parameter.

I think suppressing the duplicate row is the better option because this case is pretty rare so showing the rarity is not useful most of the time.

I think being able to show guaranteed/chance is useful for collection items. --BuffsEverywhere (talk) 11:09, 13 October 2021 (UTC)