Alright, so, I've decided to take a BIG step in this whole process...I was messing around with local hosting. Never did get cygwin to work, but eh. Trial and error I say. Anyway, I found my self a free MUD hosting company and got myself a place to host a MUD. I got Putty and WinSCP. Basically what I'm looking for is tips and pointers on using putty. Right now I'm transferring a folder, pre un-zipped, onto my server. I'm gonna give it a shot following the "How to compile" instructions on http://www.gammon.com.au/smaug/howtocompile.htm#compile , we'll see how that goes. I'm reading through the putty help files while that's being transfered. I think I get the basic idea of how to do this. Just wondering if anyone has any tips, guides, etc that they might be able to pass along.

Thanks!

Oh, yeah, the reason I'm doing this is because I'm pretty much the lead builder for a MUD that a few friends of mine and I are getting up and running. We're using the smaugFUSS base code, but making it totally original, classes, races, etc. We seem to be having problems "switching out" the classes and races. The person that started all this has their own server and runs it off that. Tried deleting the races and classes that we don't want off the class.lst and race.lst file, but that ends up crashing the MUD. Any suggestions?

Figures, right out of the gate, problem. Ok, transfer was great, got into my src folder (YAY!!). chekced the "ls" command got this:

$ ls
act_comm.c build.c db.c imc.c mapout.c nohup.out save.c startup~
act_info.c clans.c deity.c imccfg.h mccp.c o services.c startupod
act_move.c color.c dependencies.d imc.h mccp.h o2 sha256.c startuporig
act_obj.c color.h fight.c imm_host.c misc.c planes.c sha256.h tables.c
act_wiz.c comm.c grind interp.c mpxset.c planes.h shops.c track.c
ban.c comm.c~ handler.c lines mud_comm.c player.c shutdown.txt update.c
bet.h comments.c hashstr.c magic.c mud.h polymorph.c skills.c vg_suppress.supp
boards.c const.c hotboot.c Makefile mud.h~ qstart special.c
bsd-csh count hotboot.h makeobjs.c mud_prog.c reset.c startup

At this point I'm getting excited...so...now, I try "make"...and hold my breath....for about 2 seconds....I get this

make -s smaug
Compiling o/imc.o....
cc1: warnings being treated as errors
imc.c: In function âimc_recv_broadcastâ:
imc.c:1896: error: the address of âsenderâ will always evaluate as âtrueâ
imc.c: In function âimc_recv_isaliveâ:
imc.c:2621: error: the address of âurlâ will always evaluate as âtrueâ
imc.c:2627: error: the address of âversionâ will always evaluate as âtrueâ
imc.c:2633: error: the address of ânetnameâ will always evaluate as âtrueâ
imc.c:2645: error: the address of âhostâ will always evaluate as âtrueâ
imc.c:2651: error: the address of âiportâ will always evaluate as âtrueâ
imc.c: In function âimc_recv_iceupdateâ:
imc.c:2728: error: the address of âchanâ will always evaluate as âtrueâ
imc.c: In function âimc_process_authenticationâ:
imc.c:3208: error: the address of ârnameâ will always evaluate as âtrueâ
imc.c:3221: error: the address of âpwâ will always evaluate as âtrueâ
imc.c:3264: error: the address of âencryptâ will always evaluate as âtrueâ
imc.c: In function âimcsetupâ:
imc.c:5563: error: the address of âimccmdâ will always evaluate as âtrueâ
imc.c:5563: error: the address of âchanâ will always evaluate as âtrueâ
imc.c:5631: error: the address of âarg1â will always evaluate as âtrueâ
imc.c: In function âimcfingerâ:
imc.c:6185: error: the address of âargâ will always evaluate as âtrueâ
imc.c: In function âimcconfigâ:
imc.c:6542: error: the address of âarg1â will always evaluate as âtrueâ
imc.c: In function âimcignoreâ:
imc.c:6813: error: the address of âargâ will always evaluate as âtrueâ
imc.c: In function âimcbanâ:
imc.c:6881: error: the address of âargâ will always evaluate as âtrueâ
imc.c: In function âimc_deny_channelâ:
imc.c:6940: error: the address of âvic_nameâ will always evaluate as âtrueâ
imc.c: In function âimcpermsetâ:
imc.c:7056: error: the address of âargâ will always evaluate as âtrueâ
imc.c: In function âimcremoteadminâ:
imc.c:7213: error: the address of âserverâ will always evaluate as âtrueâ
imc.c:7213: error: the address of âcmdâ will always evaluate as âtrueâ
imc.c: In function âimcceditâ:
imc.c:7366: error: the address of ânameâ will always evaluate as âtrueâ
imc.c:7366: error: the address of âoptionâ will always evaluate as âtrueâ
imc.c: In function âimcheditâ:
imc.c:7583: error: the address of ânameâ will always evaluate as âtrueâ
imc.c:7583: error: the address of âcmdâ will always evaluate as âtrueâ
imc.c: In function âimc_send_socialâ:
imc.c:8063: error: the address of âsocbufâ will always evaluate as âtrueâ
imc.c:8070: error: the address of âsocbufâ will always evaluate as âtrueâ
imc.c:8077: error: the address of âsocbufâ will always evaluate as âtrueâ
make[1]: *** [o/imc.o] Error 1
make: *** [all] Error 2

So, what now......?

Putty is a windows based terminal emulator that telnets into a Unix box (your host). It works the same as the Cygwin GUI, allowing you to use Cygwin commands to manipulate your code. Any help you need would be the same as Cygwin help.




Confused... first you're crashing the Mud, then the next post says you can't compile the Mud to even get it up and running lol.

Be that as it may, regarding races and classes. Races and classes are an intricately weaved part of the code that if you want a raceless and classeless code base this probably isn't for you. If you plan on replacing the existing ones and just want to 'hide' them for now this is the workaround I would suggest. First of all you'll need to keep at least one race and class. What I discovered is that in the class list the last two classes are subtracted by the nanny function (not visible to be chosen). In order to make the last two classes visible I had to create two 'dummy' classes at the end of that class.lst. Keeping that in mind, you'll need to change your class.lst to be the one class you want to keep, plus two other (dummy or existing) classes so that the class.lst looks like it has three classes. I don't believe this is the same for races, I've never changed them, but you can experiment. Just at least leave one race.

As for the imc errors, I can't help here. My copy of 1.9 compiled cleanly so I haven't run into this. I'll leave it up to the real coding experts to advise.

imc.c: In function âimc_recv_broadcastâ:
imc.c:1896: error: the address of âsenderâ will always evaluate as âtrueâ 

Ok this (Since you didn't post the code in question).
I would assume is probably some line like this

if( !sender || sender[0] == '\0' )

You can change it to like this

if( sender == NULL || sender[0] == '\0' )

or do like it is in the latest smaugfuss 1.9

if( sender[0] == '\0' )

All those that are saying it will always evaluate to true will be kind of similar.

Ok, first I'm gonna answer Hana.

The whole "MUD crashing thing" and the "Can't get the code to compile thing". That's two different MUDS.

Now to answer Rem.

It's the smaugFUSS 1.9 from this website. Now, don't remember if it I had altered it or not, so, I re-downloaded it and it's in the process of being put on my host server now and I'll try again after work.

Now, my next question is, does a local hosted version and a live net version of a MUD run differently?
The reason I ask is because I tried that workaround that Hana had suggested about the classes on races on my local version, and no, it didn't work. I moved names around in the race.lst and put my race in between two other races and still a no go.
Also, about having two "dummy" classes. I don't seem to have that problem. I made a new class, made sure that it was in the class.lst, it was the last class in the list and when I made a new character it was there. Keep in mind I did all this on a local level, but I'm thinking that shouldn't matter. Now, I'm not sure if it did something different on the live version
1) I don't have access to the server that the live version is on. 2) The person that runs that hasn't told me if it made a difference or not.
But again, I'm thinking that there isn't a difference between a loal and live versions. The files should be read the exact same way, no?

more or less they will run the same net or local. Compiling is a different matter though because different compilers compile differently etc...

The one on the website doesn't seem to have those issues (I had downloaded one to check) and in the example I posted the one from the site wouldn't have created that example bug I used since it had the other way "if( sender[0] == '\0' )" wont give the bug. where "if( !sender || sender[0] = '\0' )" would. A fresh copy shouldn't give you all those issues that you were having.

Ok, cool, and I can understand that, Rem. But, from what I've heard and been told PuTTY is basically the same as Cygwin, right?

Well cygwin tries to act as much like the stuff you can do on an actual server but it is still short a lot. More or less though depending on how the server is set up and cygwin is set up you can have alot of the same things. Some things you can't do in cygwin that you can in a server though valgrind being one of the major ones lol.

Putty is just a basic program that you use to connect to the server to do the stuff though. So it isn't really all that much like cygwin. But you will have at least (should anyways) the same commands as you would in cygwin and it more or less from your point of view function about the same.

Hmm, maybe that's a workaround for the old Smaug 1.4 I was thinking of.

You were able to create a new class, are you still having trouble deleting race/classes?

Maybe you should explain in detail exactly what you did and at what point the mud crashed. The more information you can give the easier people can help.


That's what I said a few posts up ;)

Well, see, that's the thing. All I know is that she, the person that runs the server that the MUD is hosted on, she took all the classes and races from the original smaugFUSS code out and replaced them with the new classes/races that we are going to use. I have no idea other than that how it was done or any other details cause I can't access the server myself.

Me on the other hand, as I said, I'm running a version of the FUSS 1.9 code from the files here on smaugmuds.org, that version is a local version at the moment, and I'm working on making it a live version.

In the local version I can create a class in-game with setclass and it's good to go, just have to go back to each race and edit them so that they are allowed to be that new class. But races on the other hand don't work that way. I create a race and can't get it to show on the race selection portion of making a characer. I've tried everything I can think of and still, can't get a new race to show up. I'm about to try again with a fresh FUSS 1.9 codeset. See if that makes a difference.

But that's just in my experiments. The biggest problem we are having with the live version is the fact that we can't get rid of the original classes/races. She, the person in charge, wants an original theme. So she's not wanting to use and original classes and only one original race.

Ok try this on your local version; for races, you have to update the file mud.h with your new race types as well as setrace. It looks something like this;

/* the races */
typedef enum
{
   RACE_HUMAN, RACE_ELF, RACE_DWARF, RACE_HALFLING, RACE_PIXIE, RACE_VAMPIRE,
   RACE_HALF_OGRE, RACE_HALF_ORC, RACE_HALF_TROLL, RACE_HALF_ELF, RACE_GITH,
   RACE_DROW, RACE_SEA_ELF, RACE_LIZARDMAN, RACE_GNOME
} race_types;

This list and the list in your race.lst file should be exactly the same and in the same order I believe. After updating this mud.h file you have to 'make clean' and 'make' to recompile again (shutdown the mud first).
(Once again, these are instructions I used on the old version of Smaug, I haven't tried this with the new 1.9 version)

As for the hosted version, as I said, we'd need to know exactly what she is doing to the code.

Hmm...ok, I'd try it, if I had done the compiling for my local in the first place. I use WinSMAUG. Rather, I use a exe file that I found ready to go on Nick's site.

Alright, just try making the changes to the files and reboot.

Using a pre-built exe like that you will be kind of limited to what it has been set to handle etc...

WOO HOO!! Ok, so, I got MY live version compiled...now I can't figure how to make the MUD run so I can log into it...I know, I know, everyone's probably like.."WTF, this guys a MORON..." HA HA!

Hmmm....ok, well. next, I THINK I got something running...not sure what though to be honest...here's what happened...

I compiled cleanly, worked like a charm with a new codebase, so I must have done something to the other one I was using...then, after a bit of searching through http://www.gammon.com.au/smaug/howtocompile.htm#compile I found the $ "tcsh startup &" command...now...Following the instructions on the webpage that I linked...I couldn't get, or find, the "smaug.exe" file like the website said....Anyway....after I did the start up command I got this in my PuTTY...

$ tsch startup &
-sh: tsch: not found
[1] + Done(127) tsch startup

Then, when I tried to log in through MUSHclient I get this...

SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1

Then when I type any command I get...

SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1

Then I get disconnected.

At least i'm getting somewhere!!

Well, what port do you use?

The basic startup command is set to port 4000.

If that's your port that you're able to use with your host then just do this.

nohup ./startup &

and voila it's up and running on port 4000.

You can check this by typing ps ux in the command prompt in putty.

Then just connect using mushclient to the IP and port number.

Notice the command is tcsh, not tsch that you typed into Putty so you haven't really started the Mud yet. Should look like this;

[wren@srv17 ~]$ cd smaugfuss
[wren@srv17 smaugfuss]$ ls
area      clans    councils  hotboot         mudprogs    SmaugFUSS.dev
backup    classes  deity     imc             player      src
boards    color    doc       log             races       system
building  corpses  gods      Makefile.devcc  README.1ST  watch
[wren@srv17 src]$ tcsh startup &
[1] 9712
[wren@srv17 src]$

Or, you could use the nohup ./startup & command as mentioned above. I believe that allows you to exit the Putty window without shutting down the mud.

Edit to add: Trust me, no one thinks you're a moron, we've all been here

It should also be noted that running tcsh startup & from the smaugfuss directory will not boot the mud or anything. Have to be in the smaugfuss/src directory for it to even find the startup file. And on a quick side note in case you ever run it using gdb or actually run the smaug exe yourself once you start it up you would have to switch the directories over to the smaugfuss/area other wise it will just give bug messages and finally exit out.

To run it do this

cd smaugfuss/src
nohup ./startup <port #> &

and then connect to the host at the port # you specified.
You can also leave out the port # part and it will use the default in the startup file.

If you were wanting to run it in gdb to check for problems etc... it would be like

cd smaugfuss/src
gdb smaug
cd ../area
run <port #>

But you should probably read up on some of the gdb howtos that people have done.