Re: doors and mulitple nodes
By: Rixter to all on Thu Jun 20 2024 07:17 pm
I got all the old doors i wanted to run to run. I noticed that they only run on node 1. If someone tries to access them on node 2 or other nodes they just go back to the door launch menu.
How do you have these doors configured in SCFG? Hopefully you don't have the path to the node1 directory hard-coded in the command-line (?).
If the door has a separate config file for each node, then you'll need to be sure to set that up in the door's configuration program (if it has one) or create/edit those additional node config files (for each node you intend support).
Is there a way to to enable doors
designed for node 1 to either run on other nodes or to have a message for the user to try back later?
There's really no such thing as "doors designed for node 1". More likely, it's a multi-node door and you just didn't *configure* the door to support > 1 node.
The ones that came with synchronet have no
problem running on multiple nodes. I have one door that occasionally keeps the previous callers details instead of the current details, in the clean up command after the door closes do i need to specify a batch file that reads cd\sbbs\node1 del door.sys or dorinfo1.def or whatever the file type is?
No. Most likely, you have the configured to read the wrong drop file type (not the same type that you have Synchronet configured to *create* for that door in SCFG).
You need to diagnose the issue more (look at the door's documentation and config file and compare closely with what you have confiugured in SCFG). If you want the drop files to be automatically deleted when a user logs-off, set them to be created in the "Temporary Directory" instead of the "Node Directory" in SCFG:
É[þ][?]ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Create Drop File In º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º ³Node Directory º
º ³Start-up Directory º
º ³Temporary Directory º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
That will *gaurantee* that an old drop file (for a previous user) will never be used for that particular door. But that's not normally required when everything is configured correctly.
I
have 3 doors that only work with dorinfo1.def is why i bring this up. they work great but only on node1. calling in from node 2 - 10 only sends the caller back to the door menu.
Are you saying they won't work with dorinfo2.def if that's the drop file created by SBBS (which is an option in SCFG, called "DORINFO#.DEF")? Are you passing the path to the drop file (e.g. %f specifier) on the command-line to execute the door?
I am happy with the function of the door and
users enjoy them but it is a little confusing to some that call and sometimes they do not work. They are working, but only if the user gets node 1 free at the time of log on. Any tips from veteran Synchronet BBS SYSOPS?
What are the names of the doors in question?
Do these doors have configuration programs or files with per-node settings? Does the documentation say the door will read DORINFO1.DEF only, or will it read DORINFO#.DEF (e.g. DORINFO2.DEF) as well?
What are your setting in SCFG for these doors?
--
digital man (rob)
Rush quote #11:
Struck between the eyes by the big time world, walking uneasy streets
Norco, CA WX: 81.1øF, 42.0% humidity, 12 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net