11 Oct, 2016, Mikkamel wrote in the 1st comment:
Votes: 0
Recently me and a friend aquired the library and driver for an old MUD - long since shut down - that we used to play as kids/youths. We really want to start it up again, even if it is very possible that no one but us will play, just to reexperience some old memories. We were told by the original creator that we should have no problems just starting it up, since everything we needed was the hard drive it came on. This was good, because neither one of us have any experience with programming or Linux.

Of course, everything immediately went wrong. What follows is everything we've gleaned about what the problem is:

The core issue is that the MUD we've aquired is in Swedish and so it uses the scandic characters å, ä and ö. It was also made by a group of people not perhaps following best practice, so those characters are all over file and method names. This used to work in the original MUD, but it was written in the ISO 8859-1 charset, while the standard today is UTF-8. What this basically means is that the file system for the computer always takes whatever bytes you send it and looks for matching bytes in UTF-8, but those three characters have different numbers in the two charsets, so it fails to load any file with those three characters in it.

Amazingly, a few years ago someone tried to start up another Swedish MUD and ran into very similar issues, receiving very helpfull replies here: https://groups.google.com/forum/#!msg/ld...
Converting the entire library to UTF-8 and recompiling the driver with some slight changes should theoretically fix the MUD, at least well enough for our purposes.

This leads me to our second problem:

The MUD in question runs on a slightly older version of LDMud, with quite a few changes, many of which are concerned with allowing the problematic characters in the game. And no matter what we do, we just cannot get the driver to compile. Every issue that we solve leads to a new one. The first major problem is that the driver will not accept a 'make' command without running 'configure' first. And 'configure' resets every single change the creators made to the driver to LDMud defaults. We have some documentation for what those changes were, but with our lack of coding experience this makes every attempt take hours, and we never know if we just made a mistake somewhere or if it just didn't work.

We also ran into issues where apparently our versions of Ubuntu are 64-bit, but the MUD was written for 32-bit. I think we've solved this one by installing the correct architecture and running a 'make clean' command before 'make' to solve input/output problems that aborted the compiling. At least I managed to compile something named LDMud, but when I run that version I just get a "segmentation fault (core dumped)" message.

We're at wits' end here and I figured that since this is a community for MUDs that actually appears to have some active members it couldn't hurt to ask for help. I'm sorry for being so long-winded and probably not knowing what information is/isn't important, but you guys are our greatest hope.
11 Oct, 2016, Pymeus wrote in the 2nd comment:
Votes: 1
Mikkamel said:
Recently me and a friend aquired the library and driver for an old MUD - long since shut down - that we used to play as kids/youths. We really want to start it up again, even if it is very possible that no one but us will play, just to reexperience some old memories. We were told by the original creator that we should have no problems just starting it up, since everything we needed was the hard drive it came on. This was good, because neither one of us have any experience with programming or Linux.

Is the hard drive just mud files, or the complete OS? If it's a complete OS, imaging the hard drive and running the image in a virtual machine may be a lot less effort. If it's not a complete OS, you may still be able to download install media for whatever distro the mud previously ran on.

All this assumes that you intend to run it locally; I certainly wouldn't recommend running a decades-old OS on a public VM instance.

Mikkamel said:
The core issue is that the MUD we've aquired is in Swedish and so it uses the scandic characters å, ä and ö. It was also made by a group of people not perhaps following best practice, so those characters are all over file and method names. This used to work in the original MUD, but it was written in the ISO 8859-1 charset, while the standard today is UTF-8. What this basically means is that the file system for the computer always takes whatever bytes you send it and looks for matching bytes in UTF-8, but those three characters have different numbers in the two charsets, so it fails to load any file with those three characters in it.

Consider converting the scandic characters in the source files to some ASCII character(s). As I understand the driver/mudlib relationship, this should have minimal impact on the playing experience.

Mikkamel said:
The first major problem is that the driver will not accept a 'make' command without running 'configure' first. And 'configure' resets every single change the creators made to the driver to LDMud defaults. We have some documentation for what those changes were, but with our lack of coding experience this makes every attempt take hours, and we never know if we just made a mistake somewhere or if it just didn't work.

I'm not sure I understand the situation. Do you mean that you have to run "./configure" before you run "make" each and every time? Or is "./configure" only needed each time you start over from a fresh copy of the mud?

Mikkamel said:
We also ran into issues where apparently our versions of Ubuntu are 64-bit, but the MUD was written for 32-bit. I think we've solved this one by installing the correct architecture and running a 'make clean' command before 'make' to solve input/output problems that aborted the compiling. At least I managed to compile something named LDMud, but when I run that version I just get a "segmentation fault (core dumped)" message.

Do the compiler commands that you see from 'make' have a -m32 switch? This is what tells the compiler to produce a 32-bit program instead of 64.
12 Oct, 2016, Mikkamel wrote in the 3rd comment:
Votes: 0
I'm sad to say that we only got the driver and library, not the OS. The OS in question is an old version of Ubuntu, and we've tried to install older versions of Ubuntu to run it on, but we've only managed to get to a warning message about that version of Ubuntu not being supported anymore, then it switched to a more modern version. We've also tried to tell the version we got stuck with to read files in ISO 8859-1, but that broke absolutely everything so badly that we needed to reinstall the OS.

We've thought about converting the scandic characters to something else, but unfortunately this is thousands of files, with many of them referencing each other, so that is a lot of work. If we could automate the process that could make this step easy, but we don't actually want to remove them from the text of the game. We've managed to log into the game using the old driver, and the scandic characters work just fine in descriptions of rooms, etc, but we can't do anything in the game, since commands like 'east' contains the troublesome characters.

Yes, we have to run './configure' before 'make' every time the 'make' command successfully compiles anything. Otherwise the 'make' command just says something about "ldmud/mk-patchlevel.sh", which seems to be a github file and does nothing. Our general lack of knowledge means we would like to be able to, say change one line in machine.h and recompile to see if we get different results, but currently we have to run './configure' again every time, which deletes all the changes we've made.

Finally, 'make' does not give me any options, but the documentation for installing LDMud says we can set CFLAGS, LDFLAGS and EXTRA_CFLAGS prior to './configure' to "-m32" in a section called "Compiling for 32-bit environments on 64-bit systems", so I guess that's an option. The problem here is that we don't really know how to do this, since we have absolutely no clue about programming. My instinct is to just CTRL+F those names and improvise, but I don't know in which files to look for them, and wouldn't './configure' just reset that too to default? This is still the best suggestion I've heard and I am absolutely going to try that as far as I'm able.

Thank you so much for your response! We've tried to ask for help on coding and Ubuntu related sites, but the responses we've received have been extremely negative and unhelpful. We are pretty unqualified to do this, but since no one else is going to we will have to try. I cannot tell you how encouraging it is to receive an answer that isn't mocking and derisive.
13 Oct, 2016, Pymeus wrote in the 4th comment:
Votes: 0
That sounds… maybe not wrong, but strange. "configure" is unfortunately something of a weak spot for me. I hesitate to give advice based on the ldmud github repo, since you say your code is fairly old.

I've set up a throwaway email 13cd8ef7-08d2-4ff2-825e-97071dfc0aea@tharel.net. Could you zip up (or tar) copies of the *original* Makefile (or Makefile.in, whatever you've got), and any configure-related files (such as "configure" itself, any autoconf/ directories or configure.ac files that are present), plus mk-patchlevel.sh and any other .sh files, and shoot me an email? Don't necessarily expect all of these to exist; just send whatever you can find.

Let's try to keep the actual discussion here on mudbytes; someone more experienced with configure or ldmud may see something I don't.
13 Oct, 2016, quixadhal wrote in the 5th comment:
Votes: 0
My suggestion is to go download a linux installation image from the timeframe your old game was live, and then install that in a VM. Virtualbox works well, or VMware, whatever you like.

It's far simpler to just run a VM of the proper environment to make things work the way they did at the time it was live and running, than trying to fix EVERYTHING that's changed in however many years have passed, all at once. If you get it running on the VM, you can easily start taking baby steps back to the present, by making another VM with a newer OS version and fixing those issues, and repeating until you're using a current OS.

Or… if you don't care about that, just run it under the old OS VM for good. Your users will never know the difference, and it's just as easy to SSH into a VM as it is to SSH into a physical machine.

I use Virtualbox to run antique LPMUD's from the days of Slackware 3.3. Just enable bridged networking if you want it to be accessible from outside, and it'll look just like a physical machine as far as your router is concerned.
14 Oct, 2016, Mikkamel wrote in the 6th comment:
Votes: 0
Ok, I sent Pymeus our original .tar for the driver. That way I can be sure that I didn't fail to include anything important.

Also, the VM suggestion sounds very promising, though I have never used a VM and have no idea how to set one up. I'll be looking at that this weekend. The main problem here is that at least for the purposes of what I'm trying to do I am incredibly inept at computers. I did not know that a VM was an option until you told me. I certainly hope it will be as easy to SSH into a VM as into a physical machine, because I don't know what SSH stands for or how to do it. But these are all problems I can probably google fu my way through once I have some free time. The problems that I am afraid of are the ones that are either so specific to my particular case that I can't find a good way to start learning about them (mk-patchlevel.sh for example), or so general that I can't find a way of applying them to this project ("segmentation fault(core dumped)" is as far as I understand pretty much the equivalent of "has encountered an error").

Since LDMud is a direct descendant of LPMUD, I am very excited to hear that you have managed to run an old MUD on a VM and I guess I'll be spending the next few days learning about how to set one up.

On the other hand, that one thread of a guy running into pretty much the same problems as us has a pretty much step by step solution for this exact problem, so if there was a way to compile a working version of the driver without rewriting it from scratch I could pretty much copy/paste my way to victory, at least in theory. That solution is apparently pretty brute force and would lead to "¼" being a valid letter to use in character names among other things, but that shouldn't really be a problem in this case. Thanks again for the help!
14 Oct, 2016, Mikkamel wrote in the 7th comment:
Votes: 0
I also have to completely purge my laptop and reinstall Ubuntu, because I tried to tell it to stop reading files in UTF-8 and start reading them in ISO 8859-1. At least the "Stop reading files" bit worked great. Above expectations, really!
15 Oct, 2016, Pymeus wrote in the 8th comment:
Votes: 0
I'm not sure how soon I'll have time to dig any further, so here's an update. It's long; sorry about that. These directions were tried under Ubuntu 14.04 (Trusty). 12.04 and older versions of Ubuntu do 32-bit support a bit differently.

You have a few misconceptions which aren't too surprising to find in a non-programmer.

Most importantly, the tar file already contains compiled driver which appears to still work under Ubuntu 14.04 (Trusty). It's the file in ldmud/src/ called "ldmud". If when trying to run the driver ("./ldmud") you get a message "No such file or directory", this is usually an extremely unhelpful way for a 32-bit program to tell you that it can't find 32-bit versions of its libraries. So, install them:
apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

You don't necessarily need all of these actual libraries, but their dependencies will pull in all kinds of other libraries and I've not weeded out exactly which are needed.

Second, I don't think you need "./configure" at all. It kind of screws up things and didn't do anything that seemed helpful at least in my setup. If you do try anything with "./configure", this will tell it that you want to compile to 32 bits.
./configure –host=i686-linux-gnu "CFLAGS=-m32" "LDFLAGS=-m32"


Third, what you have here assumes that the game files will be stored at /usr/svmud/, so make a place for it. If the user you're using to compile the mud is called MUDUSER, you'd do this:
mkdir /usr/svmud/
chown MUDUSER /usr/svmud/

/usr/ is a system directory, so you need to either be root or use sudo to make these changes.

Fourth, "make" doesn't seem to do anything for you because the tarball already contains a compiled ldmud driver and object files (*.o). "make" in the ldmud/src/ directory has nothing significant to do until and unless you change some of the code, You can force it to clean house and recompile from scratch ("make clean", then "make") if you want. Before you do, you'd probably want to edit the ldmud/src/Makefile and change the CFLAGS= and LDFLAGS= lines to ensure that -m32 appears in both.

Fourth, there are some additional utilities that did not come compiled. I have a feeling that they're not needed if the previous owner didn't bother to compile them, but let's assume that they are needed. First, you'll need gcc's "multilib" functionality installed. For example, if you have gcc 4.8 installed, install package "gcc-4.8-multilib". Then under ldmud/src/util/, find all of the files named "Makefile" and again add -m32 to any CFLAGS= and LDFLAGS= that are missing it. There are 5 such Makefiles.

Fifth, install the driver to /usr/svmud/. First, install the package "help2man", then go to the ldmud/src/ directory and do "make install". If you compiled the utilities, go to ldmud/src/util/ and do "make install" there too.

Sixth, copy your mudlib directory to /usr/svmud/mudlib/.

You can then run the driver by running "/usr/svmud/ldbin/ldmud". The driver doesn't like something about the mudlib that came in the tarball, but at least it doesn't segfault (yet). The driver does this whether I use the compiled version that came in the tarball, or compile everything myself.
2016.10.15 16:11:21 LDMud 3.2.15 (Build 2325) (development)
2016.10.15 16:11:21 Random seed: 0x58028d69
2016.10.15 16:11:21 Attempting to start erq '/usr/svmud/ldbin/erq'
2016.10.15 16:11:21 [erq] Amylaar ERQ Oct 15 2016: Path 'erq', debuglevel 0
2016.10.15 16:11:21 Hostname 'XXXXX' address '127.0.1.1'
2016.10.15 16:11:21 Failed to load master object 'secure/master'.
]Failed to load master object 'secure/master'!
2016.10.15 16:11:21 [erq] read: EOF
2016.10.15 16:11:21 [erq] Read 0, should be 9!
2016.10.15 16:11:21 [erq] Giving up.

And that's as far as I've gotten. I don't really know what I'm doing inside the actual mudlib, at least not yet.
16 Oct, 2016, Mikkamel wrote in the 9th comment:
Votes: 0
First off, thank you so much for looking at this!

Roughly the first half of what you said was stuff that we had already figured out. I know that there is a compiled driver in ldmud/src, and I specifically need to recompile it to make it work with UTF-8. The problem is that they added the scandic characters to a list of allowed characters in file names, but since the driver reads files in whatever format is standard for Ubuntu it doesn't work. And converting the mudlib to UTF-8 doesn't work either, because that just allows that letter's number in ISO 8859-1, and since those are different between the charsets everything collapses. I think I can figure out which changes I need to make, but without being able to actually compile the driver I couldn't tell. Hopefully "-m32" will make the driver work as well as the old one (that is: not at all, but if I can compile a version producing the same
error messages as the original I can start to think about which changes I actually need to make.

We also managed to figure out how to install i386 architecture so that we could find the driver and run it. We managed to start up a broken version where nothing containing the wrong characters worked. And with the architecture installed and a "make clean" command I managed to compile something. Still needed to run "./configure" before compiling, but at least it was a file called "ldmud". Unfortunately that one just produced a segmentation fault when I ran it.

I'm thinking that the CFLAGS and LDFLAGS thing could very well be the reason. So next I'll try to do that. Once I've managed to get my Ubuntu to open anything at all, including the terminal. I think I told it to work exclusively in a charset that doesn't exist by accident.

You are truly a hero both for helping with this and for taking the time to write your answers in a way I can understand without hours of research. Thank you!

Finally, if anyone wants to look at this, I uploaded both the driver and the library to a file hosting site;

http://www.filehosting.org/file/details/...
http://www.filehosting.org/file/details/...
19 Oct, 2016, Pymeus wrote in the 10th comment:
Votes: 0
Mikkamel said:
I know that there is a compiled driver in ldmud/src, and I specifically need to recompile it to make it work with UTF-8. The problem is that they added the scandic characters to a list of allowed characters in file names, but since the driver reads files in whatever format is standard for Ubuntu it doesn't work.

Honestly, this doesn't track. The system at the "let's open and read a file" level has absolutely no concept of UTF-8, ISO8859-1, or any other character encoding. C isn't much more aware of encodings. It's all just bytes – encoding exists at a higher level. So, trying to get your system to "stop reading files in UTF-8 and start reading them in ISO 8859-1" is almost certainly a losing proposition.

The file names in your driver tarball all look like they're UTF-8 encoded. The mudlib files contain (indirect) references to these files which are encoded in an older 8-bit format, presumably ISO8859-1. If you're getting huge numbers of errors like "Caught error: Failed to load file: 'path/to/file.c'" in the console when you start ldmud, try converting the filenames in your mudlib to ISO-8859-1:
apt-get install convmv
convmv –notest -r -f utf8 -t iso-8859-1 /usr/svmud/mudlib/


Not sure I can offer much more. Not speaking the language, I can't really do much once the mud server is loaded and running.
19 Oct, 2016, quixadhal wrote in the 11th comment:
Votes: 0
It also makes a difference if you're using Windows vs. a unix type system, sometimes.

Windows doesn't have a true case-sensitive filesystem. Rather, it has a case-retaining system, which is normally fine… but if you had two separate files such as makefile and Makefile, one will overwrite the other.

Since you're using files that have a non-native character set, it's entirely possible that you may get conflicts like that, or that it may not let you use a filename with an invalid UTF-8 sequence in it.

My suggestion is to set up a VM with an older version of your OS of choice (ideally the one that was used during the game's development), and set the locale to be the correct region for the mudlib's source.

The game driver itself probably doesn't know or care. However, an LPMUD has certain requirements. Typically, there are two objects that MUST be working for the game to boot. There's a "master" object and a "simulated efun" object. The driver usually has a config file that specifies where these are found, and also where the mudlib's root directory is. Go edit that.

Basically, the driver will load the sefun object to override any driver efuns (or wrap them in mudlib security), and then load the master object. It will provide hooks that get called whenever driver events happen, such as a new connection, data showing up on a socket, etc, etc.

Unfortunately, the best resource for this kind of thing was lpmuds.net's forum, which has been down for months now.
25 Oct, 2016, Mikkamel wrote in the 12th comment:
Votes: 0
Ok… I think I've got it working on a VM, for a given value of working, or at least it spits out a "LDMud ready for users.".
Now I have no idea how to make it accept connections, what port to use, how to open ports for connections, what ip I'm supposed to connect to, etc. (It says that it is running on '127.0.1.1', but unless I'm mistaken, that is just a fancy number version of localhost. But thank you so much for your suggestions! Using a VM probably saved me weeks of work, and that convmv command apparently solved the scandic characters issue, or at least I don't get an error message for every file containing those letters any more.

So… When I have a driver up and running on a VM, how do I connect to it?
I use Virtualbox, and I enabled bridged networking in the settings, but now what do I do?

Since I worked through the summer, I just started a two week vacation, so now I really have the time to work on this!
25 Oct, 2016, quixadhal wrote in the 13th comment:
Votes: 0
If you're using bridged networking, your VM will show up on your LAN just like any other physical machine. If you use DHCP, it'll get an address from your DHCP server (likely a router). If you hard-coded an address, it'll use that. If you didn't set up networking in your VM's OS, it won't do anything (of course). :)

Even if all you have is localhost, you can still use the VM's console to log in. Most unix varients will have the good old telnet command. You might also use a mud client like tinyfugue. If you DO have it on your LAN, you can use whatever client you normally use.

What port it listens on, and what interface, will likely be in the mud's configuration setup. I'm not overly familiar with LDMUD, but I assume there's an FAQ somewhere for it. It will probably be in a config file you pass to the driver.
25 Oct, 2016, Mikkamel wrote in the 14th comment:
Votes: 0
Pretty much the only part of the first paragraph that I understood was the smiley. But on the other hand that makes me pretty certain that I did not hard-code an address, or set up networking in my VM. The only thing I did was select "bridged networking" from a menu in Virtualbox. Is there some kind of guide to doing any of those things? :)

On the other hand, I did forget about telnet, and my god, it actually worked! I could log in and everything seemed to be working!

Portnumber may actually be pretty simple. I found this in the documentation:

"The invocation syntax is:

driver [options] [<portnumber>]…

<portnumber> the number of the port the driver shall use to accept connections. The maximum number of ports is determined by MAXNUMPORTS in the source file config.h."

So unless I'm misunderstanding everything, I just need to open any port and invoke it when I start up the driver.
I still have no idea how to set up networking, hard-code an address or open a port number, but thanks to you guys this is actually running!
28 Oct, 2016, Mikkamel wrote in the 15th comment:
Votes: 0
And it is online!

I'm leaving it running on a VM for the moment, possibly we'll get a server in the near future, since DHCP changes the ip-address of the VM all the time, which isn't ideal. However, getting a static ip address simply cannot be an impossible task, and for today at least I am happy to just send the new address in a message when it switches.

I just wanted to say thank you! Pymeus and quixadhal, without you there is simply no way I would have ever managed this. I mean, when this started I had never used a Linux OS, did not know what a charset was, and every attempt to find out more about what I was trying to do resulted in hours of googling acronyms that meant nothing to me (For example, when you told me that it was just as easy to ssh into a VM as into a physical machine, I spent a lot of time looking into what ssh stood for, watching tutorial videos on how to ssh into a computer, trying to install openssh on my vm, starting up a new VM with a more updated Ubuntu to facilitate installing openssh, and finally not knowing what I should do with it when it succeeded). I don't think I'm actually dumb, but the amount of new information here was intimidating.

So thank you so much for helping me! Thank you Pymeus for actually downloading the driver and looking at it, and writing answers in what must amount to baby speech for people who know computers. I had misidentified the whole problem and without your help I would have been stuck forever trying to more or less solve the opposite of what the problem was. What you did took more time than I have any right to ask of anyone, and most of our problems were at last solved by copy/pasting the lines you posted. You are a true hero to us.

And thank you quixadhal for your help with VMs! That was another acronym I didn't know anything about, but apart from being half of the solution to our problem, turns out they are a really cool thing that I want to use more! If it wasn't for you, I wouldn't even know they existed, so thank you again!

You guys are the best.
28 Oct, 2016, quixadhal wrote in the 16th comment:
Votes: 0
Glad to hear it's working for ya!

One suggestion, even if you DO get dedicated hardware, you might STILL want to run the VM you have on it. Installing an old OS on modern hardware can be pretty painful, whereas the VM emulates more generic hardware that has pretty wide support for almost any OS out there.

As far as DHCP changing your address… if you're controlling the DHCP server yourself, you can nail that down by binding the MAC address to a fixed IP. If you're letting it grab one from your ISP, you're likely at their mercy. My router acts as my DHCP server, so the only thing in my house that uses a fixed IP is my 12 year old laser printer, because for some reason it seems to not get a valid DHCP response.

Depending on how large it would be, and how much of a PITA it is, you might consider making a "clean" VM with generic passwords for root, the mud account, and the mud admin login, and then uploading it for anyone else who might care. Of course, sometimes a VM image doesn't compress down very well…. and not many will download a 2G image for an old MUD. *grin*
29 Oct, 2016, Pymeus wrote in the 17th comment:
Votes: 0
Glad I could help. To be honest, in addition to helping you this was as good an excuse as any to fill in the gaps in my own understanding of encoding issues. Having goals helped me solidify some assumptions and get rid of others.

Mature and prolific VMs (and their various cousins) are just about the best thing to happen to computers in recent memory. If you want to mess around with static IP addresses, and you have enough disk space, another VM would be a great place to NOT break your PC or the VM you've got the game running on.
30 Oct, 2016, Hades_Kane wrote in the 18th comment:
Votes: 0
Just chiming in… I would have been NO help in any of this, but I've been reading/following it hoping to see it work out for you… glad it did :)

Got some awesome, helpful people around here for sure!
30 Oct, 2016, Mikkamel wrote in the 19th comment:
Votes: 0
Thank you for the additional tips, but I don't really know what a MAC address is or how to bind anything to a fixed IP. I don't really know what DHCP is. Point is, unlike the original problam - which was pretty connected to MUDs - this is something that can probably be solved by calling my internet provider/going to mo local computer store and just nagging them. The internet is full of people willing to help with things that interest them, which is why getting help with these new issues shouldn't be a problem once we start trying (Currently we are just playing), but with no other people interested in MUDs you were the only people who could help us initially, and you did.

There is one related problem. The laptop I bought and switched to Ubuntu in order to be able to do this doesn't want to switch locale. I do the exact same thing as in the VM, switching locale LANG to sv_SE (which is the iso 8859-1 version), but when I do that the terminal doesn't open. This has happened before and back then I just purged the computer and reinstalled Ubuntu. Now I know how to fix it in Xterm, since it is only the Gnome terminal that doesn't open. But this means that I cannot connect via telnet from my laptop. Also, I can't use mudlet, since it apparently converts text to latin1 before sending it for some reason, so I am stuck with a laptop that I can't use to connect to the MUD. Are there any good Ubuntu clients, other than Mudlet, that I could use?

Also, thank you Hades_kane for just being encouraging! After our time of looking through programming/ubuntu forums and asking for help there without being able to really expalin our problem very well, we have learned to really appreciate someone just wishing us well.
0.0/19