submitting tdexport tsexport and thexport

Hi. Our chess club uses wintd, but we have a program that does accounting and pairings. We recently added a module that converts the pairing list to the uscf required rating report files tdexport tsexport and thexport.

Now the problem is how to get the three files to uscf. We’re trying to get away from wintd because it’s a PITA to enter the data each week when we already have it in the pairing program which I wrote.

Any suggestions? Please do not suggest wintd or swisssys or vega. Unless wintd will accept the three rating report files. That might work.

Can’t you upload the files in the TD/Affiliate area on uschess.org the same way you’d upload files created by WinTD?

Yes, they should be able to do it the same way. I’m also trying to figure out what data they’d have to enter each week other than wins and losses? Although I’d love to see TMS continue to evolve to help run all aspects of an event.

You need to be really, really careful about how you construct those. I remember someone taking the output from WinTD and editing one field using Excel (rather than fixing it in WinTD and redoing the export) and it totally messed the file up.

If your dbf current formats are not exactly correct then, in the unlikely event that you don’t need color information you could use the Import Cross Table option (for existing tournament sections under the section tab) and pull in the information so that WinTD can then generate the output files (take an existing WinTD program and do an export first to see the format needed for the import). That would be an interim step until you finally got everything going to good dbf files.
Other program may also accept imports but you already have WinTD.

Purely out of curiosity how similar are the pairings between your program and WinTD? (the question may be irrelevant because your club might have pairing methods that do not match the normal Swiss, round robin or 1vs2 pairing methods WinTD has)

Tom’s program is very good at pairings and I only rarely see a pairing that looks like it needs to be changed (and in only a small fraction of those cases does it actually need to be changed). My experience with SwissSys is two decades old and I have no experience with Vega so I can’t say anything about the way they currently do pairings.

If you have ease of use, interfaces to the US Chess Golden database, web export capability, good pairing logic, good tie-break calculations (for non-divisible prizes that take into account both overall and limited prizes), good distribution calculations (for monetary prizes that properly take into account both overall and limited prizes), good ratings report generation, and you have good accounting functions then you might have something that could be marketed (after also including anything I overlooked but is still needed or desirable - such as easily texting pairings).

Our communitychessclub.com runs a ladder tnmt. each Wednesday. Players with similar ratings are paired. I wrote it in html5 and javascript. Getting the first row dBASE definitions was simple a matter of leading sample thexport.dbf, tsexport.dbf and tdexport.dbf into LibreOffice Calc and pasting that line into javascript.

As you probably know …

<script>
tsexport_tmp = "S_EVENT_ID,C,9	S_SEC_NUM,C,2	S_SEC_NAME,C,10	S_K_FACTOR,C,1	S_R_SYSTEM,C,1	S_CTD_ID,C,8	S_ATD_ID,C,8	S_TRN_TYPE,C,1	S_TOT_RNDS,N,2,0	S_LST_PAIR,N,4,0	S_DTLREC01,N,7,0	S_OPERATOR,C,2	S_STATUS,C,1";
// 190911001	 1	CLUB GAMES	F	R	12484800	12578256	S	1	26	1	XX	#

tdexport_tmp = "D_EVENT_ID,C,9	D_SEC_NUM,C,2	D_PAIR_NUM,C,4	D_REC_SEQ,C,1	D_MEM_ID,C,8	D_RND01,C,5	D_RND02,C,5	D_RND03,C,5	D_RND04,C,5	D_RND05,C,5	D_RND06,C,5	D_RND07,C,5	D_RND08,C,5	D_RND09,C,5	D_RND10,C,5";
//190911001	 1	   1	1	12484800	L   2	    0	    0	    0	    0	    0	    0	    0	    0	    0
//190911001	 1	   2	1	12704446	W   1	    0	    0	    0	    0	    0	    0	    0	    0	    0

thexport_tmp = "H_EVENT_ID,C,9	H_NAME,C,35	H_TOT_SECT,N,2,0	H_BEG_DATE,D	H_END_DATE,D	H_RCV_DATE,D	H_ENT_DATE,D	H_AFF_ID,C,8	H_CITY,C,21	H_STATE,C,2	H_ZIPCODE,C,10	H_COUNTRY,C,21	H_SENDCROS,C,1	H_SCHOLAST,C,1	H_SECREC01,N,7,0";
//190911001	CCCR WED NIGHT CHESS 091119	1	09/11/19	09/11/19			A6000220	ROCHESTER	NY	14610	USA	N	N	1
</script>

Yes, It’s right on the website at https://secure2.uschess.org/TD_Affil/tnmt_entry_new.php Thank you!

I don’t bother trying to figure out the dbf because WinTD handles that for me. Kudos to those who can do all of that.

The real question was what type of pairing you were doing. Since they are players with similar ratings that is either 1 vs 2 within a scoregroup (which WinTD does and others probably do) or regardless of scoregroup (which would be special for your club and designed for a lot of close games)

My program is not deluxe like wintd. It’s just a hobby based program cobbled together by me, an amateur developer. I spent about $400 on programming fees thus far. I get experts to do the heavy lifting and I concentrate on idea development and front-end UI. I have an accounting module that uses an external json data file from USCF data and another for club memberships. It looks up the ratings using autocomplete from jQuery and sorts the plays in descending order. That is displayed color-coded in moveable squares with jQuery sortable. The last phase of this will be the rating report.

if you send me your zip code, perhaps I can download the needed USCF local info and post a sample for you to see. But it only works in google chrome and opera. You are a TD, right?
That’s a testimony to my limited programming abilities. oops, I can’t do that. Unless I can get some legal sample USCF data, the program won’t work.

USCF rating dept. wants to know which players played, the dates games were played, the results. I doubt they really care about Swiss or RR designations.

If the game data is entered in the format “result-opponent number-optional color” (without the dashes), then by definition it is in swiss format. In RR format, the opponent number is pre-determined by the round number. There is no double-RR format.

Color information is only supported by one of the DBF formats. whether there will be a new upload format made available as part of a rewrite of TD/A is one of the issues that our new development group will likely be working on, with input from staff and others, I’m sure.

There’s probably a lot of things that tournament management systems (TMS) could do to help organizers that they don’t do today.

Most likely the first visible aspects of the back office rewrite will be using CiviCRM for membership transaction processing. This will likely replace the membership webstore membership form(s) and the TD/A membership form(s). Developers of TMS packages may want to become involved with CiviCRM if they aren’t already.

I have already suggested to the new developers that one thing they should build into their plans for a new MSA and/or TD/A site is rate-limiting the amount of data that can be requested. We’ve seen (poorly written) web-scraper tools try to download thousands of member records in a few minutes, the website is not built to handle that kind of database traffic.

It may be possible that CiviCRM-compliant packages could have different rate limits than other tools.