I normally use either DORINFO1.DEF or DOOR.SYS for the door dropfiles. But, when a user with a one word alias tries to enter a door (I have
real names turned OFF), the door crashes, and locks the node, because
it doesn't know what to do with a one word alias/name in the dropfile.
The only options are to either turn real names on (some have requested that this NOT be done), have them change their one word alias to a two
word alias (i.e. from Warrior to Grimy Trader), or they are just "locked out" of the doors.
Has anyone else experienced this?? If so, how do you handle it??
I normally use either DORINFO1.DEF or DOOR.SYS for the door dropfiles. But, when a user with a one word alias tries to enter a door (I have
real names turned OFF), the door crashes, and locks the node, because
it doesn't know what to do with a one word alias/name in the dropfile.
The only options are to either turn real names on (some have requested that this NOT be done), have them change their one word alias to a two word alias (i.e. from Warrior to Grimy Trader), or they are just "locked out" of the doors.
I normally use either DORINFO1.DEF or DOOR.SYS for the door dropfiles. But, when a user with a one word alias tries to enter a door (I have
real names turned OFF), the door crashes, and locks the node, because
it doesn't know what to do with a one word alias/name in the dropfile.
Perhaps if you mentioned which doors this happens with, that would trigger (heh) other sysops into remembering if they have that particular door and then test it and see what happens.
I normally use either DORINFO1.DEF or DOOR.SYS for the door dropfiles. But, when a user with a one word alias tries to enter a door (I have
real names turned OFF), the door crashes, and locks the node, because
it doesn't know what to do with a one word alias/name in the dropfile.
The only options are to either turn real names on (some have requested that this NOT be done), have them change their one word alias to a two word alias (i.e. from Warrior to Grimy Trader), or they are just "locked out" of the doors.
Has anyone else experienced this?? If so, how do you handle it??
The only options are to either turn real names on (some have requested
that this NOT be done), have them change their one word alias to a two
word alias (i.e. from Warrior to Grimy Trader), or they are just
"locked out" of the doors.
Has anyone else experienced this?? If so, how do you handle it??
I run about 200 doors, some old, some new, and have never encountered this on Synchronet or GAP. My handle is desotofireflite, (one Word), and I've never seen the issue. What doors are choking on one word handles.
On 2017 Dec 08 06:39:56, you wrote to Daryl Stout:
The only options are to either turn real names on (some have requested
that this NOT be done), have them change their one word alias to a two
word alias (i.e. from Warrior to Grimy Trader), or they are just
"locked out" of the doors.
Has anyone else experienced this?? If so, how do you handle it??
I run about 200 doors, some old, some new, and have never encountered this on Synchronet or GAP. My handle is desotofireflite, (one Word), and I've never seen the issue. What doors are choking on one word handles.
i suspect the problem is that daryl is using the new capability to swap real names with handles and that the complaining doors are expecting two word real names... so the door sees a single word handle in the real name field and complains because it is not two words like it expects...
in other words, the door is not complaining about one word handles... it is complaining about one word real names...
Which doors crash? Certainly not *all* doors crash under this condition.
Perhaps if you mentioned which doors this happens with, that would trigger DM>(heh) other sysops into remembering if they have that particular door and th DM>test it and see what happens.
Does that happen with all doors or a specific door? I haven't seen that happ N>and haven't heard of that before. Most doors I've installed can use the user N>handles just fine. That sounds like a bug that would be with a specific door N>rather than all doors in general.
I run about 200 doors, some old, some new, and have never encountered this on D>Synchronet or GAP. My handle is desotofireflite, (one Word), and I've never D>seen the issue. What doors are choking on one word handles. It may be a D>dorinfo1.def thing. I use door.sys when at all possable. If it's BRE, FE or T D>like we discussed yesterday, Synchronet has the option of making the D>doorfile.sr that is need by these 3 doors, just put them in the door director
Synchronet is one of the easiest systems around to set up doors.
That is correct. You don't need batchfiles to run the doors, and you
can set up non-fossil doors like a fossil door, and use them. It's the ONLY BBS package I know of that does this.
i suspect the problem is that daryl is using the new capability to swap
real names with handles and that the complaining doors are expecting
two word real names... so the door sees a single word handle in the
real name field and complains because it is not two words like it
expects... in other words, the door is not complaining about one word
handles... it is complaining about one word real names...
What capability is this? Synchronet has only one option with regards to names/aliases in drop files, and that is to place the user's real name wheir their alias/handle/id would normally go (in some drop files). The "real name" field in the drop file (if it has one) always contains the user's "real name" from the BBS database. There is no Synchronet option to "swap" these values.
On 2017 Dec 08 10:23:16, you wrote to me:
i suspect the problem is that daryl is using the new capability to swap
real names with handles and that the complaining doors are expecting
two word real names... so the door sees a single word handle in the
real name field and complains because it is not two words like it
expects... in other words, the door is not complaining about one word
handles... it is complaining about one word real names...
What capability is this? Synchronet has only one option with regards to names/aliases in drop files, and that is to place the user's real name wheir their alias/handle/id would normally go (in some drop files). The "real name" field in the drop file (if it has one) always contains the user's "real name" from the BBS database. There is no Synchronet option to "swap" these values.
didn't you just (six weeks ago or so?) add an option for the door command line in sbbs that places the handle where the real name used to be in the drop file?
it was something daryl had asked for, IIRC... i'll have to hunt down the topic to be more specific... i can't even recall the two or three character sequence desginated for this... %S or i dunno...
Rob,
Which doors crash? Certainly not *all* doors crash under this condition
All of them. I mainly use DOOR.SYS or DORINFO1.DEF as the dropfile.
Perhaps if you mentioned which doors this happens with, that would trig DM>(heh) other sysops into remembering if they have that particular door a DM>test it and see what happens.
Except for the Synchronet doors that came with the setup, every other door that I have crashes, if there's a one word alias...either with DORINFO1.DEF or DOOR.SYS as the dropfile.
i suspect the problem is that daryl is using the new capability to swap real names with handles and that the complaining doors are expecting two word real names... so the door sees a single word handle in the real name field and complains because it is not two words like it expects...
in other words, the door is not complaining about one word handles... it is complaining about one word real names...
didn't you just (six weeks ago or so?) add an option for the door
command line in sbbs that places the handle where the real name used
to be in the drop file? it was something daryl had asked for, IIRC...
i'll have to hunt down the topic to be more specific... i can't even
recall the two or three character sequence desginated for this... %S
or i dunno...
I think you're thinking of the RLogin gateway option (TG_RLOGINSWAP) -
has no effect on drop files created by Synchronet.
in other words, the door is not complaining about one word handles...
it is complaining about one word real names...
You may have a point, although I thought the new swap command only
worked with telgate and rlogin. He need to just tell it to use handles
in the actual sync config for the door, which I assumed he was doing.
That is correct. You don't need batchfiles to run the doors, and you
can set up non-fossil doors like a fossil door, and use them. It's the ONLY BBS package I know of that does this.
That is correct. You don't need batchfiles to run the doors, and you
can set up non-fossil doors like a fossil door, and use them. It's
the ONLY BBS package I know of that does this.
I was in the habit of using batch files, but I like that you don't have to use them with Synchronet. One thing I think a batch file is useful for, though, is if there's a problem with the door, you can put a "pause" statement in the batch file after the door command, and Windows will keep the command prompt window open so you can see whatever error the door might be outputting. But then if you want to switch to a batch file, you have to change the command in SCFG, and if anyone is logged in, you have to wait for them to log off so Synchronet can recycle its configuration..
but there is still the thing of some doors working as i pointed out... i've run into it numerous times in the past... that because the main system i work with didn't offer similar so i wrote a script that would swap the real names and handles and got bit by some doors... it was so long ago that i don't even remember which ones they were... the fix was simple, though... revert the switch on them and hope they displayed the user's handle for everything no matter if it kept their record based on their real name or their handle... some did, some didn't... we don't run many doors any more, these days...
Yes, door usage is down regretably. If a certian door gives problems with handles, I would just use real names. Like you said, some doors let you
to help him, but he won't tell us the door or doors that are giving him
I was in the habit of using batch files, but I like that you don't have to us N>them with Synchronet. One thing I think a batch file is useful for, though, N>if there's a problem with the door, you can put a "pause" statement in the N>batch file after the door command, and Windows will keep the command prompt N>window open so you can see whatever error the door might be outputting. But N>then if you want to switch to a batch file, you have to change the command in N>SCFG, and if anyone is logged in, you have to wait for them to log off so N>Synchronet can recycle its configuration..
Hi Daryl,
I seem to recall that when using Maximus way back it detected and dealt with JM>this by appending NLN (no last name) to any single-word names in its JM>dropfiles. Some doors even expected this and referred to the user by their JM>single-word name if they saw this in the dropfile.
Does Synchronet have any similar option?
That is correct. You don't need batchfiles to run the doors, and you
can set up non-fossil doors like a fossil door, and use them. It's the ONLY BBS package I know of that does this.
maybe drop the realname requirment on all the doors except legue doos.
Yes, door usage is down regretably. If a certian door gives problems with D>handles, I would just use real names. Like you said, some doors let you chose D>handle anyway, so it's really not a big thing in my eyes. I'd like to help hi D>but he won't tell us the door or doors that are giving him the problems. It m D>be a simple fix.
Re: Dropfile Issues
Could be a problem if you didn't collect real names from users when they signed up in the first place, but that could be worked around.
I got the impression from previous messages that it was Solar Realms doors. If memory serves, exclusive access is important here (only one node can run one of these games at a time), but I may be wrong. Also it sounded like he was using some utility to convert between one dropfile format and the SRDOOR type; don't know if he tried just having Synchronet create the appropriate dropfile to start with - at the very least this would simplify things.
OK, once I get the DoorStat deal set up, I'll personally go through
all 350 doors, and see which ones "barf" on the one word alias...then, I'll post a list.
It might be just with DORINFO1.DEF. but I know there are 2 different
types of DOOR.SYS files (one is longer).
Not to slow you down, but I would get one problem fixed before you start a ne D>project. Adding this doorstat when your already having an issue with handles, D>may create a new problem. If you get your games working correctly first, you D>will have a base line to work with. Just thinking outloud.
It might be just with DORINFO1.DEF. but I know there are 2 different types of DOOR.SYS files (one is longer).
I try to always use the long 52 line door.sys, as it works most of the time.
I think I have to add a parameter in the "door clean batchfile"...but
at least I've found some doors that didn't have one of these, and had to create one. I'm suspecting the problem is with DORINFO1.DEF -- but, I never could figure out what the difference was (except for node number)
in DORINFO1.DEF and DORINFOx.DEF -- where x was the node number. Under dial-up, that made a difference, but on telnet, the comport is basically ignored.
I don't remember which one the Doorway program (originally done by Marshall Dudley...now done by Mike Ehlert) requires with the DOOR.SYS file, or if there's a parameter for it, offhand. Doorway does also work with other dropfiles, but I'd have to look at the docs to be sure. I do know that unregistered, you only have 10 minutes in the door...registration removes that. I had registered it when Marshall
Dudley was still supporting it, before the rights were sold/transferred
to Mike Ehlert.
I always use the 52 line door.sys if possable. In Synchronet it's:
BBS Drop File Type GAP DOOR.SYS
It uses the long version, and the regs that Marshal Dudly gave you work with D>Mikes version.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495939:00:42 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,964 |