The Lockbox Data Collection Project

[Stickasylum]

Glad to see how many submissions we're getting!
However, I don't agree with your conclusion on 'Drop rate / Cost per try'. 'Drop rate / Cost per try' is calculated as the drop rate divided by the number of keycodes you are spending, which is the drop rate for each keycode you spend. As an example, the current drop rate for a T2 Orange item is 2.96%, and you spent 4 key codes on that item. This means that for each keycode you spent, you got a 0.74% chance of getting an Orange. It's perfectly valid to express the likelihood of a drop, a probability, as a percentage.

Converting from probabilty to actual numbers, if each keycode out of the 100 keycodes gave you an item, you would expect 0.74% (the chance per keycode) of those items to be Orange, which does work out to 0.74 Orange items. Only, the statistic displayed is one of probability (again, chance per keycode), not the expected number of drops (out of 100) as you suggest, so the the percentage sign should be kept. Q.E.D.?

The "Drop rate / cost per item" is a correct title, since that is how it's calculated. The value isn't a probability, however! Adding up the the Drop Rate / cost per item values for, say, Tier 2 gives you 25, not 100 as would be necessary to describe a probability distribution with percentages (and incidentally, 25 is number of items you can buy with 100 keycodes!) Tier 3 gives you 12.5 and Tier 4 gives you 6.25, again the number items 100 keycodes will buy you in those respective tiers.

The drop rate % for, say, tier 2 orange, gives us the number of orange items we would expect to get, on average, if we bought 100 items. Say the drop rate is 2%. Then the Drop Rate / cost per item computation looks like (with unit cancelling):

(2 orange items / 100 items) / (4 keycodes / item)

= (2 orange items / 100 items) * (1 item / 4 keycodes)
= 0.5 orange items / 100 keycodes

That is, for every 100 keycodes we spend, we expect to get 0.5 orange items, on average.

[Noupoi]

Just know that it is far better to get the Tier 2 boxes over the others. As stated on the lock boxes themselves the item drop chances are only uncommon and above.

It would be different if the tier 4 gave a minimum of purple items only.

That is how it works now and I suspect it may get changed as there is absolutely no reason anyone should buy a lockbox above tier 2.

Going on 10 oranges from tier two boxes so far, including shields and grenades. Good luck!

Like Armanewb mentioned, the sample size for T2 lockboxes is far smaller than that for T3 and T4, so I'm not very confident in those results. The sample size is too small to rule out factors mentioned earlier in the thread like people with amazing drops (such as yours :P) looking for somewhere to discuss that, getting this thread more attention from people with lots of legendarys than than the majority who are getting the 'meh' results that I'm expecting.

But really, you must be really lucky- lady RNG is on your side. Out of all the lockboxes I've brought so far, I've not gotten one orange. >.>

[Noupoi]

The "Drop rate / cost per item" is a correct title, since that is how it's calculated. The value isn't a probability, however! Adding up the the Drop Rate / cost per item values for, say, Tier 2 gives you 25, not 100 as would be necessary to describe a probability distribution with percentages (and incidentally, 25 is number of items you can buy with 100 keycodes!) Tier 3 gives you 12.5 and Tier 4 gives you 6.25, again the number items 100 keycodes will buy you in those respective tiers.

The drop rate % for, say, tier 2 orange, gives us the number of orange items we would expect to get, on average, if we bought 100 items. Say the drop rate is 2%. Then the Drop Rate / cost per item computation looks like (with unit cancelling):

(2 orange items / 100 items) / (4 keycodes / item)

= (2 orange items / 100 items) * (1 item / 4 keycodes)
= 0.5 orange items / 100 keycodes

That is, for every 100 keycodes we spend, we expect to get 0.5 orange items, on average.

That's an interesting point with cancelling units. They've never really been my strong suit. :P
I'm now not entirely sure about the % following the 'cost per item' which has now confused me.

Surely by calling the statistic 'per item', we are removing 1/item from the unit, essentially bringing the unit of cost per item to 'Keycodes'.

This means that (2 orange items / 100 items) / (4 keycodes) goes to 0.02 (probability) / 4 (keycodes), so the the y-axis should really is something like probabilty/keycode, which should have the unit /Keycode when probabilty is expressed as a number between 0 and 1, or %/Keycode when expressed as a percentage?

Edit: After typing all this out, I've just realised we're really just arguing semantics, and what really matters is which tier has the highest bar. ^^




˙sı ʇıun ʇɔǝɹɹoɔ ǝɥʇ ʇɐɥʍ ʍouʞ oʇ ʇuɐʍ llıʇs I

[Stickasylum]

Like Armanewb mentioned, the sample size for T2 lockboxes is far smaller than that for T3 and T4, so I'm not very confident in those results. The sample size is too small to rule out factors mentioned earlier in the thread like people with amazing drops (such as yours :P) looking for somewhere to discuss that, getting this thread more attention from people with lots of legendarys than than the majority who are getting the 'meh' results that I'm expecting.

But really, you must be really lucky- lady RNG is on your side. Out of all the lockboxes I've brought so far, I've not gotten one orange. >.>

I'm going on 70 T2s without a single orange. Assuming the Orange drop rate is really around 5%, we'd need around 2000 T2 item drops to get a 95% confidence margin of error of + or - 1%. If the drop rate is lower, we'd need an even larger sample size! Also, I suspect that there will be some positive selection bias in the orange drop rates - people will likely remember to report drops more often when they pull oranges than when they pull greens! A large sample size will help combat this bias somewhat, so long as it comes in the form of people submitting large batches of drops.

That's an interesting point with cancelling units. They've never really been my strong suit. :P
I'm now not entirely sure about the % following the 'cost per item' which has now confused me.

Surely by calling the statistic 'per item', we are removing 1/item from the unit, essentially bringing us to the unit of cost per item to 'Keycodes'.

This means that (2 orange items / 100 items) / (4 keycodes) goes to 0.02 (probability) / 4 (keycodes), so the the y-axis should really is something like probabilty/keycode, which should have the unit /Keycode when probabilty is expressed as a number between 0 and 1, or %/Keycode when expressed as a percentage?

Whenever we have a "per" in the name of a statistic, we're going to have a unit on the top and on the bottom. Cost per item has units keycodes / item. In the computation, the item unit cancels with the bottom item unit of (2 orange items / 100 items). There isn't a strikeout font in this forum, but I'll use to indicate the cancelling:

(2 orange items / 100 items) / (4 keycodes / item)

= (2 orange items / 100 items) * (1 item / 4 keycodes)
= 0.5 orange items / 100 keycodes

Edit: After typing all this out, I've just realised we're really just arguing semantics, and what really matters is which tier has the highest bar. ^^

Yep! The statistic definitely works as a measure of drop efficiency. I just think
"Expected number of drops per 100 keycodes spent" (or something similar) makes the actual value easier to interpret, and gives the reader an idea of how much they would have to spend for an orange. And it shouldn't have a % sign

[Noupoi]

Whenever we have a "per" in the name of a statistic, we're going to have a unit on the top and on the bottom. Cost per item has units keycodes / item.

Hehe, I agree with how you've cancelled the units, but running the original unit for 'Cost per item' through my head doesn't make logical sense to me.

As an example, if a shopkeeper told you something costed £5 per bottle, and later someone else asked you how much they needed to pay per bottle, you would answer £5, not £5 per bottle, which when taken in context to the question, is £5 per bottle per bottle. But if they asked you 'how much does it cost?', you would answer £5 per bottle. o.O

Edit: As another example, but without the per bit: if box was 50cm wide, and someone asked out how wide the box was, you would answer 50cm. But if you were asked how many cm wide the box was, you would answer 50. So if the unit was stated in the quantity, there would be no need to state it again in the answer.

[Avenger]

Good to see lots more entries being added - just added a few more T3 and T2 boxes of my own - still yet to get an orange.

Data validation is a good idea, and if a formula can apply it even better. A few clearly disruptive entries are in there - 10 of the 16 oranges reported in T2 boxes come from one person's entry.

[hugdealer]

opened a tier 3, got 2 orange! no joke!

the nade was a huge upgrade

[knightofthebroho]

I think I've opened 4 (maybe 5) T4 boxes now and haven't gotten anything better than a blue. I think the RNG hates me.

[Stickasylum]

Hehe, I agree with how you've cancelled the units, but running the original unit for 'Cost per item' through my head doesn't make logical sense to me.

As an example, if a shopkeeper told you something costed £5 per bottle, and later someone else asked you how much they needed to pay per bottle, you would answer £5, not £5 per bottle, which when taken in context to the question, is £5 per bottle per bottle. But if they asked you 'how much does it cost?', you would answer £5 per bottle. o.O

Edit: As another example, but without the per bit: if box was 50cm wide, and someone asked out how wide the box was, you would answer 50cm. But if you were asked how many cm wide the box was, you would answer 50. So if the unit was stated in the quantity, there would be no need to state it again in the answer.

Ah, I see where your confusion is coming from now! Your second example is actually the solution to this problem. When you say "50" in answer to how many cm wide the box is, there is an implied unit of centimeters (from the question). Similarly, when you say the cost per bottle is £5, the "per bottle" unit is implied, since it is included in the preceding phrase. In fact, with unit prices, the "per unit" part is often implied, since it is obvious. You could just say bottles cost £5, and most people would assume you mean "per bottle". However, if the quantity doesn't have an obvious unit, then it is easy to see how the "per quanity" unit must be part of the dimension. For instance, saying "flour costs £5" is ambiguous without also specifying how much you get for £5!

Basically, all cost measures have a "per unit" part. Even if that part is simple enough that we usually ignore it and still be understood, it is still important for dimensional analysis!

Edit: adding in my T2 data!

Edit2: I think I see where some of the invalid data might be coming from. I had 108 values to submit, so I had to use multiple forms, some of which probably didn't add up to a multiple of 2. I haven't made google doc forms before, but if you could change the selection to a number entry, that would probably fix a lot a of the problem with invalid entries (and make bulk entry easier).

[Armanewb]

There are some data entries that look suspect, but I'm not sure if I want to manually delete data, as this would mean that we are being selective we the data.

It would be a good idea to implement basic validation to check that the submitted data is a multiple of the number of items from that lockbox. Being totally honest, I'm not familiar with Google Sheets nor the Apps Scripting language, and am not sure how to best go about doing validation on ranges.

Having said that, this is one of the formulae I hacked together to perform said validation:
=ARRAYFORMULA(SUM(IF(ISBLANK('Form Responses'!E2:E)=FALSE,IF(MOD(('Form Responses'!E2:E+'Form Responses'!F2:F+'Form Responses'!G2:G+'Form Responses'!H2:H),2)=0, 'Form Responses'!E2:E, 0),0)))

There's a sizeable difference between the new 'validated frequency' column and the originals, so I'd rather someone check over my formulae to before I changed the main frequency column in case I screwed something up.

This is my attempt at explaining wth the formula does: Checks if row is for submission of specified tier (in this case, T2), and then checks that the SUM of all the results from that row is a multiple of the number of items in the lockbox. If any of these checks are failed, the total for that row is returned as 0.

I uploaded my file to let you see how I did it.

https://docs.google.com/spreadsheet/...FE&usp=sharing

It uses a modulus and a vlookup to check whether the sum is appropriate.