[Ant-l] ANT version 12 issues

[Libor Forst]

On Tue, Nov 12, 2024 at 12:44:01AM +0100, Renato Bettin wrote:
> Hi Libor,
> these are my comments:

Hi Renato, thank you very much for your comprehensive comments...

> > 3. Writing results to Toe chips
> This can be very useful, also because:
> 1. the marshal can even use a tablet with no mobile connectivity
> 2. you have two copy of the records.

OK Vote registered... :-)

> > 4. Publishing results in the forest
> Very useful. I wish I had this feature in Cansiglio some years ago...

OK Vote registered... :-)

> > 5. Assigning chips
> > If a competitor uses an unknown chip for identification, the marshal
> > can assign the new chip to the competitor from a startlist, or to add
> > a new person name. This is especially useful when publishing results
> > in the forest - otherwise, the chip assignment should be done in
> > the result IS long before any data with the new chips comes into
> > the IS. The assignment itself is not that complicated, the problem
> > arises when the startlist needs to be reloaded - whether to keep the
> > saved assignments, or forget them and simply use the new startlist.
> > Reloading the startlist typically means that we have a new, fresh
> > data which should include the new chips...
> Every additional option to make changes in the entry list during the
> competition is welcome.

I must admit I don't understand what is this vote for... :-)

I am trying to find a situation when the assigning in the forest is
useful and to check if the complication with reloading new startlist
is needed.
Let's imagine you are a marshal doing read-out in the forest:
- If the competitor coming with an unknown chip is a new person,
  you are not able to select him from the startlist and you will
  have to write (some version of) his name to the record. This
  will be hard to match with a proper name somewhere in the DB
  but can be sufficient for in-forest results.
- If the competitor is known but with another chip, this assignment
  is probably already done somewhere in the DB, so again, it makes
  sense only for in-forest results.
In both cases, if you don't publish results in the forest and only
upload results to a server, the server will probably contain all
new people and chip replacements. So in fact, no local temporary
assignments are needed. If you publish results in the forest, it
is useful to add these assignments to have results complete. But,
if you successfully download a new startlist from a server, it
will also contain all changes and your assignments can be removed.

So since you have voted for keeping the in-forest results, keeping
the possibility to assign chips also makes sense for you. But maybe
the complication with downloading a new startlist, asking the user
what could be done with his assignments and the complication to keep
his assignments despite new chip numbers coming in the starlist, is
IMHO not needed.

> > 6. E-card mode
> This mode has been used extensively in Italy both in official
> competitions and in the trainings, because is very practical.
> As far as I know, we had just one or two cases of accidental
> reset of devices during the race, with data loss (I don't know
> the details, I was not in the organization);

If the device was not broken, it should keep the data... :-(

> > 7. E-card mode menu locking
> > There is another aspect associated to the e-card mode: if competitors
> > share devices (e.g. from organizers), they can see answers of other
> > competitors who used the same device before. That's why there is
> > an option to lock the menu so that users cannot open the results.
> > Has this been used in elsewhere?
> As organizer, I've never used this option. Actually, I've never
> opted to share a device in a competition.

OK, so since you (I mean Italians :-) were the most frequent users
of the e-card mode, it seems that locking can be removed...

> > 8. ANT Master Server
> This mode can be very useful. If I understand correctly, I can pass
> the TC stations with my device configured as hotspot and Ant Master
> Server, and pick up the result from the devices of the marshals.

Exactly.

> > 9. Multistages event
> Ok for me, so far I don't see any drawback.

I'll try to be more clear: have you ever used/seen one configuration
for more races distinguished with classes?


Thanx again a lot!

Sincerely L