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
--- SBBSecho 3.20-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
|
