Subj : Re: Door problems To : Cisop From : Digital Man Date : Sun Sep 25 2005 12:00 pm Re: Re: Door problems By: Cisop to Digital Man on Sun Sep 25 2005 01:03 pm > > Re: Re: Door problems > > By: Cisop to Digital Man on Sat Sep 24 2005 12:40 am > > > > > > Re: Re: Door problems > > > > By: Digital Man to Cisop on Fri Sep 23 2005 02:35 pm > > > > > > > > > > > Do the SBJ and SBL doors work? Does SEXYZ (see docs/sexyz. > > fo > > > > deta > > > > > > > upgrading)? If none of these programs work, then the cause > > mo > > > > > > definitely > > > > > > > another piece of (security) software on your system. > > > > > > > > > > I followed up on SBJ and it does work correctly. On my system > SBL, > > > > an > > > > > > SEXYZ all work fine. > > > > > > > > > > That's good news. > > > > > > > > > > > It is only Doormud and Trivia that do not. I suspect th > > > > > > were both written with the same doorkit. > > > > > > > > > > They were written by the same author, so definitely. > > > > > > > > > > > I noticed a thread in the forums on the doormud site about th > > same > > > > probl > > > > > > One of your users was compliling his own copy of SBBS from CV > At > > > > en > > > > > > June, 2005 his doormud stopped working also. The author of > doormud > > > > no > > > > > > able to find the problem. The sysop had to change over to the > > door3 > > > > vers > > > > > > They were not able to get the xtrn.dat version to work again > after > > > > of > > > > > > CVS updates. > > > > > > > > > > Weird. What OS are you using? I just did a fresh install of v3.1 > on > > > > Window > > > > > XP and DoorMUD works fine. Here's the configuration from SCFG: > > > > > > > > > > Internal Code DOORMUD > > > > > Start-up Directory ../xtrn/doormud > > > > > Command Line dmud32 > > > > > Clean-up Command Line > > > > > Execution Cost None > > > > > Access Requirements > > > > > Execution Requirements NOT UNIX > > > > > Multiple Concurrent Users Yes > > > > > Intercept Standard I/O No > > > > > Native (32-bit) Executable Yes > > > > > Use Shell to Execute No > > > > > Modify User Data No > > > > > Execute on Event No > > > > > Pause After Execution No > > > > > BBS Drop File Type Synchronet XTRN.DAT > > > > > Place Drop File In Node Directory > > > > > > > > > > I'll do a fresh install of v3.12a and then upgrade to v3.13a on > > sa > > > > box > > > > > and see if there's maybe a problem with upgrading only. > > > > > > > > I just performed a fresh install of v3.12a, and then upgraded to > v3.13a > > o > > > > Windows XP box and DoorMUD continues to work. I was pretty sure I d > > tho > > > > before the release and verified all the pre-installed continued to > work, > > > > they are, so I'm not sure what the problem is with your particular > > > > install/upgrade. > > > > > > > I am running windows 2000. I had users in doormud on 09/14/05 at 4:29 > P.M. > > > installed the upgrade on 09/14/05 at 8:43 P.M. No one has been able to > get > > > into the game since. The doormud logs still have a 09/14/05 at 4:29 P. > > tim > > > stamp. > > > > And how does your configuration of the door (in SCFG) compare with what I > > posted? > > > > When upgrading Synchronet, it doesn't touch any files in the xtrn/doormud > > directory, so I don't really have any explanations at this point. > > > > Have you tried re-installing doormud? > I have found a way to make both doors run. I don't know why but hopefully yo > can shed a little light on it. > I wanted to see if I could stop the door with a window open so I ran it from > batch file like this. > > set SBBSNODE=C:\sbbs\node1\ > dmud32 > pause > > The door worked fine. I wrote a similiar batch file for Trivia and it also > worked fine. > > I checked to see what environmental was set for SBBSNODE in windows. The > variable being set was c:\sbbs\node1. Note that here is no trailing backslas > > I have no idea why this problem appeared all of a sudden with the sbbs > upgrade. I don't know what sets the SBBSNODE variable. > > Anyway we are up and runnig again!!! It's running *from* the BBS now? Synchronet should be setting the SBBSNODE environmnet variable before running any external progarm, and it should automatically match whatever the current node number you're logged onto. For example, if you use the ;SHELL sysop command and type "echo %SBBSNODE%", you should see the path to your *current* node directory (whatever that is). This is also true of the DSZLOG environment variable, SBBSNNUM, and some other variables. If you're not seeing these variables set to their correct values when performing a ;SHELL, then that is a clue that something is definitely wrong. digital man Snapple "Real Fact" #123: Beavers were once the size of bears. .