Optional exchange draft
This feature request is fully implemented
In TACLog all data files used by the program are "compiled" into a Pascal "record" type format (continuous file) and each included record is "tokenised" to denote start and end.
The Verified Optional Exchange (VOE) files have a text source and an accompanying program (VOE.EXE) to compile them to [WHAT-OE].VOE for direct use by the program. This part may be unnecessary in Tucnak.
The format of the VOE Text file is straight forward:
! By: G1OGY 19980806 ! ! 1 2 3 !23456789012345678901234567890 ! ! RSGB District Codes [RSGBDC;0] AB 3 Aberdeen AL 1 St Albans BA 1 Bath BB 1 Blackburn BD 1 Bradford BH 1 Bournmouth BL 1 Bolton BM 1 Birmingham BN 1 Brighton BR 1 Bromley BS 1 Bristol BT 6 Belfast
It has a maximum field and record length, comments prefixed by `!'.
The numeric field defines how many times the OE can be counted for multiplier: both in running score and in final EDI calculation. For this reason, I had to load my Tucnak-created EDI file into TACLog after the RSGB 144MHz May contest to obtain the correct multiplier totals and thus the correct score. Even though Bo included this counter field universally, it would seem that it is used only by the RSGBDC VOE as all others I have reviewed have a `1' in this place. (more VOE text files can be obtained from Bo's web site!)
Of course, I found it necessary to extend the listing of RSGBDCs to include two 'extra' OEs. We work Non-G stations in every contest. Without a 'special' OE to add for non-G stations the "Must include OE" feature failed. I added "OO" [nO cOde] and "XX" [code not sent or captured] with a numeric value of ZERO (so that these did not affect the score). I guess that a similar trick may be necessary for other VOE files too.
So, there are two features involved:
- it is not possible to enter an OE that does not appear in the list - Verified.
- when an OE can be claimed more than once for multiplier, the file is used to check against an incremented counter (array?) in order to determine and calculate the correct number of multipliers.
The value of Feature 2) is obvious, but perhaps only relevant to the UK and RSGB contests using postal districts. It is possible, if tedious, to calculate this by hand where necessary. An important point regarding this is that the RSGB VHF Contest Committee RESCORE all logs submitted using their adjudication software. Their totals will be "accurate". (I have to confirm with the VHFCC regarding the way they will deal with inaccurate presentation of totals on an entry.) BUT how many UK contesters will be pleased to convert to a program that does not correctly deal with UK Postcode contest multipliers? Is this important for Tucnak (and it's author)? (I am OK because I have TACLog and understand how it works if I don't want to count multipliers on my fingers - HI).
Feature 1) is a mechanism for avoiding errors. When a new (postcode) multiplier can mean an additional 100K+ contest points this is quite important. That said, it is not that hard to key the received data accurately, but it is of assistance in catching typos or data incorrectly sent.
Conclusion.
It appears to be a 'nice to have' feature overall - most OE contests in Europe will only make use of feature 1).
RSDBDC contests (6 contests plus 144MHz Backpackers series) appear to be the only ones likely to make use of feature 2)
-- Dave Gilligan, G1OGY