Server is up and running, but there's no inventory
 

Greetings,

I have compiled and gotten running two servers on two different OSes, and both are experiencing the exact same problem: I can log in, create a character, interact with NPC's, and wander about the world without any issues. However, I have no inventory.

When I start up my server, I see a message about items loading:

Everything looks ok, more debug messages go by, nothing alarming...

The world log captures:
Everything looks good. I am able to log in, create my character, and start running around the world, except my inventory is empty.

Digging through the logs, I find in files logs/zone-dynamic_0n (where 1 <= n <= 5):
I suspect something may not have compiled right, based on the highlighted error, but I can't seem to find anything that jumps out at me in the file common/SharedLibrary.cpp where the highlighted error above seems to be stemming from.

I built the server binaries from source from August 12:
The database I have is peqdb_rev1589.sql, obtained from http://www.projecteq.net/, which as far as I can tell is the latest and the one that should go with the current source.

Any thoughts on where I might be going wrong?

Thanks for any help.

What OSes have you been using?

Ubuntu 10.04.1 and FreeBSD 7.2-p8 jail, both AMD 64-bit.
Sometimes Zones core-dumps on the Ubuntu system.
Aside from the no-items issue, it runs rock-solid on the FreeBSD system.

Ah, 64 bit. As far as I know, everything doesn't work perfectly with 64 bit eqemu yet. There may be some other people who have posted about their experiences here.

I've been running on FreeBSD amd64 in a jail(7.x-8.x), for quite a while without any noticable issues.
Are you using erde's autobuild scripts here? I'm assuming since you got it to compile you are at least using the freebsd patch included there.

You will need this additional patch as well:
You will also need a line like this in your rc.conf file of the system hosting your jails:

Thanks, amraist!
No, my Google-Fu and Search-Fu were weak, as all I came across were people lamenting how EQEmu didn't work in FreeBSD from a few years ago. And that just wouldn't do!
I did not previously find erde's scripts or patches, I used gmake with the default makefiles, which seemed to work with some slight tweaking:
pretty much the same change to the zone and eqlauncher makefiles.
Then I made a couple changes to the code which seemed to get it to compile and run allright:
and a curious case with how money is handled:
since the value of the money variable is already known to be below 0 (negative), and I'm not seeing anywhere in there you could end up with an imaginary number, I just flip the sign instead of going through the trouble of getting an absolute value.

I'll be pouring over those patches, see how it stacks up to what I was muddling through :)

The bsd.patch included with erde's autobuild scripts will fix the odd coin issue you are having, and also the mutex fix. The scripts may be out of date with the current svn, but its pretty simple to fix them. You just have to track down a new file or two and add it to one of the files included.

Yep. The link in the thread you pointed me to no longer works, but I found the latest version here.

I still needed to fix the issue with trying to use THREAD_MUTEX_RECURSIVE_NP instead of PTHREAD_MUTEX_RECURSIVE (easy fix, that), but everything else seems to be going well. I also noticed there was a new svn release the other day, so I'm trying this out with a fresh code base.

And no dice.:
Seeing what I can do to track this one down. A missing XSLT header file, perhaps?

Upon further thought, a missing library makes no sense, as it was compiling using the default makefiles, and I have verified the presence of a defined symbol "boot_Object" in my already compiled zone. There must be a missing include somewhere.

Found it! zone/perl_object.cpp was not being compiled. Added an entry into the Makefile (and the Makefile.in and Makefile.am in the parent zone directory for future proofing) for perl_object and now it compiles and runs as expected.

Still getting an error, though:
I'm going to guess items are still missing. :/ Oh wel, guess I'll keep plugging away at this...

Did you apply the SharedLibrary patch above and add the line to your jail host rc.conf? I'm sure that will fix your issue.

Yep, caught that after the last post. Now it's core-dumping:
I'm going to guess that the host system must be rebooted in order for security.jail.sysvipc_allowed to work properly (can't just say 'sysctl security.jail.sysvipc_allowed = 1'). Which will have to wait, as this unit also serves up DNS, CIFS, LDAP, HTTP, and I'm sure another half-dozen or so services I've long since forgotten about <:)

No luck. Still core dumping after reboot.

Forgot you will also need this in your jail host's /etc/sysctl.conf
Reboot or use sysctl as necessary.

Thanks! It was kern.ipc.shmall that I was missing (64k is all it takes?). I was up late playing with values of shmmax (currently at 512M) and shmmin (currently back to default of 1).

I don't see any more errors regarding item loading, and it took a lot longer this time. Things are looking good!

Everything is looking good; I have inventory, and things appear to be running smoothly. Thanks for the help amraist!

Looking over erde's BSD patches, I see I did almost exactly what erde did, except instead of switching up to an equivalent abs function, I opted to simply flip the sign of the integers, given they're all known to be below 0 and there's no even-root calls. :)

Glad to hear its working for you. I have a startup script I wrote if you are interested. It works except on startup it seems(last time my jail started, my launcher didn't startup), and I haven't gotten around to tracking that down.

I certainly won't turn down free startup scripts :)

It seems I may have spoken too soon about everything working great. In my last post, I logged in, saw I had inventory, figured everything was great, logged out and went to sleep. Since, I have discovered I am now unable to move, or if I can move there's no gravity. And no sky. I suspect something is up with the zone launch script.

Did download the maps?

Since your source is at a higher revision than your database, you should check:

http://code.google.com/p/projecteqem.../utils/sql/svn

for any SQL with prefixes between your database and source revision numbers and source them into your database.

The particular problem you are having likely requires:

http://code.google.com/p/projecteqem...svn1618&r=1618

OK, I think I'm starting to understand the correlation between DB and EQEmu revisions here, perhaps you can confirm?

Even when doing a brand-new install, simply installing the base peqdb as obtained via CVS is not sufficient. The super-mega DB, peqdb_rev1589.sql, is applied. Then, any sql file with a revision number listing in the utils/sql/svn directory of the source is applied? I just want to make sure I understand this going forward.

Thank you for the help!

When Cavedude releases a version of the PEQ database, it is generally compatible with the current version of the server source code on the day he releases it.

As a new PEQ database is only generally released every month or two, any source code changes that are made in between PEQ DB releases, that require a database change,
will require you to source in the changes from the source code SVN, utils/sql/svn directory.

E.g. July 9th, CD releases PEQ DB Rev 1589, compatible with the latest available source code on that date, Rev 1589.

Source code developers commit changes over the following days and weeks, some of which require database changes, e.g. I commit source
Rev 1618 on 8th August which requires a change to the zone table structure.

If you upgrade from Rev 1589 to Rev 1618 of the source (or are a new user who has just installed the Rev1589 DB and compiled the Rev1618 source),
then you will need to apply any SQL changes that have have prefixes betwen 1590 and 1618 from the source code SVN.

You only want to apply any SQL from that folder for revisions that came AFTER the db revision you are running. So, in your case that would be any SQL higher than 1589. Also, if there are any SQL files for a revision LATER than the actual source code revision you are running, you do not want to apply those.

Thanks, both of those explanations make a lot of sense.

With those sql updates applied, the world and zones are now running properly.
I can move.
I can interact with NPC's.
I have inventory.
There is gravity.
There is sky.
There is combat.
There is a brass key.

> get key

Here is my startup script. It will start world, ucs, eqlogin(login server) and will use eqlauncher to start up zones. So you will need to have one setup in the database. If you notice any bugs, please let me know.

and exactly how did you do that? im haveing the same problem.

I use grep to find where the missing function is defined, and then add that file to the makefiles. You can also figure it out if you are paying attention to the svn logs. If you are using erde's autobuild, here is a patch you can apply after extracting and before running any of his autobuild commands: