That looks very similar to
this explanation, which is probably the source for Tubs
german explanation.
Unfortunately,I can't open the address of "this explanation", sometimes a too long adress is not correct, happened offen. Would you mind copy the rule to here from that link?
The sencond link of "Tubs German explanation ", I recognize it, some days before I've read it's English version, from this article I know this website has a caculator which can caculate drop chance of rare item.
This is very interesting. In your test, the probability for 3 affixes is significantly lower than 25% (first one: expected 142+-12, observed 60, probability nearly zero | second one: expected 29+-5, observed 18, that might be). This means that the theory or the test are wrong, or that they measure different things.
How did you generate the 568 rare items?
For the first 568 rare item, I choose to identify all rare item dropped by monster, continuously,
3 affixes=12+9+21+22=64,4 affixes=22+20+54+64=160, 5 affixes=31+17+72+70=190, 6 affixes=24+25+49+56=154
a few rare weapen have a vague affix number, like 4/5, because it's hard to tell out whether it's one affix or two affixes of 90ED 130AR. So I used the small one first, and the result is 3affix=11.27% 4affix=28.17% 5affix=33.45% 6affix=27.11%
second I used the maximam one, the result is:
3affix=10% 4affix=26.76% 5affix=33.27% 6affix=29.93%
then I averaged them。
The second time ,I gambled 117 rings,there arn't any vagued affixes, and the result is also not equal to 1/4,
3affix=18times 4affix=37times 5affix=40times 6affix=22times
normally 3 affixes is fewer。
Someone said it's because the sample are too few, maybe identify more than 1000 rare item, we can get a 1/4 chance for each affix. I don't have time to test that, so ,I choose to use the 1/4 chance for my programm first
An interesting question I found while testing this: What happens if the game trys to add a suffix, but all suffix groups are already used? Tests suggest that it takes a prefix in that case. If all suffix and prefix groups are already used, the game somehow detects this and generates the item without additional groups. But how does that work?
In addition, the game seems to actively search for free groups. If there is one group with a high frequency (like 2000) which is already taken and a free group with frequency 1, the game will always use this as next suffix instead of giving up and taking a prefix instead. This is different from the staffmod generation, where the game just tries to assign a staffmod 6 times and checks whether this is possible later..
Thans for give me the item choice webpage, I havn't seen it yet, I'll test it when I have time.
The phenomenon you've found is interesting, I didn't considerd this situation when prefix/suffix is not enough, I think it should happen when a item's affix level is very low.
As for the second phenomenon,when a affix choosed to be a prefix/suffix in the beginning, it has to be a prefix/suffix, as long as there are avalable prefix/suffix, no matter what the chance it is. So it is not base on Frequency/ Total Frequency, there should be a different algorithm, I think we can take it as Frequency /Total Frequency of available at present(apart from those affix that alvl< item alvl but already used)
Ah, I think I see the difference.
This gives an additional PPPS / SSSP pattern in the game, as the forth affixe is forced to be S or P, respectively. So instead of (4,6,4) different patterns you get (5,6,5).
If you just throw away this case, your total probability to get a rare item at all is not 1 any more.
This is even more important for 5 and 6 affixes, of course.
Brilliant!! I didn't consider the total chance must be 1. So my 6 affix chance is much lower than your caculator.
So at this part ,my algorithm is wrong, I can fix the problem soon.
Another difference:
If your first prefix is chosen, the second prefix cannot be in the same group, therefore you have to exclude
this group from the frequency sum. This requires to care about the order of the affixes, as the frequency sum
for the second item can be 194 or 192 (prefix) in your example.
It even gets more difficult if you consider that additional affixes might get chosen, which you don't care
about. That is the reason why our calculator uses the recursive function to "brute force" the problem
From your first to third rows I figured out why the chance is different when I choose 3 different Prefix with the same Frequency 4, because in your programm different order have different Frequency Sum.
We've discussed this question in our forum, the conclusion is Frequency Sum woun't change when choosing each affix . It's based on the ruvanal's affix selection mechanism. It didn't say the Frequency Sum should change if some group can't be choosen(when their affix has been choosen before).
We also get a explanation of choosen step:
a)Choose affix from, magicprefix.txt/magicsurfix.txt择
b)check version
c)check spawnable and rare
d)check item type
e)check alvl
f)Sum Frequency number of all available affix,chance of a affix=Frequency number of this affix/Total Frequency,similar to the usage of rarity。
based on the chance, choose one affix randomly;g)Check group number,if it already used,then go to f)and choose again
h)if the affix genearted ,then goto a).Then another affix generating cycle begins.
This rule should also have a original English version.
If this is true, then I'll insist.
If we need 2 Prefix, 1 for “of the Titan” F number is 4 ,1 for “of Precision”, F number is 3; Assumming the Total Prefix Frequency number(TF) is 100.
Then when generating the first prefix, it has a chance of 4/100 to get “of the Titan” ,when it comes to second prefix, the chance should be 3/100 to get “of Precision”, if the program choosed “of the Titan” or prefix of that group ,the program will go to a) and reselect again.
If it is runned by your rule, the second prefix will have 3/(100-number of strengh's group 31).
All make sense, but I prefer my rule, if there is a better reason for your rule, I'll also choose your rule.
But your rule will result to too many types of condition. I'll study your "brute force" approach later.
Sorry, correction, the reciprocal fourth line ,it's "the program will go to f) and reselect again.", not go to a), only the h) step will go to a).
wtf?
edit :
affixgenerator by Tub (not online since 2010 ... )
Thanks for helping me post my program interface.