<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">This is correct. It does that. It's a
long standing request and it's something that that I have looked
at long and hard and then left as it is. The trouble is that there
is a ripple effect that will run through the product with little
(and maybe great) bugs appearing in all sorts of places depending
on EXACTLY what a user expects to happen when logging in as, say
OH3/G1TLH.<br>
<br>
The first issue is that what you login with a callsign, that is
the primary (only) key to that callsign record in the user file.
This is a similar problem to logging in as G1TLH-1 etc. As far as
DXSpider is concerned it is a different, distinct, user* and
treated completely independently. G1TLH and G1TLH-1 are <b>different</b>
users, they may look the same and have the same information (name,
qth, locator etc), but is because I have put them there.<br>
<br>
What has been requested, in the past, is that one should be able
to login as, for example, PA0/G1TLH - perfectly legal and
reasonable but then <b>still be</b> G1TLH for all normal
purposes except changing my default country code, itu zone,
default (or new) qra locator etc because I am in the Netherlands.
What does one do with GM1TLH. I'm now in Scotland (sadly becoming
less likely to happen every day that passes). How do I deal with
that? The answer is I can't (or at least not without rewriting
large chunks of code and probably making it bigger and slower). <br>
<br>
For historical reasons, because I started writing this code in
1997, the standard I chose was the one that AK1A's Packet Cluster
software had user; which is the AX25 standard of 7 letters and
digits + SSID (which could then only go up to 15 with SSIDs above
7 having special meanings - neither limit or convention now
applies). Even assuming that one accepts that PA0/G1TLH is
distinct and independent in the same way as G1TLH or G1TLH-1, it
has ramifications for the formatting of output from the node to
users (spots, sh/dx et al) - it reaches into the heart of that
code - at least as far as formatting output is concerned because
of the extra length. All normal user output is based on a line
being 80 characters wide. <br>
<br>
Perhaps I should base my output on a 100 or 120 character line
length. I have mooted this very thing. Only had one comment on it
so far. I would be happy to do that and allow OH3/G1TLH (as a
distinct user) in principle, provided I get some buyin from the
logging/contest cluster client programs that they can cope with
both the callsign and the changing formatting. But even that is
still quite a lot of detailed, fiddly, work that touches many
parts of the software. I could copy whatever Lee VE7CC is doing
with his CC-Client software, over and above the 'set/ve7cc' mode
that is available for spots. But it still requires coordination
and discussion amongst all authors - which I would welcome.
Unfortunately, one major author (of AR-Cluster) has now passed
away and, I am told, taken his source code with him. <br>
<br>
Thus the status quo persists. <br>
<br>
73 Dirk G1TLH<br>
<br>
* but, under certain circumstances you might acquire an SSID, as
in the node gives you such a callsign, if you login with your base
call G1TLH in rapid succession and the enabling parameter is set.
But there are trade offs here that can prove annoying if you ALSO
want to login as G1TLH-1 (or whatever) as a separate user.<br>
<br>
On 05/08/2020 20:23, G3YPP via Dxspider-support wrote:<br>
</div>
<blockquote type="cite" cite="mid:md5:bgEYAkRr9H6IKCbZJHddvA==">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
<div class="WordSection1">
<p class="MsoNormal">Dirk,</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">If you try to login to a node with a
callsign with a / in it eg OH5/G3YPP the node returns “invalid
callsign”. </p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I picked this up on the HRD forum with
someone trying to login in to WA9PIE-2. </p>
<p class="MsoNormal">I tried it on my node MX0NCA-2 which gives
same result – direct telnet in using PUTTY, so no HRD
involvement. Login with a Callsign containing a / returns
“invalid callsign” </p>
<p class="MsoNormal">Node running mojo 1.57 build 319</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Sent from <a
href="https://go.microsoft.com/fwlink/?LinkId=550986"
moz-do-not-send="true">Mail</a> for Windows 10</p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Dxspider-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Dxspider-support@tobit.co.uk">Dxspider-support@tobit.co.uk</a>
<a class="moz-txt-link-freetext" href="https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support">https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support</a>
</pre>
</blockquote>
<br>
</body>
</html>