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.

Following my old bug report I found more typos in the distributions tables : local typos ={ -- keys are what is referenced in the Distributions.lua file -- values are what they should be referencing, aka the actual key in ProceduralDistributions.lua CrateCompactDisks = "CrateCompactDiscs", BakeryDonuts = "BakeryDoughnuts", CrateSandbags = "CrateSandBags", SportsStoreSneakers = "SportStoreSneakers", PlankStashWeapon = "PlankStashGun", ElectronicStoreComputer = "ElectronicStoreComputers", ElectronicsStoreMusic = "ElectronicStoreMusic", CrateNapkins = "CratePaperNapkins", MusicStoreAcoustic = "MusicStoreGuitar", } Additionally, I found the following loot tables referenced in Distributions.lua, but without a corresponding key in ProceduralDistributions.lua : -- line 7210, 7230, 7239 , pawnshopoffice loot {name="GunStoreGuns", min=0, max=99, weightChance=100}, -- line 7964, sewingstore loot {name="BookstoreTailoring", min=1, max=2, weightChance=100},

• Version 41.78.16(Steam) • Singleplayer • No mods. • Old save. • Reproduction steps: 1. Go south to the trailer park. 2. Get spotted by a zombie in the house at the attached coordinates. 3. Check the white car nearby to see if it's in good condition. 4. Go back to the house, clear the broken glass from the window she broke, and go in. 5. Fight the zombie. 6. Turn off the lights. First the one by the door, and then the one by the sink. 7. Go to the cabinets by the oven and open the loot table. The game then freezes for a few seconds before crashing to the desktop. Coordinates: 10820 x 10404 x 0 Also, I was playing in windowed mode, with the steam overlay enabled, and I think I had blender running in the background. The first one that came up when I went back to it in debug mode was the cupboard above the sink, and that just had a bread knife and a spoon in it. I found what YanaMD asked for in my last post, and uploaded the console.txt file, but that was while I was in the process of rebooting the game with debug mode disabled. The game's running fine now, no crashing. Although, the lights that I turned off earlier were on again. logs.zip console.txt

• Version 41.78.16(Steam) • Singleplayer • No mods. • New save. • Reproduction steps: 1. Start game in apocalypse mode. 2. While crouched, go out the back door, turn off the porch light, and go back inside. 3. Go in the laundry closet and check the inventory of the dryer. (It might have been a washing machine. I can't remember.) 4. Game immediately crashes to desktop. Coordinates: 8208x11601x0 Failed to replicate after starting the game again. Also, loading the game again later, the washing machine/dryer was empty. I don't know if it was empty before the crash or not. I would post a screenshot and my log file, but something's going wrong with my post attachments. Telling me that I have no post attachments, that I've used up all of the space for attachments, and that the two things I've attached in the past can't be found, and therefore can't be deleted to make space.

Hello, I've been fixing this for a few minutes and I'm not sure if I am correct or not. There isn't any available documentation or detailed explanation on the percentage of the loot drop because whatever I try to set is always a lot still. I'm trying to adjust the rarity of the drops in zombies as an experiment and get into modding PZ. This is what I've written so far and for a total of 20 zombies I kill I get about 5-7 items that I've set. Is the game ignoring the values I've input or is there a limit? Also I've set it to only drop on male zombies because putting the items on both male and female zombies drops a lot. Distributions = Distributions or {}; -- custom distributions table local nDistTable = { all = { inventorymale = { rolls = 1, items = { "Crisps", 0.007, "Crisps2", 0.002, "Chocolate", 0.002, "SunflowerSeeds", 0.002, "Peanuts", 0.002, "MintCandy", 0.002, "Lollipop", 0.002, } }, }, } -- insert table.insert(Distributions, 1, nDistTable); -- for mod compat: SuburbsDistributions = nDistTable; Above is the first code I've written, the second one below still drops the same amount of items. require "Items/SuburbsDistributions" local i; local nDistTable = { "Crisps", 0.007, "Crisps2", 0.002, "Chocolate", 0.002, "SunflowerSeeds", 0.002, "Peanuts", 0.002, "MintCandy", 0.002, "Lollipop", 0.002, } for i = 1, #nDistTable, 2 do table.insert(SuburbsDistributions["all"]["inventorymale"].items, nDistTable[i]); table.insert(SuburbsDistributions["all"]["inventorymale"].items, nDistTable[i+1]); end myDistTable = nil; Any feedback or suggestions is appreciated and I'd like to improve it more.

Hello everyone! I'm little stuck with my problem: I want to insert some loot in zombie corpses, BUT I also want to apply a "modifer" to a chance, based on SandboxVars Loot Rarity (or Server Settings - Loot Rarity). Here is my test mod (text formatting may be borked, not my fault ):

EDIT: This is still occuring in the newest IWBUMS version. The bug has been corroborated by other users as of October 2020 AD. I am submitting further information. Good evening. I am experiencing an odd situation on a custom Map. Now, one might say to oneself, "this is a Mod issue, take it there", but it isn't. The original author of the Map has confirmed the same bug in a game on his map without Mods. In the pictures attached, you will see the issue. In these specific classes of shelving furniture, the game is incapable of spawning anything except books. I searched in rooms marked "TOOLSTORE", "ELECTRONICSSTORE", "MEDCLINIC", "STORAGE", "GROCERYSTORAGE", "JEWELRYSTORE", and various other rare specilizations. Every single one of them spawn books. Only books. Every time. Despite this, I have seen other loot tableswork properly. In a room marked "STORAGEUNIT", I found a Baseball Bat and various tools inside both a filing cabinet and a desk. In those same kinds of places, the types of shelves pictured continue to spawn books, and only books. In the few instances where there are no books, I find empty shelves full of Plaster Powder and Concrete Powder, and five nails. I have never seen a Display Case producing anything but nails and Plaster Powder. It seems, based on what the makers of the Map I played on, that some classes of shelving are hard-coded to spawn ONLY books unless they are in one specific class of room. Some store shelves seem to spawn ONLY books UNLESS they are in an area marked as "GROCERY" or "GROCERYSTORAGE". Am I doing something wrong? Should I restart and run a custom Map, and only the Map, for testing? What governs loot spawning in shelves? Is it tied to the room, or to the shelf? I'm sick of books in my tool stores and electronic stores. Thank you for any assistance you may render. Warm regards and warm bodies, -TURTLESHROOM

This is 1993 Kentucky. Am I really expected to believe all of these people died to slow and stupid zombies without having time to get their home defense firearm? I expect them to not have ammo left most of the time, but seriously, what's with the lack of personal defense weapons in the pockets and under the pillows?

So I recently made a mod that simply adds almost everything to the loot table of zombies at a 0.1 rate table.insert(SuburbsDistributions["all"]["inventorymale"].items, "Base.Spiffo");table.insert(SuburbsDistributions["all"]["inventorymale"].items, 0.1); table.insert(SuburbsDistributions["all"]["inventoryfemale"].items, "Base.Spiffo");table.insert(SuburbsDistributions["all"]["inventoryfemale"].items, 0.1); etc. However because of the sheer amount of items added to the table I pretty much always get something from zombies, can I limit the amount of drops, is it as simple as lowering the drop rate some more or am I asking something that cant really be done yet?