Runefinding Calculator v2 - now with RFL metrics & round 3 data

[Luhkoh]

EDIT: I now think the "predicted RFL score" feature that I tried to include was very incorrect, and so it has been removed . Was excited for that one, but I think the only way to estimate it is by running several simulations of the sets. Perhaps a project for the future. The time to find a given rune from each area and the subsequent comparisons should still be good though!

After some helpful suggestions (mainly from @ffs , thanks!) in my first post HERE, I have greatly beefed up my runefinding calculator. It now includes runefinding data for what I considered the relevant round 3 areas: pits (this would also work for tunnels/ mausoleum), chaos sanctuary, and arcane sanctuary. I will include more detail about the new features below, but here is the link:

Runefinding Calculator v2 (google sheets, click to access)

For people NOT willing to record videos and count monsters:

The first page should still be pretty much the same, and the instructions on the right will describe how to use the sheet. The Round 3 data should be ignored, as it is highly dependent on decent inputs that have to be derived from recording video and counting or another method of counting monsters, such as the longer-term charm and rune counting method that @Gripphon plans to use.

For people willing to record videos and count monsters:

The "OTHER AREAS" page is where the round 3 inputs will be entered. Bosspacks should be nearly irrelevant, and feel free to leave them as zero. I wanted to include them for use cases such as someone running a p1 tunnels sorc wanting to see how long it should take them to find a rune. In a case like that (low psetting, many bosses) the bosses do become relevant. I also included the option to kill or not kill all the arcane and chaos superuniques, as well as diablo. This also makes very little difference, but I liked it for completeness's sake. Made the new version very, let's say "interesting" to calc .

Let me know if anything is behaving strangely. Always tough to keep from simple formula errors in a sheet this big. But hope some people enjoy it, and of course let me know of any issues or suggestions! Good luck to everyone during RFL!

 

[NanoMist]

Nice work! I put in my stats from last year's RFL results and it's not too far off from the expected scores.

 

[Luhkoh]

Nice work! I put in my stats from last year's RFL results and it's not too far off from the expected scores.

Awesome! Do you mind sharing the inputs? I wanted some good one in there just for when people see it.

 

[peytron]

Thanks for this (and the last one!), always fun to play around with a calculator.

Only 8000 more Chaos runs to go before I find that Zod!

 

[SlashRox]

This is incredibly cool! I'm still not at the 'running' stage of the game, but I can see myself playing with this calc quite a lot whenever I get there.
Thanks for sharing, it will be really interesting to see how the RFL results compare with the expected drops. A chance to evaluate whether our community of forumites has the RNG force behind it or not

I take it you suggest video recording so as to easily count the number of monsters after the runs? How many runs would you sample in order to feel that the expected monster count is reliable? I guess I'd just count a few and take the lowest amount obtained, so as to calculate on lower-than-real chance of drops. (only because counting could be pretty boring, I feel)

 

[NanoMist]

Cows: P7, 188 Sec (82.4, 77.9)
Trav: P3, 19.6 Sec (107.8, 96.5)
Arcane: P7, 59 Sec, 40/1/30/1 (71.2, 64.7)
Chaos: P7, 59 Sec, 30/1/30/1 (68.7, 64.7)

Arcane monster splits are based off my Nova Sorc. Not sure what my Javazon achieved but it's probably much better in the regular monster kills. In Areas I ran 10 hours each of Arcane and Chaos, so take the average expected value I suppose.

Numbers in parentheses are expected value from spreadsheet, then tournament score. I won RFL with all 3 scores below expected value? I see the expected score is calculated as RFL score * Chance to Find, but that Chance to Find is really the chance to find at least 1 particular rune. Expected return might be the better value to show. For example, 3673 Trav runs and a 1 in 591 chance for Pul rune should have an expected return of 6.215 Pul runes per 20 hours of Trav. Then the final score for the round would be the sum of the top 5 runes. This is the difficult part- how to find the expected score in a top 5 scoring scenario... I can only think of Monte Carlo methods to find this number. I recall one forum member that has done these simulations.. @drmalawi . Sample simulation and analysis of my Trav score.

 

[Luhkoh]

@peytron Awesome thanks! Honestly thats better than I'd have expected on the zod

@SlashRox Thank you! I'm not really sure what number of recordings would be very reliable for getting monster counts. Yes for this scenario recording and counting is the main thing that's done, and afaik people will count monsters on just a few runs. This is obviously helpful and hopefully accurate, but it could vary a fair bit in runs afterwards. That's part of why other, longer term methods have been discussed and used, such as the method Gripp uses, where you count all runes, jewels, and sc's. Those all drop in the same proportion as runes, and over a long period of time should give a pretty accurate estimate of monsters killed. Of course those items have a fair bit of variance too, so it could be off, and the main disadvantage is that you dont know your stats until the end of a set, rather than a few runs in.

@NanoMist Great thank you for sharing! And argh you are exactly right, and I greatly appreciate the insight. Now that I look at it, the chance to find*score seems nonsensical. As if you expected to find 0.9 pul runes. Expected number found would make much more sense, but using that gives you an expected score of almost the same number for every rune. Which I guess that also makes sense since the scores were calibrated by rarity.

Making a simulation of the data would be a fun project for sure, but i think I would want it to be separate from the sheet since at a minimum it would include a google sheets macro. I'm trying to conceptualize a shortcut approximation of taking the top 5, but am coming up with nothing. If you just take 5 of the (same value) expected score, then I think it more reflects if you chose your most average qualifiers rather than your best 5. So I am beginning to agree the simulation may be the only way to go. Let me know if you think of any other ideas. I'm thinking the RFL score sheet as it is doesn't make much sense, so I may want to remove it for now.

 

[Luhkoh]

@NanoMist The only idea I came up with that I feel had a chance of being reasonable was finding the expected number of each rune per round (like you mentioned) and multiplying that by the rune score. Then summing up those results from the bottom (zod) up, until your cumulative expected number of runes reached five. However this still gave a much higher answer than average (as determined by @drmalawi 's sims), so it's definitely incorrect. I'm not sure whether it could still serve as a useful metric or not, but I think just running a simulator is the only good way to go. So I removed the predicted score feature from the sheet, and maybe I'll work on a simulator sometime in the future. Thanks for the help and feedback!

The sheet should still be a very nice way to compare time to find a rune from those 7 areas (9 if you count tunnels/maus), but no rfl metrics. Maybe next year!

 

[NanoMist]

While playing around with the sheet I realized Trav hork was set to 50% by default, and I didn't change it to 0% when I made my last post. Doesn't change the expected score problem though.

@NanoMist The only idea I came up with that I feel had a chance of being reasonable was finding the expected number of each rune per round (like you mentioned) and multiplying that by the rune score. Then summing up those results from the bottom (zod) up, until your cumulative expected number of runes reached five. However this still gave a much higher answer than average (as determined by @drmalawi 's sims), so it's definitely incorrect.

I thought about that method too but I got scores that were fairly close. When I set P3, 20 Second Trav Runs with 0% Hork, the expected value from Ohm-Cham is 5.04 and the expected score is 79.9 points. Drmalawi's simulation resulted in 77 points.
The other data point he had was 20800 council kills for an average score of 58.3. 20800 council kills works out to 1891 runs, or 38 seconds per run. I assume he ran on P3 and I don't think he used a Barb. EV of 5 landed in the Ist range, so I interpolated the Ist score to get an exact EV of 5.0 and ES of 61.3.

Another method I tried was to find some way to adjust the expected values to account for the top 5 selection. The idea is that the more efficient the runner, the lower the chances of a low scoring rune making into the top 5. The EV of each rune is multiplied by the odds that all the runes above it does not drop 5 or more times. This is also a flawed calculation like the first method, but is it a close approximation?

This is for P3 Trav, 20 seconds runs:



I reordered the runes by rarity and provided a column for drop chances of that particular rune and above. As you can see the lower runes have very low expected scores since the chances of those runes making top 5 are extremely low for an efficient runner.

Total adjusted EV is 5.697, not quite the 5 EV I was looking for that indicates 5 runes. I tried doing a corrective multiplier but it becomes an undershoot. If someone wants the spreadsheet for this I can provide (It's based off Luhkoh's sheet), but the simulation route is really the way to go.

 

[Luhkoh]

While playing around with the sheet I realized Trav hork was set to 50% by default, and I didn't change it to 0% when I made my last post. Doesn't change the expected score problem though.



I thought about that method too but I got scores that were fairly close. When I set P3, 20 Second Trav Runs with 0% Hork, the expected value from Ohm-Cham is 5.04 and the expected score is 79.9 points. Drmalawi's simulation resulted in 77 points.
The other data point he had was 20800 council kills for an average score of 58.3. 20800 council kills works out to 1891 runs, or 38 seconds per run. I assume he ran on P3 and I don't think he used a Barb. EV of 5 landed in the Ist range, so I interpolated the Ist score to get an exact EV of 5.0 and ES of 61.3.

Another method I tried was to find some way to adjust the expected values to account for the top 5 selection. The idea is that the more efficient the runner, the lower the chances of a low scoring rune making into the top 5. The EV of each rune is multiplied by the odds that all the runes above it does not drop 5 or more times. This is also a flawed calculation like the first method, but is it a close approximation?

This is for P3 Trav, 20 seconds runs:

View attachment 12933

I reordered the runes by rarity and provided a column for drop chances of that particular rune and above. As you can see the lower runes have very low expected scores since the chances of those runes making top 5 are extremely low for an efficient runner.

Total adjusted EV is 5.697, not quite the 5 EV I was looking for that indicates 5 runes. I tried doing a corrective multiplier but it becomes an undershoot. If someone wants the spreadsheet for this I can provide (It's based off Luhkoh's sheet), but the simulation route is really the way to go.

Interesting stuff. I really appreciate the work. I will dig in to this and think on it tomorrow. Very cool ideas.

 

[ffs]

Great work, very cool tool! And interesting points re expected drops after a given amount of time.

Generally though IMO it’s totally fine to not have a score prediction feature, otherwise you may be tempted to think "if I get run times to X seconds I will win RFL". You need a lot of luck to win tournaments like this anyway (especially with only top 5 counting instead of overall drops). Of course it doesn’t hurt to be good at it, e.g. @NanoMist's incredible win streak wouldn’t be possible if he wasn’t an efficient runner. But really bottom line it’s RNG, and knowing "expected drops after X runs/time" tends to have people complaining about their bad luck more than anything... see LK running.

That’s why personally I just try to beat my own efficiency for these tournaments. Or that of others if they are faster... and not called @Gripphon. It’s the only thing you can really influence and compete against fair and square. Good results are always nice of course, but they are just a side product, and vice versa you can’t count on winning just because you’re fast. That’s my attitude at least, but it’s why I actually enjoy these tournaments even though I never seem to manage and win one.

 

[Luhkoh]

Great work, very cool tool! And interesting points re expected drops after a given amount of time.

Generally though IMO it’s totally fine to not have a score prediction feature, otherwise you may be tempted to think "if I get run times to X seconds I will win RFL". You need a lot of luck to win tournaments like this anyway (especially with only top 5 counting instead of overall drops). Of course it doesn’t hurt to be good at it, e.g. @NanoMist's incredible win streak wouldn’t be possible if he wasn’t an efficient runner. But really bottom line it’s RNG, and knowing "expected drops after X runs/time" tends to have people complaining about their bad luck more than anything... see LK running.

That’s why personally I just try to beat my own efficiency for these tournaments. Or that of others if they are faster... and not called @Gripphon. It’s the only thing you can really influence and compete against fair and square. Good results are always nice of course, but they are just a side product, and vice versa you can’t count on winning just because you’re fast. That’s my attitude at least, but it’s why I actually enjoy these tournaments even though I never seem to manage and win one.

Haha great point about the predicted score just causing complaining, and nice to hear you won't miss the predicted score feature if we don't come up with a better approximation. My main desire in providing it was to have a way to compare arcane sanctuary to the other areas, taking into account the significant disadvantage that zod can't drop. Of course this is only really applicable to the tournament as you just would not go to arcane if you want to drop a zod. But I am very interested in what is the "best" round 3 area, and by how much of a margin. I think it will still be arcane, but am not sure by any means. It's certainly not just a matter of effective kills per hour, as it seems like you have to drop at LEAST one zod for a chance to win

 

[Luhkoh]

@NanoMist I was making the same mistake. I thought I was getting way too high because I still had hork in at 50% . So I think the "cumulative expected number up to 5" method may be close enough to include in the sheet. I get 80.5 compared to drmalawi's 77, and 62 compared to his 58.3. So the prediction is optimistic but might be worth including. Do you agree? Or too flawed to think of as a decent metric? By the way I think the only reason we get slightly different answers now is because I'm interpolating last entry of the sum of expected scores in order to get to exactly 5 cumulative runes, rather than doing the adjustment at the end. But both should work fine.

Your "times chance of not dropping 5 above" method is very interesting and seems to give an even nicer score prediction. I think I like the method less though, just because it would make more sense to be the chance of dropping 5 of any of the runes above it. I think your adjustment is just dropping 5 of the single rune above it correct? I don't know how/if you could calc the chance of dropping "any 5 above" but I just wanted to make sure that wasn't what you had already done.

Ohh I think I see. That's why you use avg run rune+ correct? So that might be taken into account. That's some interesting stuff, and may indeed be a very cool way to approximate it. I'll play with that in my sheet today and probably message you again in a few hours Again thanks for all the theorizing. I love this kind of stuff.

 

[Gripphon]

I had formula for top 5 expected score somewhere, dunno where. Bottom line is when checking top 5 expected score, majority of players are really really close at it. Zod is messing things up big time due to being very rare and being very valuable in points. In the end such info loses it's sense quickly. It comes down to getting or not getting Zod. For RFO, on the other hand, such estimation was incredibly obvious and would bring huge difference between players and influence of running speed would be of much bigger importance.

To compare any area we can only compare drop odds of a single rune per time invested, be it Ber or whatever.

 

[ffs]

@Luhkoh that's a good point re AS vs other areas. There are similar issues in comparing other types of runs.

For example before AS was run last RFL most ran CS because in RFL 2017 it compared favourably to Pit runs. I figured you lose efficiency in Pit when doing full clears, so i tried these runs with Java, which in fact had higher kills per minute than CS Vizier runners. She targeted only camps, two in Pit and one in Tamoe. The caveat is that the latter can only drop up to Lo. Of course Lo is normally a top 5 rune, but here too the unanswered question was how much of a difference does it make that ~2/3 of kills have chances up to Zod and ~1/3 up to Lo.

Last year I quickly felt the higher AS efficiency outweighed slim Zod chances in other areas. But running CS with seal trick this year could change this back around, if it proves to be better than Vizier runs.

 

[ffs]

One suggestion: I saw that for CS tab you implemented "yes" and "no" option for seal bosses. I assume chosing "yes" here means the bosses and their minions are counted (and max number for Vizier "fork" layout minions). If so maybe include an option to account for partial clearing for seals if you only snipe the boss?

 

[Luhkoh]

One suggestion: I saw that for CS tab you implemented "yes" and "no" option for seal bosses. I assume chosing "yes" here means the bosses and their minions are counted (and max number for Vizier "fork" layout minions). If so maybe include an option to account for partial clearing for seals if you only snipe the boss?

I think this should work the way you want already, but its not entirely clear, I should include more directions. But the minions would just be added in as regular ghost or non ghost monsters. The yes/no is only for the single seal boss himself.

EDIT: and the seal bosses, as well as any uniques themselves, make very little difference, especially on p7. So if you ONLY input regular monsters and ghost monsters (which include minions) you will get a very good answer. I really just added in all the customizability for fun and for lower playersetting applications.