So now that we have the repro, do we have a fix for it [the golf ball bug]?

It's a little bit up in the air, actually. We put in an initial fix for it that tried to prevent the PMA from making alterations when it's in this uncertain state. Effectively, the PMA operates using a lot of asynchronous operations. We need to make a request to the server to get the current persistent loadout of the player and all of the items that could potentially go on any given item port. Additionally, there's many chains of asynchronicity in the code itself. So you have the Flash on the front end, but then that needs to talk to something in code. And so we have the Flash, which talks to something called the context component, and then it itself fires events to something called the provider component, which then coordinates using a bunch of remote methods to send requests to the server. And then we get responses and we change back and forth. So there's lots of opportunities, when you have these kinds of timing operations, for things to go awry. And so clearly we were playing a little bit fast and loose in this particular scenario. And we tried a couple of solutions to try to make a small change to fix the problem. You know, 3.0 is out. We don't want to make some large change to the code to try to fix this bug and then introduce four or five more. So we tried small changes to fix it. They started to fix it, but you could still get it to happen with a little bit more dedication. And then QA was yet again able to find a more reliable set of repros because they were looking at it longer. And this even led to finding some other bugs that we didn't even know were there, like spawning small ships in the actual game. We won't get into that. So anyways, long story short, long story long, we ended up doing a more comprehensive set of fixes. I helped a bit, but a lot of it was spearheaded by the UI guys in the UK. And effectively, there's a set of changes that probably fix it, which is: don't make changes to persistent data when you know you shouldn't be. So if you haven't actually changed anything, don't allow a save. Don't allow saving data when you're still waiting on something to finish. So if you've made a request for some data and you haven't gotten a response, don't save the data. And also prevent immediate transformation of the data. So whenever you open the screen, or after you've made a change, you shouldn't be able to, the next frame, again apply a change to that data. So basically it's reducing all these opportunities for incoherent data to make its way in when things are still in motion. And it looks like we've got mostly a fix, and I need to look at my email and see what QA is saying right now.

Yeah, this is a fix that's currently in testing in a 3.0.1 patch that's with Evocati right now, right? So we are currently testing potential fixes. I know we rolled out one version of 3.0.1. We're getting ready to roll out another version of 3.0.1 soon. By the time this airs, we'll probably have done one, maybe even two more.

I mean, I've helped with a lot of other 3.0.1 patches as well, and this is kind of the last one that won't [die]. But I think maybe we've got the bullet for it now.