Thank you - that explains why I’ve been getting black so often in my correspondence games; my correspondence rank is two stones behind my overall rank.
I shall start restricting the rank of my challenges according to my rank for that game-type. That way I’m more likely to get an even split on colours. Thanks for your help.
We’ve cleared up the colours, but I realise one question remains; when I restrict the rank of a challenge, which rank is that challenge restricted to?
For example, if my correspondance challenge is restricted to 10 kyu, will my opponent have an overall rank of 10 kyu or a correspondance rank of 10 kyu?
I see so if we were even in say blitz but lower overall and we beat them in a blitz game… our blitz rating would only go up a little but we’d see a bigger jump in our overall?
Annoyingly, it appears that the Restrict Rank feature on challenges ignores the game-type, or at least allows the overall rating to qualify you for accepting the challenge.
I’m going to search for the rank restricting feature in the codebase - maybe something obvious will come up.
I’m not going to pretend to understand TypeScript - in fact I’d not heard of that until a few minutes ago - but this line determines the eligibility in the SeekGraph and that appears to check a generic data.get("user").ranking value.
I’m going to see if I can find a class with a ranking property, but my suspicion is that this is some sort of User class and that ranking evaluates to the overall rank.
This corroborates the idea that properties named ranking tend to correspond to a players overall rank, rather than the relevant game type. Unfortunately actually understanding this code enough to draw any conclusions is a bit beyond me right now. All I’m doing is speculating.
One final clue, we set a value called move_time using another property that e has called time_control_parameters.
The following seems probable:
Whatever e is, it has time_control_parameters which we can probably use to determine the game type.
We have access to data.get("user").ranking which means we probably have access to data.get("user").ranking_blitz etc.
We can therefore calculate the relevant ranking before going into our eligible block and implement the feature properly.
However, I think I may have thought about this enough for one evening. Is there a dev around who knows the codebase/this language? Am I on the right track here and can you tell me:
Are the things I’ve highlighted as probable true?
Are there other parts of the codebase that would need to be updated, e.g. the API?
Yes, absence of comments seems intimidating. I will wait and see whether @anoek is able to corroborate my findings.
Until then, I think I shall just resume restricting the rank of my challenges to my over rank, and hope that my game type ranks just make more sense over time - a shame, I had a game with the white pieces last night!
Upon reflection, this isn’t a serious issue so long as I ignore the game-type ranks. In other words, by restricting challenges to my overall rank, I can pitch my opponent’s overall rank against my own.
Of course, it’s unfortunate that colour is not decided by the same criteria as the challenge’s rating restriction, but I think I can deal with it