Let me start over on this as I think there are a few misunderstandings. * On 2018 11 Jun 12:07 -0500, Ervin Hegedüs wrote: > Hi all, > > On Mon, Jun 11, 2018 at 08:18:11AM -0500, Nate Bargmann wrote: > > One thought I had would be to create a parallel mults file definition > > using GKeyFile as the means for setting groups for mults, alias, and > > alias_mults. I am thinking along the lines of: > > > > [Mults] > > AL > > AK > > AZ > > . > > . > > . > > WV > > WY > > > > [Alias] > > KS > > > > [AliasMults] > > (County abbreviations) > > > > > > Then the code could look for the Mults group and if found process it and > > if not, then revert to the current mults file style. > > > > In this format, any AliasMult entered would be applied as the Alias. > > > > Thoughts? > > and you should pass this file to Tlf through parse_logcfg.c?
No. This is in the mults file and should be handled in the same code area as the present mults file is read. Correct me if I'm wrong, but I didn't think parse_logcfg.c handled the mults file processing. Here is my outline of the logic flow (based on my likely misunderstanding of the process). The open mults file function is called. The GKeyFile functions are used to open the mults file and test if the group "[Mults]" is present. If so, the Mults, Alias, and AliasMults are loaded into their respective data structures. If not, the present mults processing code is used and the file is loaded into the mults data structure. During logging operations the exchange validator can process the mults structures as follows. Any string appearing in [Mults] is subject to the rules for mults defined elsewhere, either internally or in the rules file. Any string appearing in [AliasMults] is applied to the [Alias] value which is then subject to the mults rules. In the case of the Kansas QSO Party, here is how it would work. An in-state participant has 64 mults available--50 US states, 13 Canadian provinces, and "DX". When an in-state op works another in-state op we exchange the county abbreviations ([AliasMults]) and the first one counts as the KS mult and any subsequent counties are not counted toward the mults. The current implementation of Tlf does not allow for the 105 Kansas counties to only count toward KS one time. In order to validate the exchange I included the 105 counties in the mults file (attached in a previous mail) so Tlf treats it as 169 mults! Therefore I have a custom script to calculate my raw score. It's not a big deal, it's just a nice to have feature. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB
signature.asc
Description: PGP signature
_______________________________________________ Tlf-devel mailing list Tlf-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tlf-devel
