About item tooltip string display issue

[Cypress]

Oddly, I can't even seem to generate ilvl=53 large charms with either of the 2%+ magic find affixes. At ilvl=58, Lucky(4-6% MF) starts spawning, and then at ilvl=60, Lucky(2-3% MF) starts spawning. It's as if Large Charms have some secret, hidden effective ilvl deduction of -7. The same applies to other affixes, for example when attempting to spawn ilvl=58 Large Charms, I cannot roll the Vita(+26-30) affix until ilvl=65. Or perhaps there's some hidden frequency penalty until the ilvl is +7 higher than the expected ilvl. Very strange.

Excluding this oddity, OrderOfTheScribble is right, the affixes spawn as expected, just with a 7 ilvl offset, with the more powerful affix appearing first.

[aprildie]

:O It seems like we stumbled upon a hardcoded example?

Thank you and OrderOfTheScribble for helping test the relationship between the "Lucky" affixes and affix level generation. This has been incredibly helpful to me! I also wanted to ask, how are these tests generally conducted? For instance, if I want to generate an item of a specified level and repeatedly test whether a particular affix appears at that level, what method would I use? Knowing this might enable me to conduct my own tests!

--

Regarding affixes, I have two additional questions I'd like to confirm:

1.
Do the "spawnable" and "frequency" fields in affixes determine whether the affix appears in the game? Both "magicprefix" and "magicsuffix" have these fields. If "spawnable" is not equal to 1, based on my reading of the PDF documentation, it indicates that the affix is not used in the game's randomizer for assigning item modifiers. So, I would filter out affixes where "spawnable" is false.

As I organize the affix table, I noticed instances where two identical affixes appear in the same group, with only the frequency values being different. For example, both of these affixes will appear in the "armor" category:

group | name | affix level | mod1code | mod1min | mod1max | frequency | type
101 | Strong | 9 | ac% | 31 | 40 | 0 | armo
101 | Strong | 9 | ac% | 31 | 40 | 8 | armo

Since both have "spawnable" equal to 1, they are not filtered out. Upon revisiting the PDF description, it mentions: "If the item has a magic level, then the magic level value is multiplied with this value. If equals 0, then this item affix will never appear on an item." Does this mean that when the frequency is 0, I can also consider the affix as "spawnable = false"?


2.
Affix probability calculation: Regarding the frequency explanation, it seems like I can calculate the probability of affix appearance. However, I'm unsure if this calculation is correct. It mentions "Total Frequency" comes from adding other affix frequencies. I'd like to confirm if these other affixes are based on the affix group for the item or for the item itself.

To illustrate my current understanding with hypothetical data, assuming these three affixes can exist on a certain item category:

group | name | frequency
1 | A | 1
1 | B | 2
2 | C | 3
If it's based on the group, then the probability of affix A would be 1(A) / (1(A) + 2(B)) = 33.3%. If it's based on the item, then the probability of affix A would be 1(A) / (1(A) + 2(B) + 3(C)) = 16.67%.

Are these two calculations correct, or have I oversimplified the formula?

[Cypress]

My method has been to create a cube recipe that generates a specific level Large Charm in cubemain.txt, using any input to output the charm.

Code: Select all

cheat	1			100					1	any							cm2,mag	53																																																																																						0

And I also set the frequency column in magicprefix.txt of the affixes I want to 255, so that they are likely to spawn.


(1)
Spawnable must be =1 and frequency must be at least 1 for an affix to spawn.

For magic level, that's a column in weapons.txt/armor.txt called 'magic lvl' which circlets, wands, staves and sorceress orbs have. Related: viewtopic.php?t=66605, this describes the odd way magic lvl works, it uses a very different affix generation formula compared to items without magic lvl. And actually, it also describes an oddity related to how items spawn without magic lvl (i.e. Large Charms and most other items in the game), so that might be why the Large Charms require a higher ilvl than expected.

(2)
I believe (never tested statistically) it takes all possible frequencies, adds them up then rolls. So group is only relevant when rolling multiple affixes, because an affix of the same group cannot be rolled twice. So in your example, if affix A,B,C are all valid affixes for the given itype, then the first roll chance for A will be 1(A) / (1(A) + 2(B) + 3(C)) = 16.67%, but if it rolls for a second affix then it could only be C since both A and B are part of group 1 which was already selected.

[aprildie]

Cypress,

I see! If I want to test with cubes, do I just need to directly modify the data tables in those .txt files and then launch the single-player game to make it effective?

According to your second point, it seems listing probabilities on the website might not be very meaningful. However, perhaps I can create a tool to calculate the probabilities of all affixes appearing.

Returning to the earlier discussion about the random skill level ranges, based on the formula you provided, it looks like there are no issues when calculating the minimum value. The only exception is the Snowclash belt, where the Blizzard skill level range is 7-19. Could you please explain how this 19 is calculated?

Thank you!

[Cypress]

aprildie, yes. You'd need to:
(1) Open patch_d2.mpq with an mpq editor
(2) Extract the data\global\excel folder
(3) Put it into your Diablo 2 directory, keeping the same directory (so it should look like Diablo II\data\global\excel)
(4) Use a sheet editor to modify cubemain.txt, I use AFJ Sheet Editor Pro (on the D2mods discord), or you can use AFJ Sheet Editor v0.61b vv0.61b (viewtopic.php?t=63847), or you can use any sheet editor you want as long as it will keep the file you are editing as a simple tab delimited txt file
(5) Make a shortcut of your Diablo 2, and add in the parameters -dir -txt
(6) Run the game, if you quit to the menu after modifying txt files it will update your txt files when you start a character, so you don't have to full quit the game every time

For Snowclash: ilvl=99 (lowest ilvl with lvl 19 Blizzard would be 96), rlvl=24, mlvl=20
1+min((ilvl-rlvl)/4,mlvl)
1+min((99-24)/4,20)
1+min(18,20)
1+18=19

[aprildie]

Thank you very much for the guidance! Now I can test the affixes on my own!

If we assume that mlvl is 20, should the formula be adjusted to
min(1 + (ilvl - rlvl) / 4, mlvl)?

[Cypress]

That's right, I didn't even think of that, the entire calculation is up to a maximum of mlvl, so the +1 should be within the min parentheses, as you have it.

[aprildie]

That's right, I didn't even think of that, the entire calculation is up to a maximum of mlvl, so the +1 should be within the min parentheses, as you have it.

--

I would like to inquire about the prioritization of affix displays.

When showcasing equipment properties, my current process involves initially searching for the value of stat1 in properties.txt. Subsequently, I link this value to itemstatcost.txt to obtain the descpriority parameter as the display priority for that property. The higher the priority, the higher the position of the property in the display order.

However, there are some properties in properties.txt that do not have a stat1 field for reference. In such cases, I am curious about how the game assigns priority to these properties.

For example, properties like dmg%, ethereal, and indestructible fall into this category. How does the game determine the priority for these properties in such situations?

[Cypress]

Desclines with the same priority appear to use desc that have a lower ID in itemstatcost.txt as a lower priority. Meaning, strength and dexterity with the same priority, dexterity will appear above strength because strength has a lower ID.

The indestruct property func 20 adds +1 item_indesctructible to an item, so Indestructible does have an associated stat.

Ethereal seems to always have the lowest priority, alongside item_numsocket which share the same descline.

Enhanced Damage has the highest priority of all descpriority=129 stats, or the lowest priority of all descpriority=130 stats. Meaning, it will always appear between descpriority=129 and descpriority=130.

For "Adds X-Y fire damage", it uses firemindam's priority.
Adds X-Y lightning damage -> lightmindam
Adds X-Y magic damage -> magicmindam
Adds X-Y cold damage -> coldmindam
+X-Y poison damage over Z seconds -> poisonmindam
Adds X-Y damage (one-handed only weapon) -> mindamage
Adds X-Y damage (two-handed only weapon) -> secondary_mindamage
Adds X-Y damage (one- or two-handed weapon) -> mindamage or secondary_mindamage, whichever results in a lower priority
Adds X-Y damage (throwing only) -> secondary_mindamage