When the launcher detects that an update is available, and the user agrees to update (by means of the GUI prompt), then after downloading and installing the upgrade the game quits. Attempts to start it by invoking mule.sh (possibly by means of GUI integration, i.e. a M.U.L.E. starter on your Gnome panel) will fail since that file is no longer executable (but it was before the upggrade).

Possible fixes:

• Either mark mule.sh executable before wrapping it in the updater archive and use tar.gz archives which can retain the executable flag, or...
• have the updater script run chmod +x on mule.sh after unpacking on Linux.

I missed to provide a possibly important detail: the system I am experiencing this error on is a Xen virtual machine. It does not have 3D acceleration available, so this can be the cause of this very general error message. If you think it is, then a better error message pointing people to a web page stating the games' hardware/software requirements would be useful.

I hope I didn't waste too much of your time by not stating the part about virtualization in the first place.

Unfortunately this issue is NOT solved by v1.2.1.

Please let me know if I can provide additional debugging info.

I suggest you install Java 6 (you still have Java 5, and an outdated version of that) and try again.

You should install Java 6 (you still have Java 5).

Also upgrade your graphics card drivers. Use the ones from your computer/mainboard vendors' website. Alternatively, the chip vendors' drivers for this chipset are available at s3graphics.com and may work for you, too. To determine which chipset you have exactly, use CPU-Z.

You seem to have a VIA S3G UniChrome IGP onboard graphics adapter. Those are known to cause issues with games on Windows. It might be worth spending some bucks on a dedicated graphics card if related issues remain.

  INFO [GameController.setModel]                     ++++++++ New Model: CONNECT #0 +++++++++++++++++++++++++++++++++++++++++++
  INFO [Server.<init>]                               Server: Creating
  INFO [Server.<init>]                               Server: Started on TCP address /0.0.0.0:6260
  INFO [Server.<init>]                               Server: Started on UDP address /0.0.0.0:6260
  INFO [Client.connect]                              Client connects...
  INFO [Client.connect]                              Client UDP local address: 0.0.0.0/0.0.0.0:6261
  INFO [Client.connect]                              Client: Connects TCP: /127.0.0.1:6260 UDP: /127.0.0.1:6260
  WARNING [ConnectPhase.begin]                       Client failed to connect to server: SOCKET EXCEPTION: Operation not supported

Looks like you successfully started a local server and the client then tried to connect to it but failed while setting up the connection socket with "Operation not supported". Have you checked whether this can be related to AppArmor?

It's technically easy. The host just needs to firewall all connections but those to the master server at the right time. I'm not saying this is what happened here, though - I could not tell.

I guess the developers will have a hard time debugging this unless you provide log files... Check the topmost post in this forum, it explains what's needed.

After logging in (successfully apparently) or after selecting to play locally the main menu/game screen is drawn but all of a sudden a message box pops up saying:

Code: (Error message)

ExceptionInInitializerError
null

Relevant log files are attached

At least in my case this very issue was caused by this nasty Debian Squeeze bug. Took me a while to realize java did not allow IPv4 network connections generally. Now I've got a new bug but this deserves a new thread.

XP SP2 is no longer supported either. You should upgrade to SP3.

I assume the FAQ is trying to say that you should use the JRE of Sun (i.e. not kaffe or the GNU gcj implementation etc.) since that's what the game is tested and built against, no matter how you install it. Both the proprietary and the open source (openjre/openjdk) variants should work then since the differences are really minor.

Version 1.2 uses 'nohup' on Linux to redirect output to a file. nohup is quite inflexible, usually dumps output to a file 'nohup.out' in the current working directory (or ~/nohup.out if the current working directory is not writable), the name of the file cannot be configured. nohup is meant to prevent hangup signals from causing an application to exit. This is an unlikely event in case of this game, after all the developers can influence which returns signals are produced by their application.

If output is to be redirected (why?) then it should be redirected to a file using the ways the shell provides, namely standard output and standard error output redirection (or piping into 'tee').

Code:

$ diff -Naur mule.sh.orig mule.sh
--- mule.sh.orig	2010-01-10 06:36:11.385625737 +0100
+++ mule.sh	2010-01-10 07:15:55.585704580 +0100
@@ -1,9 +1,20 @@
 #!/bin/sh
-cd data
+#
+# Find java executable and start launcher
+#
 if [ -f "/usr/lib/jvm/java-6-sun/bin/java" ]; then
-	nohup /usr/lib/jvm/java-6-sun/bin/java -jar ./launcher.jar nohup /usr/lib/jvm/java-6-sun/bin/java -Xms64m -Xmx256m -Djava.library.path=lib -jar ./data.jar
+	java_path=/usr/lib/jvm/java-6-sun/bin/
 elif [ -n "$JAVA_HOME" ]; then
-	nohup $JAVA_HOME/bin/java -jar ./launcher.jar nohup $JAVA_HOME/bin/java -Xms64m -Xmx256m -Djava.library.path=lib -jar ./data.jar
+	java_path="$JAVA_HOME/"
+elif [ -n "`which java`" ]; then
+	java_path=""
 else
-	nohup java -jar ./launcher.jar nohup java -Xms64m -Xmx256m -Djava.library.path=lib -jar ./data.jar
+	echo 'ERROR: Cannot find your java installation. Please ensure the JAVA_HOME environment variable is set or the 'java' binary is in your path.' >&2
+	exit 1
 fi
+
+cd data
+"${java_path}java" -jar ./launcher.jar "${java_path}java" -Xms64m -Xmx256m -Djava.library.path=lib -jar ./data.jar
+# Alternatively, redirect all output to data/output.txt:
+#"${java_path}java" -jar ./launcher.jar >output.txt 2>&1 "${java_path}java" -Xms64m -Xmx256m -Djava.library.path=lib -jar ./data.jar >output.txt 2>&1
+cd ..
$

I have a 1366x768 resolution on this Ubuntu system. Gnome has two menu panels by default, one on top and one on the bottom of the screen. By default, both panels are visible. If that's the case and you start the game what happens is that the game window's title bar keeps showing and hiding whenever you click on the game screen, and switching to full screen doesn't seem to make a difference. It's thus not possible to move the window around, and the status line on the bottom of the game can never be seen.

Setting the Gnome panels to auto-hide works around it - the whole game window displays (incl. the status bar on the bottom) and the issue disappears (but the game will not switch to full screen mode, i.e. the gnome window decoration will remain).

Since people will want to play this game on netbooks allowing to resize the game screen via zooming or by allowing to rearrange the chat window size (or even to hide it, after all you don't need it for local gameplay) would be nice.

Windows 2000 SP4 still has security support until August this year (extended support) but you really should switch to something more recent.  Your Java version is also outdated and vulnerable to critical security issues (just like Windows 2000 which has at least 2 critical bugs Microsoft does not appear to be planning to fix anymore). The dual-core CPU and 2G of RAM you have should suffice to run an up to date operating system, either Windows or, if you'd prefer to use your resources more effeciently, some Linux distribution (such as Ubuntu).