ID:121916
 
Resolved
If a hub path included an underscore but one was not included in world.hub, medal caching failed.
BYOND Version:493
Operating System:Windows 7 Home Premium
Web Browser:Chrome 15.0.874.121
Applies to:Dream Daemon
Status: Resolved (494)

This issue has been resolved.
Descriptive Problem Summary:
Operations to get or update medals will often fail.

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
world
hub = "Forumaccount.TestGame"
hub_password = "BE9YTsqX1m859duH"

mob
Login()
..()

world << world.SetMedal("Medal #1", key)
world << world.SetMedal("Other Medal", key)
world << world.SetMedal("Number Three", key)

world << world.ClearMedal("Medal #1", key)
world << world.ClearMedal("Other Medal", key)
world << world.ClearMedal("Number Three", key)


Expected Results:
It depends on the status of each medal initially. If you have none of the medals, you'd expect to see six 1s output to the message log with a small delay in between each one appearing.

If I run it when I already have all three medals, I'd expect to see three zeroes appear then three ones appear, all with small delays before appearing.

Actual Results:
If you had none of the medals initially, you see three 1s appear with a small delay before each one, then three zeroes are output immediately. These zeroes returned by ClearMedal() mean that you don't have that medal, but I clearly do.

If I run it when I already have all three medals, I see three zeroes appear with small delays before each one, then a 1 appears after a small delay, then two zeroes appear immediately.

Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
I've also had problems getting a list of medals. It would be nice if the world.GetMedal and SetMedal procs always hit the hub. If I wanted to cache the results myself and try to guess when I don't need to contact the hub, I could, but I'd always have the reliable procs that hit the hub each time for the cases where I want to be certain and don't mind the delay.
SetMedal also returns 0 immediately if the player is not authenticated. A return value of zero means "the medal was already awarded", but that's not the case here.
Any word on this? Do other people have these same problems? Is this really a bug?
I haven't noticed any problems with setting/getting medals, but I also don't clear them...
Falacy wrote:
I haven't noticed any problems with setting/getting medals, but I also don't clear them...

Do you see the behavior I described when you run the test?

I've also noticed problems when getting a user's list of medals. It seems like the most common operation people perform is to award a single medal, and that appears to work more reliably. It's all the other operations I have problems with.
I'm almost certain that the longer a game is running, and the more times medal related procs are called, the slower and less likely to complete it is.

Of course, we're talking about games running over a period of days/weeks and after hundreds of call attempts. I can't prove it, but I think I managed to reduce the load, and the slowtime by managing the medal data in-game and only calling it when absolutely necessary.
Any word on this? Has the staff been able to reproduce this problem?

Acebloke wrote:
I think I managed to reduce the load, and the slowtime by managing the medal data in-game and only calling it when absolutely necessary.

I'd like to do that, but if the procs to update medals aren't reliable there's no way I can reliably manage medals myself. I'd prefer if the world.GetMedal, ClearMedal, and SetMedal procs *always* hit the hub and it was up to me to cache the results myself to determine when calling world.GetMedal wasn't necessary. The behavior I'm seeing suggests the world.ClearMedal proc thinks it doesn't need to hit the hub, but it really does.
Very sorry .. we are going 100% to get this site update out and then will visit this and the other bugs that have backlogged in the time.
Any word on this yet? I was thinking about turning this into a feature request to have a way to force these procs to contact the hub.
I meant to post an update on this a while back, but I ran some tests some time ago and was unable to reproduce the issue of failing to contact the hub. This was when using test code just like that which you provided.
Lummox JR changed status to 'Unverified'
It wasn't failing to contact the hub, it was thinking that contacting the hub was unnecessary. If it failed to contact the hub it'd return null but these calls are returning zero.

Would it be possible to make the medal procs always contact the hub (it can be an additional parameter)? That way I can avoid this problem and can cache the results however I'd like to. I'm not even sure if/how it's caching works when you have multiple game instances open.
With multiple instances I could see there being an issue; medals should be sent either right after the server requests them, or on client login, and then the server keeps them cached. I supposed we could always make it contact the hub, but I don't know that it'd be wise.

But where I really ran into a problem was here:

If I run it when I already have all three medals, I see three zeroes appear with small delays before each one, then a 1 appears after a small delay, then two zeroes appear immediately.

I didn't see that. In my tests I was reliably able to see the correct results. Unless I screwed something up in the testing process, something's off. Our results don't match.
I'm seeing wrong behavior in just about all cases. If I don't have any of the medals and I run it, it adds the three medals and doesn't remove any. If I have all of the medals when I run it, it returns three zeroes (to indicate that I already had them) then it only removes the first one. I can provide a video of this happening. I'm currently running 494.1125, I'll try it in the latest version later.

It looks like once I call SetMedal or ClearMedal, every subsequent call to ClearMedal will immediately return zero. Is this just because the calls are sequential and the client limits how often it'll hit the hub? Would adding a delay help?

I supposed we could always make it contact the hub, but I don't know that it'd be wise.

I'm sure there are projects that rely on caching and would otherwise bombard the hub with requests, so it'd be best to add this as an extra parameter to skip the cache. Unless I'm using SetMedal() and ClearMedal() incorrectly, the caching appears to interfere with legitimate use, so I'm not sure what alternative there is.
The calls are sequential, but the commands should queue up. The weird thing here is that while I could see the caching getting in the way if the calls returned immediately, that's not the case in your example code nor in what I'm using. If you spawned off each call, I could understand the problem.

One thing I've started wondering about is whether your key is an issue. The path used by your game doesn't actually match what the hub would return. The caching routine would well be confused by that. If you use the underscore in your hub path, does the problem go away?
Actually this did turn out to be it. As a workaround for now, use the official hub path from the site which includes the underscore, and all should be well.
Lummox JR resolved issue with message:
If a hub path included an underscore but one was not included in world.hub, medal caching failed.
In response to Lummox JR (#16)
Lummox JR wrote:
Actually this did turn out to be it. As a workaround for now, use the official hub path from the site which includes the underscore, and all should be well.

So you weren't using the test code I provided =)
I was using similar code but with my own hub entry in an existing project; it didn't occur to me the actual hub path you provided was relevant to the issue.