zex20913
Level: Smitemaster

Rank Points: 1723
Registered: 02-04-2003
IP: Logged

I think I recall a request a while ago about sorting the high scores lists--when we sort by average points, there are 4 players who have solved one room, receiving a 1st place tie. And that's it. Two others have fewer than 10 rooms solved (though one of them does have a 1st.)

When sorting by average rank, there are 8 people with fewer than 10 rooms solved (5 with only 1.) I still would like a "minimum roomcount" for people to get to the top of that list. That would give a better view of the high scorers.

____________________________

Schik
Level: Legendary Smitemaster

Rank Points: 5413
Registered: 02-04-2003
IP: Logged

That would be great, but oddly it's harder than you would expect.

I'll keep it in mind though, maybe an elegant solution will come to mind some day.

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

eb0ny
Level: Smiter

Rank Points: 484
Registered: 09-12-2007
IP: Logged

Could you explain this sorting by average points thing? Your explanation isn't very clear and want to try to come up with an "elegant" implementation.

____________________________

zex20913
Level: Smitemaster

Rank Points: 1723
Registered: 02-04-2003
IP: Logged

1. Go to the High Scores tab under the Caravel banner.

2. Click on the "Players" tab.

3. Click on "Average Points" or "Average Rank" to resort the information by that column.

Resorting of pretty much every column in that section is doable.

____________________________

agaricus5
Level: Smitemaster
Rank Points: 1838
Registered: 02-04-2003
IP: Logged

If it's too difficult to have people with few highscores not showing up on the main database, might a possible compromise be for individual users to be able to ignore these players on the highscore tables? For example, you could put a check-box to the left of each name; if you select it, it then hides that person's scores from showing up.

Does this sound like a reasonable idea?

____________________________
Resident Medic/Mycologist

---

[Last edited by agaricus5 at 03-24-2009 12:54 PM]

eb0ny
Level: Smiter

Rank Points: 484
Registered: 09-12-2007
IP: Logged

All you need is one WHERE clause away. If you are not using SQL in the back, the solution still comprises one IF statement and three lines of code. What hurdles are there, exactly? Or am I missing something?

____________________________

---

[Last edited by eb0ny at 03-24-2009 04:34 PM]

Syntax
Level: Smitemaster
Rank Points: 1218
Registered: 05-12-2005
IP: Logged

eb0ny wrote:
All you need is one WHERE clause away. If you are not using SQL in the back, the solution still comprises one IF statement and three lines of code. What hurdles are there, exactly? Or am I missing something?

I remember Schik mentioning in the past that the global highscore table was the most expensive (hence no longer the default when you click "High Scores").

I can only presume this means the table is generated from aggregate functions such as sum() group by user etc. A where statement doesn't apply to aggregate functions.

A "having" clause would allow a statement to select specific groupings though but I'm sure Schik has looked into this and that it's not viable for the current setup. Otherwise, a "having count(*) > 9" clause would solve the issue and ignore players with less than 10 demos, for example.

eb0ny
Level: Smiter

Rank Points: 484
Registered: 09-12-2007
IP: Logged

Makes sense, then. I was going to suggest to use a table, which contains all the required sums so they are not recalculated each time the high-score table is requested and are updated when new demos are submitted. But then it becomes somewhat problematic to keep track of #1 scores...

Well, if it was an easy addition, it would've been already implemented, right? Only Schik knows how the backend is set-up, so in this case he knows best.

EDIT: It just came to me. If data is fetched for every player when the table is generated, why not exclude the entries which do not match some condition AFTER they are all fetched, instead of checking the condition DURING calculations? This might be doable.

____________________________

---

[Last edited by eb0ny at 03-26-2009 03:09 PM]