tlf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tlf-devel] Handling multiplier aliases?


From: Nate Bargmann
Subject: Re: [Tlf-devel] Handling multiplier aliases?
Date: Mon, 11 Jun 2018 21:51:30 -0500
User-agent: NeoMutt/20180223

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]