Quote from: ibminer on June 10, 2021, 06:16:50 PM

Quote from: suchmoon on June 06, 2021, 07:14:04 PM

It's sorted by time, but when multiple records have the same timestamp the sort order within that group is undefined so it can be kinda random. I'd like to say I'll fix it but this might take a while

I can try to work this into the development site over the next few weeks, should just be a secondary sort that needs to be added into the query.

I assume it makes sense to use the username, alphabetical, as the secondary sort.

Instead of adding anything, switching the sorting to the 'id' itself seemed to be the best solution. Assuming everything is as it should be, I believe this should always still coincide with the timestamp, but it keeps the /TrustLog page less jumpy. It was a simple switch, so I've made this modification live as well. Might have to switch it back if I did something stupid.. but it seems more stable now. Grin

Quote from: Timelord2067 on July 02, 2021, 07:58:44 AM

Hello again,

Just a quick question if I may: What is the highest number that BPIP scores go up to? I was always under the impression it was just one thousand, however, I've noticed recently UID's with much higher scores.

Regardless of what is displayed on the site, because ranks are based on calculations, these calculations could be applied to any user.. but it does require more resources, and isn't really necessary to run the calculations on everyone for the website. Only the top 1,000 are currently displayed/calculated on the website, but there are intentions on increasing this to maybe 10,000 once we can do it across the board. The extension specifically calculates the recognition values/ranks past 1,000 and lists that as the BPIP rank.

Quote from: Timelord2067 on July 02, 2021, 07:58:44 AM

I also figured out the ranking of users with the same score is based on their registration date instead of giving each user the same score/rank giving earlier registered users a nudge up the totem pole...

The "Most Recognized" rank in your example does not intentionally do any sorting based on the registration date. The only calculation done is listed at the top of the most recognized page.

However, I'm guessing because SQL processes the tables with profile ID's in order, the lower/older userIDs will probably get processed first, which would get them ranked first.

It's not intentional, but as it stands now, I don't see a huge issue with this personally. It could be something adjustable in the future but I'm not sure it is a huge issue at this point.