Template talk:SDRH

We could put in a fixed width parameter for each column so people don't have to wrap the labels with br tags.--Relyk 04:16, 19 November 2012 (UTC)

I tried using percentages based on some sample values, but it sucked. Setting a fixed column width could work, but would only be needed if you have the labels displaying. If you tell me what width I can code it k. --Chieftain Alex 08:11, 19 November 2012 (UTC)

Sandbox talk

→ moved from User talk:Chieftain Alex/sandbox

So, I've been fucking about with this for a while... and eventually I've whittled it down to three templates, namely Template:Drop rate header‎, Template:Drop rate footer and /line. The first two could be used across all the templates, while the last one would have to be set up for each drop rate table. The key advantages are having totals and percentage statistics generated automatically. (Additionally, the lines are labelled clearly). Thoughts anyone?--Chieftain Alex 23:29, 6 November 2012 (UTC)

{{Drop rate header‎|Item 1|Item 2|Item 3|Item N}}
{{/line|~~~|i1=|i2=|i3=|iN=}}
{{Drop rate footer}}

With the columns being numbered possibly. Named parameters for the line would be an advantage even without calculating the total dynamically. The full name of the item is defined in the header, so using it as the parameter isn't much more useful when it'll inflate the line length.--Relyk 00:18, 7 November 2012 (UTC)

The name of the item in the header doesn't have to match the name used on the /line template, it could be anything but should be descriptive imo (e.g. instead of "Black Lion Salvage Kit" we could have "salvage").

(If you mean that the parameters could be numbered instead of any text, then I'd disagree with that.. when I fill in /drop rate stuff that doesn't have named parameters, I'm always scrolling back and forth between the edit pane and the preview)

I have however fixed it such that the footer doesn't require any inputs at all, thanks for that idea. --Chieftain Alex 07:54, 7 November 2012 (UTC)

Ahh i see why you did it, you won't likely be using every single parameter so it stays short. I was concerned with the lines wrapping because you have too many lengthy item names.--Relyk 11:46, 7 November 2012 (UTC)

I stole some more ideas from you, namely shortening all the internal variable names for images and links to 2 characters to make them quicker to type :P --Chieftain Alex 23:44, 7 November 2012 (UTC)

Opinions

→ moved from User talk:Chieftain Alex/sandbox

Things I'd like to get some feedback on: a) Would this be worth adding to the mainspace templates? b) If so, would a text description of the item be necessary too? (and what size is the smallest I can get away with w.o making it ugly?) --Chieftain Alex 22:23, 16 November 2012 (UTC)

This would certainly be a useful and easier way to handle drop rate tables, especially when not all of the possible items are known. When a user line doesn't include the item name at all, it defaults to zero, right? What happens if someone enters an item that doesn't exist in the SDRH? Is there a reason for the pictures to be so small? The names above the icons are important, I think. It just needs room for ~15 characters per line of text. Manifold 23:26, 16 November 2012 (UTC)

The line template already has the answer to both questions :P The icons have mouseover text and you'll see the item names in the edit window so I don't think the text is necessary.--Relyk 23:39, 16 November 2012 (UTC)

I do think that the text would be a good idea, so I'll try and add a line beneath the icons for labels. --Chieftain Alex 23:43, 16 November 2012 (UTC)

I came here to ask for text on both the header and the footer -- otherwise you have to memorize icons or mouseover or something. 75.37.23.222 20:47, 17 December 2012 (UTC)

There has been code supporting labels (identical on both header and footer) implemented for quite some time.. Chieftain Alex 21:12, 17 December 2012 (UTC)

Boilerplate

I still feel that having that template on every page is stating what should be the flaming obvious + any qqing by anet about inaccurate data is down to users incorrectly invoking this table for items with more than one reward >_>. Chieftain Alex 19:14, 24 December 2012 (UTC)

I don't see what's wrong with using it with multiple reward items, it's still giving you the chance to get any one item. We don't know how the loot tables work anyways.-- _talk 11:31, 28 December 2012 (UTC)

Packages

It would be really nice to be able to use this for packages, but some have at least 30 possible drops, including different amounts of the same item. I've saved a few hundred bags that are taking up dozens of inventory spaces, so is there any chance we can make this hold even more possible results, or even any given amount? Manifold 20:19, 27 December 2012 (UTC)

For packages like that, I would recommend that you only record drop rate data for the different items, not for quantities. The quantity determination is a separate RNG from the item selection. —Dr Ishmael 21:37, 27 December 2012 (UTC)

Does this look ok before I start doing other bags? Manifold 06:54, 28 December 2012 (UTC)

When it starts spanning off the page, I turn off labels and decrease the image size. Also, I'd really like to assume all the materials of the same level have equal chance to drop, which abbreviates the tables. But that would be cheating.-- _talk 11:29, 28 December 2012 (UTC)

That table looks fine to me. If it spans off the page, your resolution's too low. :P It might be true that all materials of the same tier and rarity have the same drop rate, but in my experience it's not always true, and the rates seem tailored toward the type of enemy that drops the package. Moldy bags, for example, seem to drop totems and bones a lot more often than they drop scales or venom sacs. —Dr Ishmael 15:51, 28 December 2012 (UTC)

1600x900 is by far too low lol; it looks fine when you zoom out! And you are right in all likelihood.-- _talk 22:07, 28 December 2012 (UTC)

Heavy Miner's Bag has 28 possible different items, not including coin. Manifold 00:54, 31 December 2012 (UTC)

I posted this once already so: If you need for whatever reason 30 unique items, you do the same as I did: [1] (minor error fixed in [2]) and [3] and [4].-- _talk 01:02, 31 December 2012 (UTC)

I think for bags and stuff like that we do need to adjust the header a bit so that it takes into account the number opened Anzenketh (talk) 00:40, 9 August 2013 (UTC)

Usage on dye pages

I'm thinking it would be useful to have an option to turn off the heading row, so it can be used on pages like Talk:Unidentified Gray Dye - where all the options have the same icons. (easily done, worth bothering?) Chieftain Alex 18:18, 20 January 2013 (UTC)

Lol. Just realised I'd have to move the variable setting bits back out of the header if I wanted to do that. sod the dye page. Chieftain Alex 18:20, 20 January 2013 (UTC)

Multiple tables

So I saw on the Mystic Clover/Drop rate Page that with two tables, the automatic totals won't work, is there an easy fix for this? Calvinthesneak 03:45, 9 February 2013 (UTC)

The template isn't designed for to be used multiple on a single page, so you shouldn't be doing so. If you want to know why, the variable that tracks the number of columns is defined for the first table and that value is being used in the later tables.--Relyk ~ talk > 04:33, 9 February 2013 (UTC)

I think I have it working, still testing as I build the dataset, might just be some undocumented functionality, I did have to play a bit with format Calvinthesneak 06:25, 9 February 2013 (UTC)

I mentioned this fairly recently. I honestly don't think multiple tables can be done, unless all of the drop rate variables were told to vary due to a reference in each row to which table, e.g. I could have Table1_DRvar_1 & Table2_DRvar_1 + they wouldn't interact. (Idk why its not working at the moment, its not as if I haven't got each variable being redefined as zero with the start of each new table. :( )-Chieftain Alex 21:20, 9 February 2013 (UTC)

If you coded better you wouldn't need the column count :D--Relyk ~ talk > 22:04, 9 February 2013 (UTC)

Without defining the variables as zero you can get some variables extension bugs kicking in. If I coded better, i'd write an extension to do Excel calcs on the wiki, but that will never happen. -Chieftain Alex 22:11, 9 February 2013 (UTC)

THe headers never had a problem with multiple, it was only the footers that were getting confused. The second footer I simply left a blank variable in it SRDF|. I don't know enough about wiki editing and formatting, but I spend a lot of time building databases and programs to display data. Seems odd that you can't just apply a name to each table, so it understands which table its referring to when you do a footer. 70.66.0.91 04:45, 10 February 2013 (UTC)

The variables used to store and access values are stored on the article. It's not a datable as much as the header defining 300 separate variables that the other two templates fortunately know the names of and can modify and retrieve their values. The separate tables are using the same set of variables to display information. That's why you can call {{SDRF}} again and it will generate a phantom footer. If you didn't use the same exact variable names, you would notice SDRF grabbing the values from the first table instead of the second one because SDRL only grabs the variable name defined, and other funny stuff even if the header and line templates are in agreement.--Relyk ~ talk > 05:59, 10 February 2013 (UTC)

I had two distinct tables there for a bit, with different variables and they were still performing correctly. The data on the tables was virtually useless though as all they did was really show what % of the time they got clover, and had no data about what tier 6 materials were retieved. I certainly had some issues with the footers for a bit till I started playing with the formatting for them. I'll chalk it up to dumb luck. 70.66.0.91 08:03, 10 February 2013 (UTC)

Manual Totals Option

Can someone add support for optionally specifying a manual amount of user entries for the drop table? This would be useful for the Black Lion Chest page, where automatic totals don't work, since you get multiple items per chest. Instead, users would have to specify the amount of chests opened, and that would be used in place of the automatically calculating total for the purposes of calculating the percentages. Psycho Robot (talk) 02:45, 25 November 2013 (UTC)

I guess it'd:

1. set a parameter at the top (SDRH) to trigger a variable like "manual mode"
2. wrap {{#vardefine:DRvar_total | {{#expr: {{#var:DRvar_total}} + {{#var:DRvar_count}} }} }} (SDRL) in an if statement to see if "manual mode" is on, and if so, do DRvar_total + manual total instead.

that might be all you'd have to do. -Chieftain Alex 10:13, 25 November 2013 (UTC)

{{SDRH
 | title = Icy Bag | class = mech1 | labels = yes | size = 50 | noheading = true
 | Almond | Bay Leaf | Carrot | Chocolate Bar | Green Bean | Kidney Bean | Onion | Orange
}}
{{User:Chieftain Alex/Template:SDRL| total = 1 | Almond = 0 | Bay Leaf = 0 | Carrot = 0 | Chocolate Bar = 1 | Green Bean = 0 | Kidney Bean = 0 | Onion = 0 | Orange = 0 | User A }}
{{User:Chieftain Alex/Template:SDRL| total = 8 | Almond = 2 | Bay Leaf = 1 | Carrot = 1 | Chocolate Bar = 2 | Green Bean = 1 | Kidney Bean = 10 | Onion = 3 | Orange = 2 | User B }}
{{User:Chieftain Alex/Template:SDRF}}

ok just the row template needed changing. The percentage bit doesn't help at all though in this case. Perhaps more helpful to show average amounts for a single opened item? (i.e. percentage/100 - e.g. 111% -> 1.1 on average) -Chieftain Alex 14:20, 25 November 2013 (UTC)

i've edited the above template, replacing SDRF with userspace version with new capabilities. Thoughts? -Chieftain Alex 14:36, 25 November 2013 (UTC)

It still takes ages to load, but I've applied the changes to the main templates and implemented them on Lost Orrian Jewelry Box/Drop rate. -Chieftain Alex 15:58, 25 November 2013 (UTC)

I think the percentages are still useful, since the line can be read as "you receive this item from x% of boxes you open" instead of "you have an x% chance to receive this when you open a box". That way there's no problem if it adds up to more than 100%. The amount per box is an interesting thought, but the lodestone note demonstrates an issue, in that the numbers in that line are going to be so small that they're going to be useless to the average person. I don't think that, in this case, a total like that can be useful. An alternative, perhaps, is to show the amount of boxes it takes to get one of those items, based on our data. That is to say, divide the total amount of boxes opened by the total amount of item x, and then round up. The issue with this is that its an average number, and you'll get people who will see that there's an average of 1k boxes to get 1 hair contract, and they'll open 1k boxes without getting one, and claim the data is wrong. Psycho Robot (talk) 16:29, 25 November 2013 (UTC)

I thought over 100% was just irksome. I was experimenting with *how many to get 1 item* in excel, but the results are just as wierd tbh. (100 boxes to get 1 mini seemed perfect to my mind, its a relief to me that the data isn't entirely junk after all.) -Chieftain Alex 16:43, 25 November 2013 (UTC)

Having totals be over 100% is a bit weird, but this wouldn't be a total. We'd just say "chance to receive" and then its no longer going to be totaled by anyone. Unless you're saying that one specific item had a chance over 100%? If that's the case, then it a matter of people having put the total in instead of the amount of times they received it. Its an interesting problem I suppose... On the one hand it'd be useful if people could just look at their inventory when its done and put in what they got, but on the other hand, that really screws with the probabilities of actually getting it. In the black lion chest the current data shows that getting 1 dye and 2 dyes is exactly the same, so we could multiply the data by 2/3 to get the amount of times that dyes were received. Ooh! What if we took the total amount of multi-items received, divided by the total number of boxes opened. That would get us an average amount of items received per opening. Then we divide that value by the total amount of multi-items received, and we'd get the total number of times any amount of that item was received. It'd be rather rough at first, but would get more and more accurate as the data volume increased. Psycho Robot (talk) 16:55, 25 November 2013 (UTC)

Wait hold on. I'm not sure I got the math right. If you have an average amount of an item received per incident, and the number of items received in total, how do you calcuate the number of incidents? Psycho Robot (talk) 16:59, 25 November 2013 (UTC)

(Reset indent) (Edit conflict) Just checking this.. If I open 2 boxes; one contains 1 of Item A, 3 of Item B; and the second box contains 3 of Item A and 2 of item C, what would you be expecting to record? For this template with manual counts the way I've implemented them, I'd be expecting to input

{{SDRL|~~~| Item A = 1 | Item B = 3 | Item C = 0 | total = 1 }}
{{SDRL|~~~| Item A = 3 | Item B = 0 | Item C = 2 | total = 1 }}
...
(this one is ultimately used to calculate average amount of A, B and C received each time)

I'm not totally sure that you were intending this, perhaps you were intending for a template which would be entered as

{{SDRL|~~~| Item A = 1 | Item B = 1 | Item C = 0 | total = 1 }}
{{SDRL|~~~| Item A = 1 | Item B = 0 | Item C = 1 | total = 1 }}
...
(this one is ultimately used to calculate the likelihood of each different item being received)

I think this might need clearing up before I do anything else with this template lol. --Chieftain Alex 17:06, 25 November 2013 (UTC)

I will elaborate with dyes since I know that getting 1 dye and getting 2 dyes is equally likely. So let's pretend that you opened up 1000 chests and you got 1 or 2 dyes 250 times. Under the current system you would have to count the number of times you received any amount of dyes, like a tally or something, because if you got 1 dye 125 times, and you got 2 dyes 125 times, that's a total of 375 dyes, and 375/1000 is 37.5%, significantly higher than the actual probability of receiving a dye, which is 25%. To fix that, we would first divide the total amount of dyes received (375) by the total amount of chests opened (250). That gives is 1.5 dyes per chest. Then we divide the total amount of dyes received (375) by the average dyes per chest (1.5) and we get 250. The exact amount of times dyes were received. There, I think I've got it! Math saves the day once more. Psycho Robot (talk) 17:14, 25 November 2013 (UTC)

It just hit me that this wouldn't work at all, I used 250 as the amount of chests opened in my calculations, but I said it was 1000 in the beginning. Damn yo I thought I was on to something. Oh well. Right now the only way someone could input the total amount of dyes they got and have it spit out the times they got any amount of dye would be if we figured out the average amount of dyes returned per incident beforehand. But if someone took the time to figure that out, then we could allow people to input the contents of their inventory instead of having to keep track of how many times they get it. In this case, that would mean that someone inputs that they received 375 dyes, and since we know that that's an average of 1.5 dyes per incident, the template would calculate that there were roughly 250 incidents of them getting dyes, and it would use that value to return 25% probability of them receiving dyes. That's something that I think would be worth it, since it would make it heaps easier to contribute research to the wiki. Psycho Robot (talk) 22:12, 25 November 2013 (UTC)

my stunned silence was to do with not knowing how to/not being able to automate any of the stuff you were so enthusiatically talking about ;)

the edits I've made today mean that users can record the changes that occur in their inventory rather than the number of occurances. --Chieftain Alex 22:24, 25 November 2013 (UTC)

Inability to automate what I was suggesting would probably be because it was actually impossible and nonsense. Anyways its great that people can just put in the content of their inventory, but I still think that not having percentages is a problem. Your percentage chance of getting drop x is a big part of why people care about drop logs. Putting the average amount of boxes needed to get drop x is a pretty good substitute, but its not perfect. Speaking of which, earlier you said that figuring out "how many to get 1 item" was returning weird results. What makes it weird exactly?

Anyways, in order to get percentages back into the drop tables, but keep allowing users to put in their inventory contents, rather than keeping track of individual drops, the only way that I can see to do it is to figure out the average amount of a certain item dropped per incident. This could be a secondary table of data which users could contribute to if they wanted to, and we would only need a relatively small sample size to get a clear picture. Something like, with swig of liquid karma from orrian boxes:

{{QDL|User A| 1 swig = 100 | 2 swigs = 50 | 3 swigs = 25 | 4 swigs = 10 }}

{{QDL|User B| 1 swig = 110 | 2 swigs = 55 | 3 swigs = 30 | 4 swigs = 15 }}

The math would then be figuring out the total amount of karma swigs received (685) and the total incidents of receiving karma (395) and dividing the two, to get an average of 1.734 swigs per incident. We can then go into the main table and divide the total amount of karma swigs received by this average, and it will give us an approximation of the amount of incidents of receiving swigs of karma, which would then allow us to put a percentage on the chance to receive swigs of karma from the boxes. I myself would volunteer to do a healthy amount of this logging on every bag/box that I could afford to do it on. But I can also see how it might just be more trouble than its worth. Psycho Robot (talk) 23:21, 25 November 2013 (UTC)

wierd as in "didn't look right" in a row. the calculation was fine.

Having a drop table for each possible combination for each item is going to be a mammoth undertaking, and if the sampled average doesn't use a large enough population, then the inaccurate result of multipling the two isn't going to make the data more helpful :/ -Chieftain Alex 23:27, 25 November 2013 (UTC)

I had intended it would only be used for items for which you had a chance of getting more than one quantity, so that's only two items per bag, usually. For lost orrian jewelry box, you would have one log for swigs of karma, one log for drops of karma, and one log for unidentifiable objects, in addition to the already present drop table. The logs wouldn't need to be visible in any way. Obviously if there were only two entries of data then it wouldn't be helpful, but a couple hundred would be enough to at least get it close enough. Psycho Robot (talk) 23:39, 25 November 2013 (UTC)

After thinking about it for a while, I think you're right, I think I underestimated how difficult it would be to get data on the average drop quantity of these items. So now I have one final suggestion. Add a new parameter for use with the manual totals table: varieddrop1 = yes. When this is set in the header, it will flag this column for being removed from the percentage calculations. Then we add a percentages row that is calculated as normal, but for any items which are flagged as a varied drop, it will display — instead of a percentage. This will let players see a percentage chance of receiving the more interesting/rarer drops without having any bizarre over 100% drop rate items. Psycho Robot (talk) 18:04, 26 November 2013 (UTC)

That's a bandage. If the drops are any more complex than what the template is designed for (Basic case of unique drops for automatic tallying), we need an actual spreadsheet instead. If we want to calculate the averages, you have the proposal on User_talk:Chieftain_Alex#Salvage_Research.--Relyk ~ talk < 19:07, 26 November 2013 (UTC)

I just think that it would be good if you could look at, for instance, Black Lion Chest, and see what your percentage chance of getting some backpack or mini was, instead of just how many you get per chest .01 quaggans per chest is a rather strange way of presenting the data, if that's the only way you're presenting it. Psycho Robot (talk) 19:49, 26 November 2013 (UTC)

note on variables layout

→ moved from User talk:Chieftain Alex/Template:Drop rate footer

pictorial layout:

| Totals        |      Item 1               |     Item 2                  |      Item 3                <!-- heading appearance

| Totals        |      {{{1}}}              |     {{{2}}}                 |      {{{3}}}               <!-- actual heading code

|------------------------------------------------------------------------------------------------------

| DRvar_count   | {{{{{#var:s1}}}} + DRvar_1 | {{{{{#var:s2}}}} + DRvar_2 | {{{{{#var:s3}}}} + DRvar_3 <!-- actual row code

|------------------------------------------------------------------------------------------------------

| DRvar_total   |       DRvar_1    |     DRvar_2      |     DRvar_3      <!-- (Hidden) Running Page Totals - final line is the same.

moved from orphaned page. -Chieftain Alex 13:33, 30 January 2014 (UTC)

total parameter

Since we have the manual totals to solve the tallying issue, I don't think the template should be doing automatic tallying for any table. This is mostly for the reason we are doing it manually in the first place, as automatic tallying is impossible for almost all our drop tables. I'd like to create a separate template for simple probability distributions for the condition where we have binary outcomes. This is to reduce the complexity of the template and make it easier to use for editors to avoid confusion. It will also remove the code and variables needed to automatically tally.--Relyk ~ talk < 23:13, 12 April 2014 (UTC)

the automatic totals was originally intended for items where you can only get one at a time, i.e. Daily. Everything else, well, you're just using the template wrong. And you can rewrite it, you're more than capable, and no doubt have more time than me. -Chieftain Alex 01:10, 13 April 2014 (UTC)

The template was intended for all drop rate pages, hence the standard in the name. You're the one that pushed for the template to be used on all drop table pages after all. Obviously, the original implementation wasn't correct. I don't want to make changes and then get your input weeks later once you happen to have more time and energy.--Relyk ~ talk < 01:50, 13 April 2014 (UTC)

ie. should have been e.g. and in fairness, I don't even play gw2 so how was I supposed to know that gifts would function differently to how they did in gw1. -Chieftain Alex 10:02, 13 April 2014 (UTC)

if you want it to be more obvious which template is which, then you could create something like {{SDRH auto}} for the automatic totals - it still would see use in a few places, and cull the automatic bit out of this template (quite why that would be better than current setup is beyond me...). -Chieftain Alex 10:43, 13 April 2014 (UTC)

Double "File" namespace

According to Special:WantedFiles, several missing images with the name "File:File:x" originate from pages like Small_Wintersday_Gift/drop_rate/2012.(Example: Special:WhatLinksHere/File:File:Bell_Focus_Skin.png). I can't wrap my head around what happens here exactly, does anyone have an idea what happens here? ~ Sanna 20:56, 9 November 2014 (UTC)

Performing a null edit on the offending pages clears out those entries. Must have been a bug in this template in the past that didn't completely clean itself up when it was fixed.

However, there's another bug - the i# parameters aren't working to override the icon images. —Dr Ishmael 21:37, 9 November 2014 (UTC)

The wierd thing is that the headings are appearing with their TOC numbers attached. o.o -Chieftain Alex 21:52, 9 November 2014 (UTC)

Solved. You left out the i in the parameter name. And then you included a default suffix even though the documentation (that everyone's been following) said that the suffix should be provided in the parameter value. Everything should be good now. —Dr Ishmael 21:56, 9 November 2014 (UTC)

I hadn't even looked at the template, I was so mesmerised by MW retaining the viewing options by the last person having chosen "auto-number headings" in preferences. (Similar to a bug I observed on pvx years ago where the page kept the MW messages of the previous editor, an italian) -Chieftain Alex 21:58, 9 November 2014 (UTC)

Nice job guys :) ~ Sanna 19:31, 12 November 2014 (UTC)

Inconsistencies

Howdy!

I'm very new to this wiki. I found out about the drop rate tables you've done here and wanted to participate by adding my data. Everything looks great except that I have a feeling that some of the data is added incorrectly. It seems that some of the people posting data just open all of their loot bags and post what they got. Ignoring the fact that if you had two silk from one bag drop, the table thinks you've opened two bags. Although the way to add data has been described on the same page. Perhaps adding a bigger red text with an example like, "Bob opens 1 Bag of Booty and receives 3 Cotton Scrap. Bob writes down, Cotton = 1". Not sure if that would help.

Anyway, that's not what I wanted to talk about. Inconsistencies! So there are many different tables out there now. Some of them use the manual totals way of adding data, like this one Heavy Loot Bag/Drop rate. Some have the automatic system, like here: Bag of Booty/Drop rate. And some even have 1xscrap, 2xscrap, 3xscrap as different lines, as seen here Light Supply Bag/Drop rate. So which one is the way to go? I wanted to add data for Heavy Bag of Booty but the drop rate table has not been created yet. I have no idea which template I should use as an example. Which is the way to go?

Thanks!

Maurish (talk) 16:51, 5 June 2015 (UTC)

The point of looking at the drop rate is to know how many bags you'd have to open to get, for example, 100 silk scraps.

The most complete would be to split the various quantities (x1, x2...) like Light Supply Bag/Drop rate. But this can be tedious when you open many bags.

The manual total is interesting because you can open a large number of bags at once and then write the final quantity of each item. Although, people have to remember the number of bags they opened; Sometimes they get 2 thick leather sections from... 0 bags!

The automatic total without separating the quantities makes the drop rate biased. Useless. Raljeor (talk) 17:18, 5 June 2015 (UTC)

I'm planning to switch to use the total parameter and default to the number of items if it's omitted. Blame Alex for not doing that in the first place.--Relyk ~ talk < 17:42, 5 June 2015 (UTC)

Sure, I don't really mind which method is used, as long as it's consistent. Some of the tables would have to be restarted then, right? Maurish (talk) 19:36, 5 June 2015 (UTC)

After a year, whats the state of this? I'd argue for the total, instead of occurrences, since it is by far easier to record, and its useful unlike the occurrences, since you get an average. Its still inconsistent. And it seems some are still confused what the right way to record drops is. Maybe change the line "Some boxes can give the user multiple amounts of a single item each time they are opened. If a player opens a single box and receives 3 of item A, and 1 of item C, then 1 would be added to the existing line count for both item A and C."? ( Additionally with this you could use the API to just click 2 buttons to record what items changed and paste it into the template ) Kalel (talk) 09:48, 4 June 2016 (UTC)

I don't think the table answered "number of occurences" in the first place. What would be accurate is to identify the entire drop table, the drop rate of each slot, and the drop rate for each slot. This isn't going to happen and the most important part for people is average drop rate. Anyways, I mostly finished a rewrite of the template on User:Relyk/SDR awhile back but some additional features Alex added aren't integrated and there are some other nuances that aren't addressed.--Relyk ~ talk < 10:34, 4 June 2016 (UTC)

Bringing this back up again. I don't think I've ever seen a page where people actually recorded the number of times they received the items, instead of how many items they had after opening x bags, due to how ludicrously easier it is to record the number of items received, and frankly what the template tries to instruct people to do makes no sense for someone that wants to open a lot of something --Gimmethegepgun (talk) 05:33, 14 September 2016 (UTC)

Take a look at https://wiki.guildwars2.com/index.php?title=Guild_Wars_2_Wiki:Sandbox&oldid=1258178 - there are 143 invocations of the SDRH template. 42 of them have manual totals specified, the functionality for which we are suggesting is what we should be using. I propose that we remove all data from the pages without manual totals set and start with blank drop tables. -Chieftain Alex 06:35, 14 September 2016 (UTC)

Some of them are plainly manual totals though, like Cracked Fractal Encryption/research, where all but 2 of the entries have more Dust/Fragments/Dragonite than the number of Encryptions opened (and those 2 are close in all 3 of them), whereas anyone who opened a single one could tell you that you don't get all 3 in every one you open --Gimmethegepgun (talk) 07:04, 14 September 2016 (UTC)

(Reset indent) I've gone through and blanked a hell of a lot of tables, and set the default to manual totals. Cracked Fractal Encryptions was an oddity which had manual totals in the rows but the header wasn't configured correctly. -Chieftain Alex 15:06, 17 September 2016 (UTC)

Adding additional option to for kill-based drops rather than container-based drops

Don't suppose there's a quick and easy way to modify the template to write "Creatures killed" instead of "Items opened" for the row titles and the Totals table's "Per container" to "Per kill". I've been working on a table for Karmic Retribution and found that there's no way to change these texts without modifying the template. I also feel that adding the option to do this can help with other articles with drop rates and articles that may come up in the future. Sythe 17:47, 22 September 2016 (UTC)

Okay done. totals label for the header template, and average label for the footer. -Chieftain Alex 19:10, 22 September 2016 (UTC)