Possible bug on item package randomness

[guilherme-gm]

Note: I don't know if this is really a bug, it seems so, but it may simply be that it is meant to work this way. I am opening the issue so it may be discussed before I open a PR for it.

The issue is a bit long to avoid confusion.

Describe the bug
I believe Item Package chances are not working as intended. Currently the logic applied to pick 1 item in a random group is:

1. Pick a random item as start point
2. Run a "drop logic" in this item
3. If it fails, go to the next item and repeat 2/3
4. If it success, stop and go to the next group

Source

Now let's consider the following case:

Custom_Item: {
 Red_Potion: {
  Random: 1
  Rate: 8000
 }
 Blue_Potion: {
  Random: 1
  Rate: 2000
 }
}

For this package, if step 1 picks Red_Potion, the following would happen:

1. Try to "drop" Red_Potion (80% success / 20% fail) - Failed
2. Try to "drop" Blue_Potion (20% success / 80% fail) ...

In this case, Blue_Potion chance is not really 20%, to get it you have 2 conditions:

1. You must fail "droping" Red_Potion (20% chance)
2. You must success "droping" Blue_Potion (20% chance)

That means we have to pass the 20% check twice, which would mean 0.2 * 0.2 = 0.04 = 4% chance of getting a Blue_Potion.

I did some modifications on my Herc to run a simulation of lots of packages to compare the chances (Remember: there is the randomness in effect here, so it is expected that it will not be a perfect match, but should be close by).

This is a spreadsheet with results:
Package Item.xlsx

I did a few tests:

1. Simply running the code as is and opening lots of boxes with different settings
2. Removing the step 1 of the process so it always starts from the first item
3. Fixing the random seed to compare with the proposed solution

As far as I can see, the issue gets alleviated due to step 1, but it gets a bit more clear when you start using higher chances (e.g. 80_00 / 20_00 as shown above).

On a side note: The current implementation also does a lot of loops -- the spreadsheet shows how many loops were required for each item too.

Expected Proposed behavior
I believe item packages should be using a similar approach to item groups, where Rate actually translates to "repeated entries", and instead of trying to "drop" each item, we could run a single rand in the entire list and pick the item from there.

For example (inlined to save space):

Custom_Item: { // Assume all of them are in same Random group
 Red_Potion: { Rate: 50_00 }
 Blue_Potion: { Rate: 30_00 }
 Green_Potion: { Rate: 20_00 }
}

We have a sum of 100_00 (0 .. 99_99) where:

• 0 .. 49_99 is Red_Potion (50% of the values)
• 50_00 .. 79_99 is Blue_Potion (30% of the values)
• 80_00 .. 99_99 is Green_Potion (20% of the values)

The spreadsheet above contains the same tests using this solution (in a hacky way, but the results are correct)

Checking the notes when this feature was implemented, I got into those 2 topics in herc forum:

• https://board.herc.ws/topic/1244-official-item-grouppackagechain/
• https://board.herc.ws/topic/332-package-item/ (Specially this comment: https://board.herc.ws/topic/332-package-item/?do=findComment&comment=2741 )

This also led me to think there might have been a misunderstanding between the explanation and the implementation, and I think the proposed solution is closer to the explanation in the 3rd link.

I can work in this fix, just want to be sure if it is really something to be fixed.

System specs (please complete the following information):

• OS: Linux Mint 21.1
• Hercules Version: v2023.01.11
• Mode: renewal
• Packet version: 2018-10-02
• Client type: main

Plugins used or source modifications
none

Additional context
N/A