Alias Variable Empty on GO32V2 Compile
Opened this issue · 11 comments
I have been able to successfully compile to GO32V2 target. Everything seems to work fine, but in a test using Spitfire and door.sys I am getting a strange result where the Alias variable is blank. It shows the user's name in the lower left corner of the local window along with RMDoor v13.09.02, but if do DoorWrite('Logged in as: ' + doorDropInfo.alias); It just comes up blank. So I'm confused as to what to do as it seems like the drop file is getting read successfully.
If I run from local command prompt it reads whatever I write in the local login prompt so there's no accidental overwrite or something. I've been compiling to other platforms and BBS installs no issue...I'm pretty stumped.
Just a brief update it also happens on a synchronet install. But if I target WIN64 the same exact code and call it from your Door Game Server it works just fine. Going to continue testing.
What do you see on lines 36 and 10 in the door.sys file? According to the dropfiles.pas source, that's where the Alias and Real Name values should be.
If you don't see the alias on one of those lines, do you see it on another line? dropfiles.pas may have the wrong line numbers and need fixing.
Yeah I apologize it’s definitely specific door.sys. When it was changed on sync to door32.sys it worked fine. Line #10 is showing the alias I’m looking for in door.sys (and seems to appear on the local screen). I’ll see if I can get a copy of the door.sys being used. Thank you for the reply.
Sample sync door.sys:
COM1:
38400
8
1
38400
Y
Y
Y
Y
Tyberius Saurfang
Oregon, USA
<scrubbed password>
50
7
12/31/22
14389
239
GR
24
N
0
00/00/00
48
Z
0
0
0
13312
d:\sbbs\NODE1\
d:\sbbs\DATA\
xbit
00:00
Y
N
Y
15
0
10/20/21
11:15
07:06
999
0
0
0
Warning: same IP address as user #1 xbit
0
0
Sample spitfire door.sys:
COM2:
19200
8
1
9600
Y
N
N
Y
Moosejaw Rex
Hillsboro, Usa
000-000-0042
000-000-0042
<scrubbed password>
10
187
12-31-22
5400
90
GR
24
N
1,2,3,4,
3
12-31-99
12
N
0
0
0
999999
C:\SF\WORK\
C:\SF\
Rob
Y
N
Y
7
0
04-02-21
11:13
06:32
10
0
0
0
2
This is an example screen shot where it seems to be reading the door.sys alias line (displays on status bar), but is blank when I try to write it (and door32.sys works fine with same code).
In both of the dropfiles you provided line 36 is blank, so the BBS is not specifying the user's alias in the dropfile.
I just double-checked the statusbar, and the default one outputs the user's real name, which comes from line 10.
Presumably the reason things are working OK with door32.sys is because the BBS is outputting the alias there (in that file, line 6 should be the real name and line 7 should be the alias).
Ah okay, that helps a bunch - the status bar is pulling line 10 and .alias is pulling line 36. That was making me think something else was going on.
It looks as though door.sys is 35 for alias specification, I just extracted an old copy of my board and looked at an old door.sys file that was written and the alias is on 35. The above door.sys files were provided to me by someone trying to set up with two separate instances one of Synchronet and one Spitfire. Its xbit as you can see from the drop files and he has a ton of doors already set up using door.sys. I looked at the door.sys file generated by GameServer and it is on 36 however.
It seems odd to me that this would just be popping up now and if I'm looking at this wrong just let me know. Thanks so much!!
Line 35 would be the sysop's name, so if it was a dropfile from your board then it would make sense to have your name on that line.
For the samples above, line 35 is saying the sysop's name is xbit, which is confirmed by the comment on line 50 that says user #1's name is xbit. And then in the second file it's saying the sysop's name is Rob.
With Synchronet, if I remember right you have the option of specifying whether to use real names or aliases in the drop file, so it may be that based on that decision only one or the other is output to the file, and never both. But it's been awhile since I setup a door so maybe that setting only applies to dorinfo.def files (which doesn't have separate real name and alias fields), and doesn't apply to door.sys
As a sort of workaround I could update RMDoor to add functions called RealNameOrAlias and AliasOrRealName that will prefer returning the first property but fallback to the second property if the first is blank. Then instead of printing .Alias you could print .AliasOrRealName, and in the case of the samples above they'd fallback to printing the user's real name instead of the alias.
You are absolutely right, thank you. Line 35 did have my name, but I wasn't even the user logged in that generated the door.sys file and I didn't even recognize that. Those functions would be helpful and would solve this.
From the looks of my old door.sys file it even appears it's using line 10 as the alias line, but I wouldn't want to depend on that if there are other systems generating a door.sys without blank line 36 (and up to this point .alias has been working with everyone including my setup).
I put in a if blank use line 10 in the door.sys reader and it seems to be working. Much appreciated.