Live data from Hacker News

Wi Flag (2002)

asheron.fandom.com

1–10 of 217 posts

Re: Wi Flag (2002)

#2
tl;dr: players get attacked based on monster targeting RNG that's supposed to take an interval [0,num_players], assign players to subintervals that are shorter or longer based on a bunch of factors, and then roll a random number somewhere in that full interval. Whoever's subinterval the number ends in, they get targetted.

Instead, the code assigned subintervals and then rolled a number between 0 and 1, instead of 0 and num_players. If your player happened to sort to the top of the list for subinterval assignment, you'd be it. You'd always be it.

Someone had to think to look at this, then confirm the maths, before it was found, years after the symptoms got reported. A unit test would have caught this, but didn't. Writing tests is annoying, especially in a codebase that keeps changing, but it's so important that this should count as one of those "this is what happens when you don't" lessons. Money was lost here.

Re: Wi Flag (2002)

#3
I've seen a similar mistake in a rushed "feature flagging"/phased rollout system.

User IDs were random UUIDs. Let's say we want to release a feature to ~33% of users; we take the first 2 characters of the UUID, giving us 256 possible buckets, then say that everyone in the first 1/3 of that range gets the feature. So, 00XXX...-55XXX... IDs get it, and 56-FF do not. This works fine.

However, if we then release another feature to 10% of users - everyone from 00-1A gets it, 1B-FF do not. That first set now has both features, and 56-FF have none. It turns out you can't draw meaningful conclusions when some users get every new feature and some get none at all.

Re: Wi Flag (2002)

#4

I've seen a similar mistake in a rushed "feature flagging"/phased rollout system. User IDs were random UUIDs. Let's say we want to release a feature to ~33% of users; we take the first 2 characters of the UUID, giving us 256 possible buckets, then say that everyone in the first 1/3 of that range gets the feature. So, 00XXX...-55XXX... IDs get it, and 56-FF do not. This works fine. However, if we then release another…

Huh, thanks for this. Will live in my head from now. Basically, in this situation, use (user_id, feature_name) for hashing, not just the user_id.

Re: Wi Flag (2002)

#5
I love the "lore" that this sort of bug creates, especially in these sorts of large scale multiplayer environments.

Players claiming to be cursed, and the curse was real!

A very different sort of event that it reminds me of is the old World of Warcraft plague: https://en.wikipedia.org/wiki/Corrupted_Blood_incident

Re: Wi Flag (2002)

#8
So it's not really a flag, it's that the algorithm that determines who the monsters attacks had a bug. The bug made it so that when there were a group of players to choose from, the mob would always pick players whose (hashed) identifier was higher on the list. Since the hash of your ID doesn't change, those players would always get picked on first. Like if your name is Aaron A. Aardvark, you're always coming first on any alphabetized list.

Re: Wi Flag (2002)

#9

tl;dr: players get attacked based on monster targeting RNG that's supposed to take an interval [0,num_players], assign players to subintervals that are shorter or longer based on a bunch of factors, and then roll a random number somewhere in that full interval. Whoever's subinterval the number ends in, they get targetted. Instead, the code assigned subintervals and then rolled a number between 0 and 1, instead of 0 a…

> You'd always be it.

It's slightly more complex than that: if you were farther away or otherwise in a better position than average your portion of the interval would be <1, and so even if you sorted first you still weren't guaranteed to be hit.

Re: Wi Flag (2002)

#10
Why does weighted randomness seem so difficult for games? Are there any libraries that simplify this? I couldn't find any for JS.

So I created my own "algorithms" for things like randomly choosing which type of plants spawn in the world. It weighs them by the local frequency of each land-type. Eg if there's more swamp nearby, it's more likely to spawn cattails.

It's awful. Not intuitive. Weights have to be passed in ordered smallest to largest. Posting in hopes someone will correct my entire approach or point out an industry-standard way of doing these things.

  Utils.weightedRandom(percents, types)

  function weightedRandom(weight, outcomes){
    var randNumber = Math.floor(Math.random()*100)
    for(let i=0; i
Post reply on HN