Challenges: My issues

Question

Love the new my issues page.

Except that the 10 examples are logged against the checker, and are thus repeated for each tag on that checker. To solve a checker problem we really need them logged against the tag, in case it is a tag parameter that is causing the problem, and so that I can see what they should be getting.

 

Thanks,

Tom

Answer 1

They are tested against each tag. The same name occurs on each tag because the user are tested on different challenges.

If it is the same user on many tags the problem are probably the same.

I suspect it is basic members and checker that use coordinates because the are false on premium cacher for them.

If you edit the checker script thy will all be cleared.

 

Comments

You can test this by changing the values to false
set the first cache in the result of PGC_GetFinds
myFinds[1].latitude=false
myFinds[1].longitude=false

Or on every cache in the find depending if you use the coordinates on all or only some caches.
Remove the testline when everything work.

edit: change index to correct 1 instead of 0

---

The are false not nil and the first index is 1 have changed the exampe

---

I am sceptical on this. The same users are listed on all 53 tags, even though the tags are for many different countries. It seems very unlikely that having failed on 30 tags, they would try yet another just in case. It looks more likely that although they are tested on each tag, the issue is stored against the script, not the tag. This makes fault finding (in general, not my case specifically) harder. The list should show the individual tags the person failed against, and not list that person against every tag.

Thanks for the tips on how to fix the problem in my script. There is another script of mine that will need the same fix. Will be fixed shortly.

---

the result that are used to create the page is stored in the database like the dump below. Sen to ganja to me when we tried to find out why a checker had a problem. It was the elevation that was nil in that case

| user_id | tag_id | last_run | status |
+---------+--------+---------------------+---------+
| 5650254 | 1307 | 2015-01-29 15:26:44 | success |


You problem is probably from your Generic minute of degree checker with lines like i copies below. and the problem is that coordinates can be nil for basic members.
507    the Seagnoid    6180    Target.    M9T, Suprcel, matouj, Ankarcrona, Mark-n-rara, Drejan, thefoxisblack, Rtreds, Aludii, lelle1987

The checkers are not runed by the users but by pgc in the background.

---

There are two problems being discussed here.

One: I have issues with a checker. I have just fixed the checker, Thanks very much for your posts on where I had gone wrong. Now I have to find me a non-premium person to test it. Have also fixed my minute range checker, which would have had the same problem. This has nothing to do with my original post.

Two: The way the issues list is displayed, which is what my original post was trying to raise.
While I believe you in that the page is created from that data dump, I do not believe that is how the displayed table is built.
Let's pick one person - thefoxisblack. This person has never been to New Zealand, and you are trying to tell me that although he checked 30 challenge tags, he went on to check ALL the rest of them? Even though they apply to challenges he cannot possibly complete? I would have given up after trying just 5. Trying all 53 is behaviour that borders on idiocy - I don't believe people are that stupid. Sorry Target, there must be an error in the SQL logic, that causes him to be displayed against EVERY tag.

And since I have fixed my checker, that list is gone. Hopefully you/Ganja can regenerate one for testing.

Tom

---

I am saying that project-gc runs the checkers in the background for users for upcoming features.
The process is to run it on all checkers on user at the time because then the sql server don't have to be used on all pgc_getfinds because the querys can be cached on the computer that runs the lua script. And probably script by script because that will most likely increase the number of cache hits.

That also result in that the same users are listed on all tags for the same script.
You can actually test this. If you run a user that have the basic member problem on a tag the result will be stored as ok and a refresh on the issues page will remove that user on that tag and will still be there on the other tags.
I have tested that.

---

Ahh! Now I understand! They are not real users using the checkers, but server side checks. Thanks, Target. [:)]