You asked me if there's any advantages of JAR over ZIP, and I answered truthfully.
Since Jar was mentioned before and partially dismissed, I just wanted to make it perfectly clear that the difference between zip and jar was almost negligible before someone made a fool of themselves an burst in here with a "zomg, how to open jar on windows? Use zip plz".

That said, jar is mostly intended to make use of the manifest file, and thus its primary purposes are signing files and release distribution. As you've pointed out, for simple project files, which is basically just a collection, and not a runnable, unless signing is desired, zip is just as good as jar, with a very minor edge being that it's more recognizable and does not imply release distribution.

As for how signing files would be achieved from the Java api, I'd have to look into it, since it's not immediately apparent in the JAR api (would probably be a 2-step process: Use another API to sign, and then use the Jar API to stick the signature in the manifest).

[Bug]

Bug: keyword mod is not implemented.
Workaround: Replace every occurrance of "mod" with "%"

Another Bug: I've encountered a strange issue relating to scope and comparisons of numbers less than or equal to 8. Sorry, it's difficult to simplify any further.
Create event:

Code Select Expand

x = room_width / 2;
y = 0;
nextdir = 180;
direction = 180;
speed = 4;
Normal Step event:

Code Select Expand

if (y == 0) direction = nextdir;
nextdir = 0; //this seems to lose scope before the next step rolls around

//enigma handling code
x += hspeed;
y += vspeed;
Draw event: draw something at x,y so you can see what's going on. The figure should always move right, but seems to always move left.

Also, to add to the strange behavior, set y to 24, and then in the step even replace if (y == 0) with if (y == 24). You'll notice it now moves right. In fact, any value greater 8 will work properly. Set it to any number from 0 through 8, and it will lose scope.

Workaround: In the create event, prefix nextdir with "var ", such that it becomes "var nextdir = 180;"

a JAR is runnable.

Java also has native support for JAR in its APIs.

Recall - jar is really just zip with some special rules - namely that the manifest should appear near the beginning.

Also, for those of you checking out r230 or later, you will notice the splash screen has returned.

For those of you experiencing X crashes on Linux when trying to Drag and Drop: Open lgm16b4.jar with a zip manager. Go to META-INF, and edit MANIFEST.MF with a text editor. Remove the Splash Screen line (the 5th line), resave, and update the jar. Sadly, X-crash-fixers will not get to enjoy the Splash Screen, because it was the least intrusive functionality I had to remove in order to stop the X crash. The other options were: Do not jar, disable D&D, or fix X/Java so they play nicely.
You will need to repeat this modification each time the LateralGM jar is replaced, unless I figure out and implement a workaround (seeing as the bug reports offer none at this time after dozens of heads have tried to think of one, I'm going to say the prospects of me finding one are grim).

For those of you not experiencing X crashes, enjoy your splash screen, and laugh politely at the X-crashers.

I've also noticed that global warming has decreased the number of pirates, and that more firetrucks seem to cause bigger fires (and less firetrucks cause smaller fires).

New option added in r225.

Won't this mean that you'll have to change things constantly?
No, these settings are local to each game. When Ism's versioning modifications are complete, this is What it will look like:
Loading a GM6/GMK will set all options to the left (unless Ism adds a mechanism to change this default GM import behavior).
Loading an EGM (which has yet to be genuinely forged, sadly) will load any previously saved settings.

* Creating a new game in LGM will set all options to the right

As of r225, the settings are always set to the left, and other behaviors are not implemented yet. This should change soon.
Not that it really matters yet, because Enigma doesn't even have a mechanism for handling the settings yet.

iirc, they are tiered. The lower tiers allow you to work with the raw data being sent through the network. The middle tiers handle packets for you. The higher tiers handle protocols like TCP and UDP, and ultimately, actual transfer protocols, like HTTP and FTP.

MPlay will be a little more difficult to code since its "protocol" is deprecated, windows only, and massive and proprietary, so I chose not to implement it. You'd basically have to build your own protocol packets, much like you do with 39dll

I don't recall removing it. The splash screen not showing up appears to be another bug, actually.

LGM has been working around this by encouraging anyone on Linux who believes they may encounter this bug to remove the splash screen from the Manifest file in the jar. We've also considered distributing a version of LGM without the splash screen.

Alternatively, avoid using D&D (consider using alternative functionality, if available), and wait for a bugfix in Java or X. According to one of those pages linked before, a fix is expected in java 6u19 or 6u20. Apparently 6u20 beta still exhibits this problem.

A possible workaround is to apply a binary patch if using 6u18.

1) find libsplashscreen.so file (on Debian it is in
/usr/lib/jvm/java-6-sun-1.6.0.18/jre/lib/i386/)
2) take your favorite hex editor and starting from 0x70d0 replace 6 bytes to
0x90 0x90 0x90 0x90 0x90 0x90
3) save the file and enjoy.

Use at your own risk, obviously.

Josh already saw them. I developed them almost a year ago. No clue where they are lying around now. I thought they might already be in the Enigma project. If not, I'll hunt around for wherever I put them.

http://www.ismavatar.com/lgm/forum/index.php?t=11
LGM forum already had a bug filed on this. We realized that it's not a bug with LGM, but seems to be Java-end. The bug is reproduced by having any program with D&D, with a splash screen, running on a specific set of versions of X with specific graphics cards, and only seems to take effect if the program is a JAR. The problem can be worked around either by not using D&D or disabling the splash screen (which can be achieved by modifying the manifest, a text file inside the jar).

Once we realized it wasn't an LGM bug, we moved it from Bugs to Help. It has been an argument between Java and X to figure out whose fault it is. I suspect X.

I developed the mplay-like functions for Enigma, which can be used similar to 39dll. I'm pretty sure I recall developing them cross-platform.

I don't understand. That just restarts X and takes you to the login screen.

Also, if Java freezes up and you don't want to log out, use [Ctrl]+Alt+F1 (or any F-key from 1 to 6), give your credentials, and then $ pkill java