Congratulations and thanks to all involved. It appears that the January supplement is available, and in a very timely fashion. I have it working with SwissSys. What a difference a month makes! During the last supplement generation I was getting a little discouraged. I submitted a tournament last night and it was queued for a bit but was processed overnight. Although I’m not one who enjoys change, I’m beginning to think this will all work out. One little nit - might we have the file that WinTD needs uploaded soon?
1 Like
You mean the all players file? That’s at the top of the list, but the file name will need to be changed because WinTD expects it to be named ‘rtglist.txt’ not ‘Uscf-2026-01-AllRatings.csv’,
Right now I don’t think the pairing programs can automatically download these files from MUIR because they’re behind the Muir TD Portal login. Once that issue gets resolved, Tom will probably update WinTD to know the file’s new name.
Right. Are you going to put this out at https://secure2.uschess.org/supplements/ALLRTG2601.zip, similar to what you did with December’s ALLRTG2512.zip, so that current versions of WinTD can find it?
I have to do that manually and it may not get done until this evening.
2 Likes
Just wanted to make sure it didn’t fall between the cracks! Thanks.
January Gold Master and ALLRATINGS files have been posted on the legacy website.
Thanks, Mike. You’re working late. I updated WinTD and all the records that I checked are correct. The “0 for unrated” problem seems to be solved, although now I have a WinTD mystery. A few players are assigned 0 ratings by WinTD, even though when I look in rtglist.txt they have blanks, not 0s as happened last month! I deleted all the relevant files from my folder and started fresh, and it still happens. Strange.
Send examples and I’ll look at them when I can. I’m on the road at the moment and have little access to the net.
Mike, you are off the hook on this one. I’m 99.9% sure this is a WinTD issue, not a supplement issue. If any WinTDers are curious, I’m happy to expand on it, but I don’t think it’s a problem with the supplement.
It’s working for me now, and I doubt something got changed in the last 4 minutes in this regard.
…I note that it is also available in the former monthly location.
Now it is working but I noticed something with the new files. It looks like there are a lot of null expiration dates. What do those mean? In the past files, all the players had expiration dates (including in last months files that I got from the ratings site directly)
The files probably have more of the non-members records than they used to have, because we’re still getting the mapping of codes from CIVI-CRM to MUIR straightened out. There are about 154K of them on the January files,
If we got rid of all of them, we’d probably wind up with duplicate IDs being generated for those who have IDs but no membership. (I recommended putting in an expiration date like 1900-01-01 rather than leaving that field null, but that’s not the way it was implemented.)
spot checking a few I see a lot of them were 12/31/99 last month. Should all of the nulls be treated as never expiring ?
No, a lot of the 12/31/2099 ones last month were erroneous. (I thought we released a corrected file for those, but I may be mis-remembering things)
These are individuals who have an ID but have never purchased a membership.
This is not the case for at least the first four examples displayed above. John Logue - 10000238 - appears to have an expiration date on file of 1986-06-30; why that didn’t transfer through to MUIR is unclear.
Similarly, Emilio Rodriguez in the next row has an expiration date on file of 2001-12-31, J Bienvenido Rodriguez below actually is a life member (if inactive) at 2099-12-31, and Manuel Ormaza expired 1992-05-31.
Also
https://www.uschess.org/msa/MbrDtlMain.php?10000726 (life member)
https://www.uschess.org/msa/MbrDtlMain.php?10000947 (deceased life member)
…so far, every single one has an expiration date at MSA.
The issue is that the old membership system that I wrote had one way of coding memberships (type, expiration date, status, suspended, etc), CIVI-CRM uses a different way of doing it and MUIR a third way of doing it, so we had a conference call a while back to try to set a full mapping from CIVI-CRM (now the definitive source of information) to MUIR.
It definitely doesn’t seem to be mapping quite right at the moment - “null” as “expired” I could almost make sense of, but “null” as “inactive life member” seems wrong.
We do have over 2000 inactive life members, they’re inactive because they did not respond to a series of website notices and requests several years ago. We didn’t have a valid mailing address or an email address on file for many of them, and a number of them are most likely deceased.
I think a handful of them have been reactivated after they contacted us.
The office may do another series of contact request for active life members again in 2026 or 2027. (I think the Bylaws authorized doing it every five years.)
We did the mapping recently enough that I don’t think anything has changed yet.
I think the current practice is to only have 2099 or later expiration dates for active life members, around 8000 of them. (My dislike of null expiration dates is fairly well known.)