Shop Inventory Filling - Possible Coding Mistake
Posted: Tue Nov 26, 2019 5:04 pm
This is (slightly modified) from my post in the Shop Inventory Mod topic in Mods & Features General:
This is all regarding some code in DaggerfallLootDataTables.cs, specifically these lines:
49: public static byte[] itemGroupsArmorer = new byte[] { 0x02, 0x50, 0x03, 0x14 };
60: public static byte[] itemGroupsWeaponSmith = new byte[] { 0x02, 0x1E, 0x03, 0x46 };
I've noticed something. It looks like the arrays from DaggerfallLootDataTables.cs are read and processed in order (in pairs) from left to right by a function in DaggerfallLoot.cs that generates the shop inventory, and the second number of each hex pair is related to the appearance chance. This is modified slightly by the rarity (from ItemTemplates.txt). Weapons all seem to have the rarity 1 (meaning no change of chance to appear), while armors all see to be rarity 3. This seems to mean (based on line 194 of DaggerfallLoot.cs) that the armor's chance of appearing is 90% of the number in the array, so if it's 0x32, it's not 50%, it's 45%.
(I'm puzzled by the bits about shop quality and buildingData. I can't find where the numbers are being drawn from, and I have no idea of their magnitude.)
But wait, it gets worse. In standard Daggerfall Unity, armor shops use this array: { 0x02, 0x50, 0x03, 0x14 } (I think) this means check armor first, 50% chance (that turns into 45%), and if nothing, try for weapons at 20% chance. While weapon shops use this array: { 0x02, 0x1E, 0x03, 0x46 }. If I'm interpreting the code right from the DaggerfallLoot.cs code, this means that weapon shops check for armor FIRST (at 30%, lowered to 27%), and only if it doesn't pass, check for weapons at 70%. That means that the chance of a weapon is effectively 73% of 70%, or 51.1%. Lower than intended, and more armor than intended.
If I'm correct, the array for itemGroupsWeaponSmith should be reversed, from { 0x02, 0x1E, 0x03, 0x46 }, to { 0x03, 0x46, 0x02, 0x1E }, then the percentages of generation should match what was intended.
Maybe I should let one of the devs know and let them check my analysis for accuracy so if I'm right, they can fix it in the next build.
Can someone who knows what they're doing (i.e. not me ) look at this and see if this is an (admittedly minor) issue?
This is all regarding some code in DaggerfallLootDataTables.cs, specifically these lines:
49: public static byte[] itemGroupsArmorer = new byte[] { 0x02, 0x50, 0x03, 0x14 };
60: public static byte[] itemGroupsWeaponSmith = new byte[] { 0x02, 0x1E, 0x03, 0x46 };
I've noticed something. It looks like the arrays from DaggerfallLootDataTables.cs are read and processed in order (in pairs) from left to right by a function in DaggerfallLoot.cs that generates the shop inventory, and the second number of each hex pair is related to the appearance chance. This is modified slightly by the rarity (from ItemTemplates.txt). Weapons all seem to have the rarity 1 (meaning no change of chance to appear), while armors all see to be rarity 3. This seems to mean (based on line 194 of DaggerfallLoot.cs) that the armor's chance of appearing is 90% of the number in the array, so if it's 0x32, it's not 50%, it's 45%.
(I'm puzzled by the bits about shop quality and buildingData. I can't find where the numbers are being drawn from, and I have no idea of their magnitude.)
But wait, it gets worse. In standard Daggerfall Unity, armor shops use this array: { 0x02, 0x50, 0x03, 0x14 } (I think) this means check armor first, 50% chance (that turns into 45%), and if nothing, try for weapons at 20% chance. While weapon shops use this array: { 0x02, 0x1E, 0x03, 0x46 }. If I'm interpreting the code right from the DaggerfallLoot.cs code, this means that weapon shops check for armor FIRST (at 30%, lowered to 27%), and only if it doesn't pass, check for weapons at 70%. That means that the chance of a weapon is effectively 73% of 70%, or 51.1%. Lower than intended, and more armor than intended.
If I'm correct, the array for itemGroupsWeaponSmith should be reversed, from { 0x02, 0x1E, 0x03, 0x46 }, to { 0x03, 0x46, 0x02, 0x1E }, then the percentages of generation should match what was intended.
Maybe I should let one of the devs know and let them check my analysis for accuracy so if I'm right, they can fix it in the next build.
Can someone who knows what they're doing (i.e. not me ) look at this and see if this is an (admittedly minor) issue?