Question Error Connecting to Headless Server

[PickledNipples]

Hi, I have been messing around with the 0.50 release of Terasology on my headless FreeBSD server. I saw on Github that there was an issue with lwjgl not being current on FreeBSD so I modified the Makefile to use lwjgl 2.9.2 instead of 2.9.1 and it seems to have worked but I can't connect to the server. I used the following command to start the server.:

./gradlew start

Then, on my Windows PC, I try to connect to it and it starts connecting and then disconnects. Looking through error log it looks like there are two errors, one when I first connect, and another when I attempt to connect a second time.

The first is:

java.util.zip.ZipException: error in opening zip file

The second is:

19:16:34.105 [New I/O worker #1] ERROR o.t.n.i.ClientConnectionHandler - File already exists at C:\Users\timla_000\AppData\Roaming\Terasology\STABLE\TerasologyStable\50\modules\core-0.50.1.jar

I uploaded the rest of the log file in case you want to look through it.

 

[Cervator]

Huh, the first error is odd, gestalt-module is a pretty core library, normally we might see a module fail.

Are you using the exact same version of the game on both the server and as client? Binary 50 server + binary 50 client should work, but anything outside of that is currently overly sensitive and tends to fail, usually with errors trying to download some part as the game thinks the version it has is off. May be something similar causing the second error.

If you're running the server from source at the stable release 50 codebase ... maybe somehow it is making its own temporary version id that can't match with a local client. But I figure the binary 50 won't work on FreeBSD so that's not really an option

You could try to "gradlew distZip" on the server with the modified game, then launch the resulting binary (from facades/PC/build/dist/app or so) on the server as well as downloading it to your local machine to use (again as binary) for the client.

 

[PickledNipples]

I am using release 50 on both. The interesting thing is when that error occurs, the file "core.0.50.1.jar" is downloaded to the client but the file is incomplete and of size 1 kB. It seems like the client version of the game is 0.50.0 while the server version is 0.50.1.

I am running the server from source. I think somehow it may be mismatching the version info of server and client but I can't be sure.

I tried running "gradlew distZip" on the server but it didn't run as but what did work was "gradlew distPCZip". I tried running the "run_linux.sh" file but it wouldn't work due to FreeBSD not containing the correct Linux shared objects. There are ways to run with a Linux compatibility layer but I haven't figured it out yet. If I could somehow allow Terasology to link to FreeBSD shared objects instead, I think maybe I could get this to work. Do you think that it is possible for me to implement that?

EDIT: I fixed the previous error by replacing Terasology's liblwjgl64.so with the one built on my system and that fixed that issue.

 

[Cervator]

Oh sorry, yeah, gradlew distPCZip, I should remember that as I did that rename some time back, haha.

A long time ago the game actually attached to existing system libraries like LWJGL in some cases, but that was causing trouble on systems with a different version than our target so we forced it to use bundled files. FreeBSD is an interesting challenge that might warrant a way to favor system defaults or external options.

@manu3d / @msteiger what do you think? Is that something we might want to consider a command line flag for? Or maybe a launcher option? Also pinging @Immortius and @Skaldarnar. Or do we even need a headless server to load LWJGL in the first place?

It would be nice to have a more formal solution for FreeBSD (issue #1559) but maybe expanding support this way instead is an option. Perhaps one day a poor suffering soul will arrive from Solaris land and curse the day we stopped bundling binaries for that OS ...

 

[manu3d]

I cannot look at the issue in detail, but NOT loading LWJGL when in headless server mode sounds reasonable. Unfortunately the whole headless architecture is still a bit foggy to me and I wouldn't be surprised if there are reasons to use LWJGL even in headless.

 

[Immortius]

In theory the headless server should be able to run with Null versions of a number of systems like audio and graphics. It still needs to support asset loading so that the assets can be recognized as existing and information from those assets can be gameplay critical - you may need to load enough of a sound to know its duration for instance, or load a skeleton so the necessary entities can be created and manipulated (animation can be particularly important too). But the sounds need not be played, and mesh not rendered, so the Null versions of these assets can be terse.

 

[PickledNipples]

Let me know if there is anything I can do to help with this issue. I have basic Java experience and am okay with scripting and unix/linux systems. I also have the headless freebsd server to test on.

 

[Cervator]

Let me know if there is anything I can do to help with this issue. I have basic Java experience and am okay with scripting and unix/linux systems. I also have the headless freebsd server to test on.

We definitely will, we need some FreeBSD testing! Just a question of when we can prepare something interesting to test

Sorry for the late reply, been busy! But now the weekend is about here, woohoo.