Installation instructions for Ubuntu?

[trenatos]

Hello, I've been trying to set up a test shard on a ubuntu box, but I'm having issues.

I got the binary and the extra files.

UOX doesn't seem to care what setting I use for DATADIRECTORY though, according to the startup it looks muldata, so in my example /home/useracc/uox3/muldata

Even though I set it to /home/useracc/uox3/datafiles

So I made that folder, muldata, and copied the files in and it's still not finding them, I reuploaded the files to my webserver making sure to set ascii, and used wget to download again but the files are still not found.

Am I missing something silly here, are there instructions for installing on ubuntu?

[Xuri]

Hm. Not sure what could be causing this. Sounds like the changes you're making to UOX.INI aren't taking hold, somehow? Either that or I somehow messed up and made UOX3 look for a static, hard-coded path for those files when on Linux - though I don't immediately see why that should be the case. I'll have to poke at it a bit later today/this weekend to see if something stands out.

[trenatos]

The changes are saved, but even when I create the folder it's trying to look in and drop the files in, it's still throwing Not Found errors on all of them.
Right now I'm just playing around, but I much prefer being able to run a linux VPS for my servers, so if I went with a live shard at some point, I'd much prefer it over a windows VPS or cloud, but it's not crucial or anything.

[Xuri]

Just to be certain - do you have a trailing slash behind your paths in UOX.INI?

Also, I see in the source that the default datadirectory is indeed "muldata", but I'm really confused as to why it would read this instead of what you have in your UOX.INI file. Unless it's not reading the file at all, for some reason, and instead using default values. Hm.

[trenatos]

I just double checked it, it was set to /home/useracc/uox3/muldata/
I tried setting it like the other ones to ./muldata/ but I get the same error, Not Found.

I know the folder exist, and has the files in them (At least a number of them.) but yeah it seems to be ignoring the uox.ini settings, and still not finding the files.

[Xuri]

Very strange. On my Ubuntu (though running through VirtualBox) I have the UOX.INI setup like this:

Code: Select all

[directories]
{
DIRECTORY=./
DATADIRECTORY=./data/
DEFSDIRECTORY=./dfndata/
BOOKSDIRECTORY=./books/
ACTSDIRECTORY=./accounts/
SCRIPTSDIRECTORY=./js/
BACKUPDIRECTORY=./archives/
MSGBOARDDIRECTORY=./msgboards/
SHAREDDIRECTORY=./shared/
ACCESSDIRECTORY=./accounts/
HTMLDIRECTORY=./html/
LOGSDIRECTORY=./logs/
DICTIONARYDIRECTORY=./dictionaries/
}

My UOX3 setup exists in /home/projects/uox3/ and the datafolder in /home/projects/uox3/data/, and if it seems to be working. :/

Wait, is it saying it can't find the files, or that the directory doesn't exist? If it's complaining about not finding the files, it might just be it's using a hardcoded errormessage which includes "muldata" in the name, and you're actually missing the files in that folder that need to be there.

Minimum set of data-files UOX3 needs to run properly:
map0.mul (felucca facet only)
(or map0LegacyMUL.uop in versions between 7.0.24.2 and 7.0.25)
statics0.mul (felucca facet only)
staidx0.mul (felucca facet only)
multi.mul
multi.idx
tiledata.mul
(then you add more maps/statics and/or mapdiff files for worlds other than felucca)

Another thing to keep in mind is that UOX3 will not be able to read .uop mapfiles from clients 7.0.25.7 and newer, so either aim for a client-version lower than that or get hold of a set of mapfiles converted from the new uop-format to classic mul format.

[trenatos]

Yeah my test linux box is on a virtualbox too.

Attached screenshots.

I also set up on my Win7 box (With your help, in another thread), I grabbed the datafiles from the same client that supplies the files for the working setup on my Win7 box.

I'm also having a weird issue where after it shuts down, I can't see anything I type in the console. It still works, just nothing shows. lol

[Xuri]

Very strange. I have no idea what could be causing this, unfortunately.

[trenatos]

The binary you're using, is it the same as the one from the download?

[Xuri]

The very same.

[trenatos]

Very odd...
I'll try wiping the uox directory and redownloading, maybe something got corrupted.

[cnj]

I've tried building from CVS with the same issue; the server looks for everything relative to the binary's path seeming to ignore the values set in uox.ini; has anyone has any luck looking into this?

I then tried the posted binary and existing scripts (DFN/JS since most of these appeared to be empty directories in CVS), with the same result.

I'm runnning on AMD64/X86_64 for what it's worth. I did make some changes to get the server to compile (size_t is a unsigned long int on my system by default), but that shouldn't have affected the pre-compiled binary.

[Xuri]

I am still stumped at what could be causing this :/ Have you tried full path-names instead of relative ones, by any chance?

[cnj]

Two issues I've tracked down. The first is that the example uox.ini files are missing the curly brackets ({}) which are apparently required.

The second is that the map file names are not getting the carriage return ('\r') stripped before they're trying to be open(2)ed.

[Xuri]

Where are you seeing the missing brackets for the directory settings? I'm seeing the brackets in all the downloads from uox3.org.

Couple of things to double-check:
* Don't use map-files from client 7.0.25.7 or later, as UOX3 will be completely unable to read the .uop files from those versions.
* Run all files (except the binary) through dos2unix to solve potential problems caused by carriage returns (dfndata/maps/maps.dfn in particular, in relation to these map-loading problems).

[cnj]

Where are you seeing the missing brackets for the directory settings? I'm seeing the brackets in all the downloads from uox3.org.

Unfortunately I don't have access to the laptop which had the instance upon which I was testing so I can't say for sure. I can say that I started out with a CVS check-out (I'm having trouble finding the repository information now since the link from the install page has been pointing to a closed forum, and I had to find it from another thread originally). Since I was having issues I started pulling files off of the downloads page, but the ini file may have basically been what I got from the VCS.

Couple of things to double-check:
* Don't use map-files from client 7.0.25.7 or later, as UOX3 will be completely unable to read the .uop files from those versions.
* Run all files (except the binary) through dos2unix to solve potential problems caused by carriage returns (dfndata/maps/maps.dfn in particular, in relation to these map-loading problems).

I was using the maps from an un-patched Mondain's Legacy (downloaded from Origin's Web servers). I've since downloaded the Win32 ZIP file for comparison on a Win2k virtual machine, and gotten that running. Everything seems to work there* so I might start copying files back over to the GNU/Linux system. I'm pretty sure I dos2unixed the file (and back in case the line endings were hard-coded) without much change; for testing on the GNU/Linux system I just wrote a method to rip the line ending off [I'm not sure why adding '\r' to MYWHITESPACE wasn't working, but it's been quite a while since I hacked C++ last].

It may have also been that, since I was juggling issues with file locations being ignored, I hadn't tried dos2unixing the right file (it was only the maps file that was giving me issues as far as I could tell). When I have some more time again, I'll poke a bit more in hopes my issue was just that of keeping track of what files I was using.

*With the win32 build, I tried using the spawn file in the thread linked from the downloads page (~93kB), and that caused the server to abort (or die hard enough for Windows to ask me to report it). I didn't try debugging this any further.

[cnj]

OK, so I started over again. Fresh check-out (same CVS repository as is mentioned on the download page, followed the directions basically in viewtopic.php?f=6&t=457 ). I built for AMD_64, which required adding #ifdefs around the declarations in cConsole.{cpp,h} taking size_t as a parameter. I also changed some ints to size_t elsewhere (last time I just commented them out, in some output lines unknown3 etc.; and a few other lines in cConsole to avoid ambiguity). Finally, I creaed a symlink for cPlayerAction.cpp to fix the case so gcc would find it.

I dos2unixed dfndata/maps/maps.dfn but this didn't fix the carriage return problem. As I mentioned, I hacked in a method to clean-up the filename. Later I removed tha hack and dos2unixed maps.4xclients.old (also in that directory) and tiles.dfn, but now I see:
| /home/matt/uo/ultima_online/map0.mul(/) [Failed]
[lots of [done]s]
| /home/matt/uo/ultima_online/map0.mul(/) [Failed]
[more [done]s]
| /home/matt/uo/ultima_online/map5.mul(/map5LegacyMUL.uop) [not found]
| /home/matt/uo/ultima_online/statics5.mul [not found]
| /home/matt/uo/ultima_online/staidx5.mul [not found]

I'm not sure if any of this is a concern yet.

Regardless of whether I hacked in to remove carriage returns or if I dos2unixed all of the files:
Following that, I got to: | Caching Multis....
Program received signal SIGSEGV, Segmentation fault.
UOX::CMulHandler::LoadMultis (this=this@entry=0xad50d0, basePath=...) at mapstuff.cpp:545
545 ptr->Include( items->x, items->y, items->z );

gdb indicates items->{x,y,z} point to bad memory. My assumption is that the getLong() methods aren't searching the intended length. I tried swapping out typedefs for int32_t/uint32_t etc. but there appears to be too much conversion going around (especially around SERIAL) and I gave-up. Giving CFLAGS=CPPFLAGS=-march=i686 -m32 let for a clean compile but it looks like I'm getting linker errors given that I'm not set-up for a 32-bit dev environment (outside the scope of this thread).

Long story short, it looks like UOX3 needs to be targetted at 32-bit machines at the moment. Unless there's a trick that I'm missing.

[Xuri]

The spawn.dfn-related crash you saw with the win32-build should(TM) be fixed in the CVS source, as well as in the "experimental"-build. It was a crash that would occur only when using mapfiles from clients below v7.0.9.0. I fixed the broken links on the install page, btw - thanks for letting me know. If you run into any other broken links like that, let me know and I'll fix 'em straight away.

Btw, if you're using map-files from an un-patched Mondain's Legacy client (or earlier), I assume that means the client-version is lower than 5.0.0a? If that's the case, you should replace the default maps.dfn with the maps.4xclients.old (as in, rename maps.dfn to something else and then maps.4xclients.old to maps.dfn), as the default maps.dfn file is intended for use with clients above 5.0.0a (which has larger maps). That unfortunately isn't made very clear anywhere. Hmz.

Don't think that would affect your compile/link problems though, and I unfortunately have no experience with building for anything other than 32-bit.