a different way to startup bport?

Posted by Tzaro on Thu 06 Apr 2006 03:40 PM — 8 posts, 28,214 views.

USA #0
Howdy all,

I've been looking for a way to start my bport up (assuming it went down via acceptable reasons) by using an in-game command on our main port. I'm not the best coder in the world, I just know enough to get by. I leave all the big stuff to my partner in crime :P. Anyway, here's what I have (and I'll explain it further below):

void do_start_bport( CHAR_DATA *ch )
{
char buf[MSL];
sprintf(buf, "~/lpbuild/build_port/src/startup &" );
system(buf);
send_to_char( "the bport should now be running.\n\r"
"If the port was already in use, this will have no effect.\n\r", ch );
return;
}

(our main port runs from ~/mud_lp/src)

Kay, I've experimented around with a few different versions of the above and managed to somehow get a bport up and running, however it was an exact copy of our main port running on bport's port assignment (all the pfiles could be loaded from main port, areas, etc). So I figure I'm on the right track, but I'm simply missing something. I wish I had left the variant I had alone when I got it to startup with mainport's 'stuff'. Alas I didn't, else I'd tell you how I managed to do it.

Can anyone explain to me why this isn't working and describe a possible solution?

-Tzaro
Canada #1
Er... I read your post, started writing a reply, then went back and read it again - and now I'm not sure what your question is.

You realize you have to copy over the /area, /player, and al the other folders right? Otherwise, it'll just be writing data to the main port, and they can use their characters on either port.
USA #2
The startup scripts both need to use full paths, not relative paths. That's very important. Otherwise, if a startup script says go .., then go to area, then run ../src/smaug (or whatever), you'll just end up running the same thing.

Remember that the current directory of the build port startup script is the current directory of the main port.
USA #3
Sorry Dace K, I should've been a little more specific...
I have a completely seperate directory with all the goodies inside it for my bport. It's an exact copy of my main port with the exception of area.lst and /player being cleared appropriately. We've had our bport for ~3 years. I'm simply looking for a way to allow my imms to startup bport if they crash it so they can continue working on areas (without giving them shell access).

Ksilyan, Thank you much. I must've been falling asleep at the wheel for a little while. My problem (I think) didn't dawn on me until I read your post. Because I'm running the command from my main port, it's causing my bport's startup script to be run using the directories of our main port. That's too easy of a fix. Thanks again!

-Tzaro
USA #4
A general idea to keep in mind is to not ignore crashes. You should always attempt to fix them, and remember we're here if you cannot figure something out. ;)
USA #5
*nods* Most of the crashes that occur on our bport are nothing more than people using some of our newer commands that are still being worked on. If it crashes from something else and I cannot get it fixed, you can bet your bottom that I'll be posting here looking forward to a response from people like you :) You all keep mudding alive. Thanks for all your support!

-Tz
USA #6
BTW, thought I should post once more...

I got it working. Thank you Ksilyan. I changed the startup script for bport to reflect the correct paths (cd ~/lpbuild/build_port/area, etc) throughout the entire script. It works perfectly. Thanks much!

-Tzaro
USA #7
Glad to hear you got it working! It's always the little annoying problems that you never think about, isn't it? :-)

Part of being "good" is having run into so many of them so many times that you start to know where to look for simple errors, and not get carried away debugging complex problems that are really just from a silly mistake.