Hi,
On Tue, 8 May 2012, OK1ALX wrote:
> Second, the normal map shows the lines of the packet path, red for normal hop,
> violet for hop heading to igate. Here, the line is shown for the first hop
> (the digi i have on the first place in path), even if digi doesn't hear&repeat
> the packet. So it looks like it goes over the digi everytime (since the packet
> path is set as described above).
Yeah, you're right. The background for this is the fact that the backend
code precompiles references to all of the known callsigns in the path
(even if the callsigns didn't actually digi the packet). This is right and
well, since it's good to make all of the callsigns clickable links in all
of the views, and the links are quickly generated using those precompiled
references.
The bug is that the path line is drawn via all known stations referenced
in the path without paying attention to the "has digipeated" info. The
"has digipeated" information is not currently available to the Javascript
user interface code that draws the line in question. I'll see what I can
do to fix that.
You're the first one to complain, since it's quite rare to do what you're
doing (configuring specific digipeaters).
When I fix this, some other people will probably come complaining. If I
remember right, some popular digipeater doesn't set the "has digipeated"
bit in some situation when replacing a path element with it's own
callsign.
I'll come and test your digipeater paths in Prague in a week (Sat-Tue
19-22th).
> The packet goes directly to igae OK1KHL-1, not even touching the OK1ALX-2
> digi:
> 2012-03-03 21:05:36 CET:OK1ALX>UP0R15,OK1ALX-2,WIDE2-2,qAR,OK1KHL-1,T2CZECH:`+`o |n>/]"6@}438.900MHz op.Libor
> =
> - on the map, the line is drawn trough the digi (nonexisting hop)
- Hessu