Live data from Hacker News

Wi Flag (2002)

asheron.fandom.com

91–100 of 217 posts

Re: Wi Flag (2002)

#91
post #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

One of my favorite things in gaming is when lore develops from bugs. When they added the ability for Kerbals to be killed in Kerbal Space Program, they tripped over a bug where the first Kerbal in the game's engine, Jebediah (the one who dated back to the original introduction of astronauts at all, where only one existed), could not be killed. Because of some of the game logic having gone unmodified from the earlier…

The KSP community has lore about the Kraken. They will joke about anything.

Re: Wi Flag (2002)

#92
post #82

What am I missing here? Unless all the devs were really bad at maths (unlikely if they're game devs) then this seems like a really easy bug to find all things considered? I thought maybe it was going to be some weird DB glitch or something far upstream from the algorithm selecting which player to attack, but it was literally the logic of the very algorithm you would first look at if you were aware of such an issue. T…

I'm missing something here and it has nothing to do with math.

Why couldn't they reproduce the problem in testing? For what was it, years?

Re: Wi Flag (2002)

#93
post #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.

A better way is to assign some internal salt to the feature at creation time and use that, that way you are not dependent on something external that user (the creator of the feature flag) could change. I bear the scars of this design mistake from when I worked for a company that provided feature flagging. It was not my initial mistake, but I drew the short straw trying to work around it.

Re: Wi Flag (2002)

#94
post #44

Around 15 years ago, when casual little games on Facebook were still a thing (actually when Facebook itself was still a thing), I used to play Yahtzee on the site while watching TV shows or whatever. It was one of the most popular games on there. For me it was something to fidget with (there was no money involved or anything, just a personal high score), so I played it a lot. I felt more and more that dice values of…

You stopped playing because they listened to you and fixed the bug for everyone?

I sent a patch to a bigger and more known software company, now defunct. I ended up writing some rude comments in the bug submitting form, after being forced to enter endless data about me, the company that I worked for and a lot of information about how to reproduce the error. Not proud of it, but I understand the GP: you're helping them and they treat you poorly.

They included the fix in the next version of the tool. I later noticed it was incomplete, but this time I just made the correction locally.

Re: Wi Flag (2002)

#95
post #11

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…

> A unit test could have caught this I've always wondered the best way to write tests for "This event should happen x% of the time." Obviously we could re-run the test 100 times and see if it happened close to x%, but not only is that inefficient, how close is "close"? You'll get a bell curve (or similar), and most of the time you'll be close to x but sometimes you'll be legitimately far away from x and your test wil…

This is pretty hard to black-box test.

What would have helped in this case:

* Test that all players can be selected by the algorithm at all

* Test that the totals of the weights is the same as the RNG max range

Re: Wi Flag (2002)

#96

Earlier quoted context omitted.

From what I recall it was a character named Wi who was persistently vocal about it.

This is the correct answer. Wi was a prolific blogger and fun personality.

would love to know how “bad” Wi's hash actually was, like what percentile of the users DB sorted higher/lower than it

Re: Wi Flag (2002)

#97
post #82

What am I missing here? Unless all the devs were really bad at maths (unlikely if they're game devs) then this seems like a really easy bug to find all things considered? I thought maybe it was going to be some weird DB glitch or something far upstream from the algorithm selecting which player to attack, but it was literally the logic of the very algorithm you would first look at if you were aware of such an issue. T…

Systematic debugging flaws probably; and lack of tooling to easily isolate.

Systematic flaws: a cross between groupthink, early flawed assumptions, deference to team leads, a 'I just look for 1hr, if I can't find move on' (which leads to not looking), or just plain simple "reading" instead of searching.

Lack of tooling: many game engines are infamous for lack of control over tooling. I havent used many, but I understand it would be quite an effort to run meaningful parameterised or structured fuzz testing on most systems. This makes it hard to artificially confirm suggestions. That said, there is practically no excuse for them not to just add a bunch of counters to the game - even on their internal testers it would very quickly become clear there was a bias.

Most of my 'should have caught it earlier bugs' are of the 'deference to lead' variety. I looked, didn't see immediately, handed off with some notes, and then the follow up debugger(s) took notes or thoughts as gospel. This is really hard to fight - I write something along the lines of "my hunch is there is a problem in code x because it handles y and is poorly structured/tested. I checked z and found i, j - queries as follows" and then find the debuggers effevtively refuse to look anywhere past x. This is particularly true for a group of debuggers, who play chinese whispers with groupthink and invent reasons it must be x.

Re: Wi Flag (2002)

#98
post #89
post #69

Earlier quoted context omitted.

After I (happily!) did their work for them, a simple "thank you", or even an acknowledgment through a closed ticket, would have entirely sufficed to make my day.

Or maybe the bug was closed as a duplicate of one they were already aware of? Still impolite of them, of course, but we shouldn’t assume the worst.

[deleted]

Re: Wi Flag (2002)

#99
post #23

Hmm, when they told me they were assigning people to a list I kind of knew what the answer was going to be. What is curious is that it took them a long time to find. I’d think that -as long as you believe there is a bug- this should be fairly straightforward to spot.

> I’d think that -as long as you believe there is a bug- this should be fairly straightforward to spot.

This is the power of continuous integration.

There's a certain amount of optimism needed to keep going as a software developer, and then there's the crippling amount of optimism that a lot of people have which makes for difficult team dynamics. CI says it doesn't matter if it works on your machine, it's red on a neutral box so fix your problems or it's not going into the release. It's much harder to ignore Jenkins than to ignore David.

People learn through trial and error that the Wally Filter works on bugs, so denial is their first and best defense. Prove to me there's a bug. I won't spend any time on it until you do.

Re: Wi Flag (2002)

#100
post #90

Really didn't expect to see AC at the top of HN. Asheron's Call was the first game I worked on and I remember all the times we'd joke with Wi about it and watch monsters beeline for him. It seemed like one of those "Haha sure, player perception" problems and not something that was actually real. IIRC someone did a very cursory look at the code at one point but it never bubbled up as important enough to assign someone…

Sorry, who is Wi?
Post reply on HN