Monsters with partial (i.e. between 0 and 1, exclusive; made-up term) rejection are not handled correctly, either with or without the combat queue.
Example: spend turns in the Hole in the Sky until you encounter an astronomer, then add up all the rates in appearance_rates($location[the hole in the sky], true) to get some number greater than 100. This does mirror what's shown in the location details.
The problem seems to be that the total zone weight as calculated by AreaCombatData is reduced by monster rejection rate, so the "denominator" in AdventureQueueDatabase.applyQueueEffects is smaller than the total number of monsters in the zone. The calculation ends up being incorrect in this scenario.
The approach is also simply incorrect in the case where multiple monsters with partial rejection appear in a zone (I don't think this currently happens; the only monsters I see with partial rejection are astronomer, amok putty, and wild seahorse; there may be others, though). For instance, I made a test zone locally where two of three monsters have 50% rejection. The current code expects that the two monsters with rejection show up 25% of the time, and the third monster shows up 50% of the time. In reality, for the third monster, we have three scenarios:
1) no monsters rejected, occurs 1/4 of the time. encounter rate: 1/3.
2) 1 monster rejected, occurs 1/2 of the time. encounter rate: 1/2.
3) 2 monsters rejected, occurs 1/4 of the time. encounter rate: 1.
Putting these together, the third monster actually appears 1/4*1/3 + 1/2*1/2 + 1/4*1 = 7/12, which is roughly 58.3%; the other two monsters appear with equal probability, about 20.8%.
So, two (maybe obvious) options:
1) accept slight incorrectness and just normalize so that the sum adds up to 100. This isn't as bad as it sounds in most practical cases, as it would yield results like 3.9263% when the expected is 3.9215% (specific case: looking at non-astronomer in queue; astronomer in queue, four other distinct monsters in queue).
2) Properly account for this, probably introducing more complexity.
I prefer the latter option, but I've been staring at it for the better part of a day and not coming up with a clean approach that doesn't involve cloning ArrayLists for every monster in the zone, so I'm open to input.
Example: spend turns in the Hole in the Sky until you encounter an astronomer, then add up all the rates in appearance_rates($location[the hole in the sky], true) to get some number greater than 100. This does mirror what's shown in the location details.
The problem seems to be that the total zone weight as calculated by AreaCombatData is reduced by monster rejection rate, so the "denominator" in AdventureQueueDatabase.applyQueueEffects is smaller than the total number of monsters in the zone. The calculation ends up being incorrect in this scenario.
The approach is also simply incorrect in the case where multiple monsters with partial rejection appear in a zone (I don't think this currently happens; the only monsters I see with partial rejection are astronomer, amok putty, and wild seahorse; there may be others, though). For instance, I made a test zone locally where two of three monsters have 50% rejection. The current code expects that the two monsters with rejection show up 25% of the time, and the third monster shows up 50% of the time. In reality, for the third monster, we have three scenarios:
1) no monsters rejected, occurs 1/4 of the time. encounter rate: 1/3.
2) 1 monster rejected, occurs 1/2 of the time. encounter rate: 1/2.
3) 2 monsters rejected, occurs 1/4 of the time. encounter rate: 1.
Putting these together, the third monster actually appears 1/4*1/3 + 1/2*1/2 + 1/4*1 = 7/12, which is roughly 58.3%; the other two monsters appear with equal probability, about 20.8%.
So, two (maybe obvious) options:
1) accept slight incorrectness and just normalize so that the sum adds up to 100. This isn't as bad as it sounds in most practical cases, as it would yield results like 3.9263% when the expected is 3.9215% (specific case: looking at non-astronomer in queue; astronomer in queue, four other distinct monsters in queue).
2) Properly account for this, probably introducing more complexity.
I prefer the latter option, but I've been staring at it for the better part of a day and not coming up with a clean approach that doesn't involve cloning ArrayLists for every monster in the zone, so I'm open to input.
Last edited: