Search the Community

Context: I play a lot of insanely rare loot runs on high pop and when I finally looked up the actual item weights, I noticed that they did not create an expected distribution that even remotely resembled what I experienced finding after 1000+ hours of play. The most apparent of which is that Book 5 is supposed to be 12x rarer than Book 1, which definitely does not feel true in my experience. I made another bug report (https://theindiestone.com/forums/index.php?/topic/72133-4178-loot-rarity-rerolls-unintuitively-makes-common-items-rare/) before I fully understood, but in that post, I demonstrated via a sample of 200 rolls in a random Muldraugh house that the resulting loot gave a much flatter distribution than expected. I didn't understand the correct reason why yet, but I think I have identified the reason now. Overall root issue: Zombie Intensity Loot Modifier (returned from getLootZombieIntensity), which I will refer to as "ZPLM" for this post, which is part of the roll to determine if an item is added to a container, is not modified by loot settings or item weight. This means that the rarity difference between two items of different weights is much smaller than their relative item weights would suggest, especially on lower loot settings. I've identified at least 4 separate problems related to this core issue: Low weight items are functionality equivalent in rarity between insanely rare and abundant loot settings. This becomes more apparent the lower the weight of the item. Item weights do not impact item rarity to the expected extent. This means that rare items cannot be made to be nearly as rare as their weights relative to common items would suggest they are. This becomes more apparent the lower the loot setting you are on. Integer RNG (random(10000), so specifically with this level of precision anyways) means the smallest weight multiple that actually impacts the outcome on insanely rare is 0.2. Even without ZPLM, any item with a weight under 0.2 would have the same 1 in 10000 chance of appearing on insanely rare, requiring a 0 on the random(10000) roll. Item weights go as low as 0.01, so this makes them all equal rarity. (e.g. HottieZ, 0.1, and Sledgehammer, 0.01, are equal rarity despite the 10x weight difference) Since item weight is less of a factor in determining rarity, rarity becomes more closely tied to how often items appear in containers than their weight, especially on lower loot settings. This explains my difficulty finding a belt that I explained in my other post. Despite having a moderately high weight (4), "Belt" does not appear in a ton of loot lists (14 hits in proceduraldistributions.lua), which makes it arguably rarer than Sledgehammer (0.01 wgt, 18 hits), despite the 400x higher item weight. Evidence Here's how I understand it to work: (based on itempicker.doRollItem & itempicker.rollItem) Zombie Intensity is loaded from save data per chunk, presumably related to population. I think it is literally the 8-bit value on a population heatmap. For simplification I will refer to it as population. The finer details don't matter too much for the overall point unless it turns out that ZPLM is very rarely relevant. If the average ZPLM turns out to be closer to 4 than 8 then the impact is still there, just less pronounced. Zombie Population Loot modifier (ZPLM) decompiled code derived formula : if rand(300) < Chunk population x 10/255, return 120, else 0.06 + Intensity x 11.94/255 Super oversimplification: Zombie Population Loot modifier (ZPLM) = 1 per 25 zombies, 1/25 chance of max modifier (8) per 25 zombies. Max possible value of 8. Sandbox Loot Modifier (SLM) = {0.05, 0.2, 0.6, 1.0, 2.0, 3.0} doRollItem simplified pseudocode (runs for every item when generating loot for a container, usually 4x): if (100 * wgt * SLM + ZPLM*10) < rand(10,000), add item to container if it does not exist yet, or if qty can be >1 For the sake of further simplification, going forward we will assume ZPLM is always 8, as it will be frequently enough to have a significant impact, especially at higher population settings. I think in practice it is almost always 8 in any moderately populated chunk, but I haven't been able to verify that since I don't know exactly what it is reading for the intensity value and how much actual zombie population (after population modifiers) comes into play. Example outcomes: Sledgehammer (0.01 wgt, or 0.01%) vs Battery (20 wgt, or 20%) drop chance Expected distribution - 1 : 2000 -------------- insanely rare (5%) ------------------ 0.01 wgt: if (0.05 + 80) < rand(10,000), or 0.8% chance 20 wgt: if (100 + 80) < rand(10,000), or 1.8% chance Actual distribution - 1 : 2.25 -------------- rare (60%) ------------------------- 0.01 wgt: if (0.6 + 80) < rand(10,000), or 0.8% chance 20 wgt: if (1200 + 80) < rand(10,000), or 12.8% chance Actual distribution - 1 : 16 -------------- abundant (300%) ------------------ 0.01 wgt: if (3 + 80) < rand(10,000), or 0.83% chance 20 wgt: if (6000 + 80) < rand(10,000), or 60.80% chance Actual distribution - 1 : 73 Put A LOT more simply, it looks like you get up to a flat +0.8% chance for every item to drop based on the zombie intensity / population in that chunk, not scaled with any other loot modifiers. This brings the rarest items almost up to the same drop chance as common items on the rarer loot settings. This also effectively sets a "minimum" drop chance of 0.8%, which is much higher than the expected drop chance of something like a Sledgehammer with a weight of 0.01, which would be 0.0005% on insanely rare, or rounded to 0.01% due to integer RNG, making it 80-1600x more common than expected based on weight. This is just speculation, but to me it feels like the max value of 8 (seems arbitrary) may have been added to address this. Additionally, a lot of the code around Zombie Intensity calculations seems to have some lines/assignments that don't appear to do anything. It's possibly an issue with my decompilation of it, but I've used the code pretty thoroughly and never seen any obvious issues with any of the other code.

Go here http://orteil.dashnet.org/nested This is a simple procedural generation game; "The display is set up like a directory of nested folders. You click on a universe, which gives you access to a number of galaxies, each of which contains planets, asteroid belts, and such. You can click to explore planets, and if they harbor intelligent life, you can view the species and cultures, visit their museums, and even see their thoughts." For example, this is my game session: I started out by selecting a universe > galaxy > star system > asteroid belt > then into another galaxy > inside a black hole > dyson sphere > a future planet > a continent called Masoca > a city called Citadion > person called Alice Dorzine > explored his body > explored his psyche > his thoughts > he thought: "I need a couple decades on an exotic planet to cool off." > Alice is wearing a white nanosuit > the suit is made of nanoplasm > it contains nanobots > made of silicon > it thought :"ready to sacrifice myself for you, sir :]" > then inside the nanobot itself contains atoms > which lead me to another multiverse called "babyverse" > star system > another planet > continent > land called "Realm of Kesdoor" > fortress > castle > a guard named "Henry Blackmight" > his body > his head > his skin > pores > contain bacteria called hydrovirus. So what did you find in your universe?