When trying to validate a tournament in MUIR, validation may suggest that one of the tournament players is from the wrong state, SC, instead of NC. This discrepancy should show up only as a warning and not as an error, right?
Itâs a new validation filterâŚA player is not from the same state as the majority of players in the event. For clubs near borders, itâs extra noise. Learning to ignore itâŚ
Try it and see, but also imagine how many people from out of the hosting state attend national events.
Not just near borders. Itâs triggering on literally every player now. These players have known states in MUIR, most of which are LA, so I really have no idea why this error persists.
out-of-state issues should not prevent the tournament from being submitted, Iâm not sure they are as useful as the âDoesnât belongâ checks from the old system yet, though, which used a combination of state/zip code, birthdate and rating, only flagging those that met at least two of those conditions.. May need refinement (but that was the case on the old system as well.)
Mike,
Why is the system not validating against the MUIR state record for these players?
EDIT: Itâs looking at only whatâs in the TDEXPORT.DBF file, which doesnât have a state because the PTOZ that King registration exports doesnât have a state. Iâll follow up with Bill.
1 Like
Are you saying the state field is blank in the upload file? Whatâs the event ID so I can look at it?
Yes, I confirmed that the tournament files King outputs - whether .ptoz for WinTD or .sjson for SwissSys - do not include state codes, which leads to D_STATE being empty in the TDEXPORT.DBF file:
This event is US Chess
So this one is, well, not user error but tools error.
Iâve created a ticket suggesting that if the state field is blank in the upload file, that should not trigger a state mismatch. I wonder what happens with foreign players, both how King Registration handles it and how MUIR does?
2 Likes
Aside from out-of-state warnings, I saw something similar but different. Even if the upload files are wrong, most of my players matched a state in the database. Warnings were generated for a few new members because they didnât have states. I didnât understand it because I processed memberships with states. Anyway, I could edit the state at during validation. I forgot the UI pane to say exactly where.
Mike, can you send me the upload files (mnolan@uschess.org)? Iâm wondering if this was a data transfer issue or something else and if it would still happen now that the event is rated.
How were they entered into your tournament software though, I think is the issue - unless the tournament software had the state, they might have still been uploaded to US Chess in the report file with blanks.
Youâre right for at least one player. I donât remember who the others were at the moment. Files sent to Mike NâŚ.
King does the same as with other players, sends down no state or country information as part of the ptoz created for WinTD use, which leads to WinTD then creating a TDEXPORT.DBF with no state information. Our last foreign players have all expired now though so I donât have an easy way to test how it flows into MUIR (I got no state alerts after upload, but I did get expiration errors which might override).
Nolan, when dealing with an Alert that one player is from South Carolina in a North Carolina tournament, how is that dealt with in MUIR when trying to validate a tournament? What is done so that the Alert is removed?
You donât do anything, just submit; an alert doesnât stop the tournament from going through.
It might be nice to have an âignore state issuesâ option, though, especially on larger events. But I donât see that as a high priority enhancement.
Events in Omaha NE frequently draw players from Council Bluffs IA, and vice-versa. A distance measure based on player and event ZIP codes is probably a more reliable check, but requires access to ZIP code latitude/longitude data and some math. This was used in enough different places on the legacy system that there was a zip-distance function that looked up two zip codes and computed the distance between them. MUIR does not currently have a ZIP code latitude/longitude table. (If you wanted to get REALLY accurate, you could use a ZIP+4 database, itâs much larger and more expensive to buy.)
Historical note: The idea of looking for âDoesnât Belongâ players in an event was triggered by an event from the late 90âs in which the ID for a master from NJ was mistakenly used in a California scholastic event and the master lost a bunch of points, and was not happy about it. I think the legacy system had a two-factor approach, it looked at state differences or ZIP code distance, age and rating, and if a player looked out of place on 2 of those, it triggered a warning/alert. This was separate from the high/low âperformance ratingâ warning.