I bet some code unknown to the developers becomes active.

For those of you who don't know what the Wi Flag means, a little history. From the beginning of AC, some players have complained about unbelievably bad luck. When the swarm of Lugians spawn in the citadel, they will go after certain players--every time. The player's level doesn't seem to matter, nor does the number of other players in the room. What does seem to matter is that this player is cursed with that most unfortunate of distinctions: the Wi Flag.


For some players, the flag came and went. For others, it was a perpetual nightmare, present in nearly every monster experience. To live a Wi-Flagged life meant to be hunted at every turn. Perhaps other adventurers could know peace in a BSD or a Citadel, but there was no rest nor respite for one under Wi.


Our developers at Turbine initially answered these complaints by saying that they could find no such bug. Occasionally, a senior Turbine engineer could be found who would admit that perhaps there was something "not quite right" with the system, but they still could not identify a cause, if one even existed. Easy culprits, such as a malfunctioning random-number generator, were eventually dismissed.


But our search went on. For there were people even at Turbine convinced that the Wi Flag existed, and that they had it in spades.


And then one day, long after most people had learned to either forget or ignore the Wi Flag, the answer was found. Here in the report from Sandra Powers, AC Live's Lead Engineer, on the nature of the Wi Flag. We warn you in advance that it is a very technical explanation, but we hope it is of some interest to those of you who have long been afflicted with this terrible burden.


"Many of our players have complained for a long time that their character are `Wi-Flagged'--that is, that creatures attack them a much greater proportion of the time than random chance or distance should dictate. After looking at the code in depth, I believe I have found out why this might happen.


Generally, a creature chooses whom to attack based on who it was last attacking, who attacked it last, or who caused it damage last. When players first enter the creature's detection radius, however, none of these things are useful yet, so the creature chooses a target randomly, weighted by distance. Players within the creature's detection sphere are weighted by how close they are to the creature -- the closer you are, the more chance you have to be selected to be attacked.


The actual algorithm for selection looks like this: We roll a random number within a certain range--say between 0 and 1. Each player is given a portion of the range based on how close they are to the creature. The closer you are, the larger a portion you get. The player who owns the portion into which the random number falls is selected to be attacked.


This algorithm is sound. The problem comes up when we are assigning portions of the range to various players. If we wanted distance from the creature to be proportional to your chance to be selected--that is, if the closer you are the *less* chance you have of being attacked--then we would assign this range by taking your distance from the creature over the total distance--the distances of everybody under consideration added together. But we really want the inverse of this ratio--so that the closer you are, the *more* chance you have of being selected. So we invert this ratio by subtracting it from 1 to assign you the size of your portion.


An example:

A is 5 meters from the creature.
B is 2 meters from the creature.
C is 3 meters from the creature.
D is 10 meters from the creature.
Total distance is 20.
The size of A's portion is 1 - 5/20, or 0.75.
The size of B's portion is 1 - 2/20, or 0.90.
The size of C's portion is 1 - 3/20, or 0.85.
The size of D's portion is 1 - 10/20, or 0.50.
So we assign these people these portions of the total range:
A has between 0.00 and 0.75.
B has between 0.75 and 1.65.
C has between 1.65 and 2.50.
D has between 2.50 and 3.00.

Notice, however, that while the original ratios added to 1 (.25 + .1 + .15 + .5 = 1.0) that the inverted ratios -- and thus the total range from which we should have rolled the random number -- no longer add to 1. Instead, they add to 3. (Some algebra will convince you that the assigned portions always add to n-1, where n is the number of people under consideration.) So in order to randomly select some portion of this total range, we should roll a number between 0 and 3.


But in the existing AC code, we always roll a number between 0 and 1.


You can easily see in this example that if the random number is always been 0 and 1, only A and B have any chance at all of being selected, and A has the majority of the chance. And the reason that these two have all the chance is simply because they are first in the list, and so were assigned the low parts of the range. Normally--if we had rolled between 0 and 3 in the example--your order in the list should have no effect on how likely you are to be chosen. But because we only rolled between 0 and 1, the earlier you appear in the list, the more skewed your chance of selection is. And as it happens, in AC code, your position in this list is determined by the InstanceID of your character, which is assigned when you create the character and never changed. (Note that the InstanceID is hashed--mutated by the system into another number--to determine position. So it's not a simple relationship like the older the character, the earlier in the list they will be. It is, however, a static relationship--an ID that hashes to an early position will always hash to an early position, although it's exact position will depend on what other ID's are also under consideration.)


So what does this mean? The way this random targeting algorithm is implemented right now, if you happen to have an InstanceID that hashes to an early position, you will tend to be attacked more than your fair share when the creature is using random targeting, regardless of your distance from the creature. In other words, you are Wi-Flagged."


We're glad we were finally able to fix this bug. With the July 2002 Event, may you know peace in the fast-spawning dungeon of your choice!