It is frustrating to have to make several clicks to join a game, and then get an error message “Challenge does not exist.”
Please ask your developer to show challenges only while they exist, and to lock the challenge when someone clicks on it, so there is no time gap when the challenge does not exist.
Thanks.
I’m not a dev, but my money would be on that being a lot harder than it sounds. I think an automatch would be a better solution, though I don’t consider it a particularly important feature to implement.
It might be harder than it sounds, if distributed single-level locking were actually difficult, but it isn’t. It’s a fairly simple two-step process, and I can explain it to the OGS developer, if there is one. Locking is easy, and is the perfect solution for clicking a resource that might disappear while or after you click it. I use self-healing locking on my website and it has never failed.
I get the error message about 33% of the time, so, yes, it’s important to fix.
I’ve never got this error once so from my perspective it isnt an important thing right now
I think the reason may be that I currently prefer blitz games on 9x9 boards, in which challenges are quickly taken. You, like most Go players, probably prefer standard 19x19 games, where challenges hang around for a while.
Today I was unable to play since I get “Challenge does not exist” 100% of the time.
The scenario is: I login with Firefox, see a game offer I like, click the green Accept button. Now the window is greyed, and a popup says Loading… and nothing happens afterwards.
This popup window has an “Accept Challenge” button.
If I click it, the reply is a popup window “Challenge does not exist”.
Now the game offer is still in the list with game offers, but the
green button has been replaced by a black-on-white “Error”.
If I refresh the window, all is as before, and I can repeat this cycle.
@ploche, If you run any version of Windows, I recommend that you restart your computer then try again. Post here if the problem still happens. If this is a locking problem, I would like to talk with the developer.
Over a network the time taken to lock could easily result in others clicking and finding out the challenge is locked. It would make the window much smaller for an error to occur (would require dual clicking) but it would happen.
Basically, if you’re ever loaded into the game but you’re not one of the players, that’s how often an error would occur.
All in all I would support the change. It’s locked when someone opens the info box, unlocks when it’s closed or user DCs or open for X amount of time. It could be annoying though, having someone open a challenge and just sit on the info box because they run AFK and don’t know they’re locking.
Probably better than having to click the challenge through the info box as fast as possible on fast picked games.
Currently, we click on a green dot, then have to click again to get the challenge information. We then have to read it and decide if we want to accept the challenge. All of this takes time. By the time we have done all of this, the challenge may have been accepted by someone else. This is annoying, yet avoidable.
Here’s the improved process:
What I’m thinking is that when we click on the green dot, the Go app records us in a list of all the people who have clicked the green dot. The challenge is shown only to the first person the app detected. The other people get a “please wait” dialog box or a rotating wait icon. This is what I mean by locking. When the first person accepts the challenge, the “please wait” for the others disappears, so they can try again. If the first person refuses the challenge, the process continues by showing the same challenge dialog box to the second person, and so forth.
Now that I have thought this through, it is clear that the current interface is not the best one. Better would be a list of the current challenges as a row of lines, which can be sorted by the user by game speed, ranking, etc. Then when clicking a challenge line (or typing its number), one would start the game immediately. Note that in this second scenario, locking would still be needed, but I won’t bother to explain how or why until this better interface is accepted by the developer, since the details of locking are, well, just details. Locking is always needed when dealing with decision input from many people that can come in simultaneously. Locking is not a bad thing, it is good because it eliminates errors. Locking never causes errors, it avoids them nicely.
Remember, you are just “locking” at a different point. You want it to lock while you read the info box so that it can’t be “stolen” from you.
Assuming you’re referring to clicking the green tick though (rather than the mouseover green dot) I agree with this.
First person clicks the tick and the challenge window pops up. Anyone else clicks it during that time gets a “Please Wait” button instead of accept (can’t just be that though, needs to communicate that someone else got there first).
Then they either get a “Challenge no longer exists” and the box exits, or the button goes green and they can accept.
You’d need a countdown to accept though, so you can’t hold the lock indefinitely. Something like 10-15s probably before it tries to reacquire a new lock.
But yes, being able to filter the list would be super useful (you make it sound like the list doesn’t even exist).
I’ll point out that in your second example, if the instant accept list is the only way to accept games then no “locking” is needed, as it’s the exact same system as “Challenge does not exist”
“…needs to communicate that someone else got there first.” Yes, this is the heart of the locking problem, and it is easily solved by remembering the IP address of that first person, in a two-phase (or two-step) test. This is a simplification, as the entire decentralized locking algorithm does have some necessary complexities to work correctly over the net.
“You’d need a countdown to accept though, so you can’t hold the lock indefinitely”
Yes, great insight. A self-healing robust lock algorithm contains a timeout, to handle “wedged” states resulting from users being cut off from the server unexpectedly.
However, if we assume that the current behavior of the user workflow for selecting and accepting a challenge must be retained unchanged, then your description of how to fix the current problem will not work.
Locking must start with the first user action, in this case clicking on the first green item shown on the Play diagram. It must continue with clicking on the popup user information, and continue with the popup of the challenge information. If you would kindly re-read my description, you will see how it has to work.
But in the real world we don’t have to make this assumption that the process must look the same. Instead of a diagram of green dots, the process can be changed to be a dynamically changing list of challenges, with columns for username, rank, desired time specifications, desired board size, etc.
If we made such a change, the user experience would be far better, and locking would be different (it would still be needed for freedom from errors).
I hope this reply answers all questions and our discussion is done, because this replying takes time I don’t have. Sorry to sound rude, but I must move on, and I have done my best to explain.
I have been trying to accept a challenge, but each time I click “Accept Game” in the game review screen, it says “Challenge does not exist”.
Then I close that window, reload “Find A Game” page to be sure … and there the challenge still is. I did that a few times, the challenge hung around the whole time.
If this is a challenge that someone else is reviewing at the same time, then it might be better to say so 
It’d also be nice if there was some way that people couldn’t hold up a challenge in review indefinitely…
i’ve seen this also, tried to find the thread where i posted it, but cant, maybe it didnt get posted
You are right, there is a duplicate thread on this called “Challenge does not exist.” You can do a search for it, Although I believe I’m empowered to combine threads, I don’t know how to do so, otherwise I would.
maybe we need more threads
Thanks, I did it.
No, less threads for same or similar topics would be better because it’s too easy to overlook things here already. Keeping up-to-date with the forum is work.
But some of us really like threads. They keep all sorts of things tied together nicely. And they can be dyed pretty colors.
it was clear already that you’re, uhm, somewhat special (but then again we all are, no?), but I wasn‘t aware that you’re also a necrophiliac 
Turns out there are actually ten different, uhm, flavours 
of necrophilia, choose yours 
I think you don’t know how to spell. Dyed is a different word from died. 
It’s because you resurrected a dead post, I believe 