*note* you will need to set a -Xms switch to at least 128M otherwise you may recieve a memory error when playing the executable JAR

The game comes to 6.2meg, i have only included one background world in this version to reduce the size.

Things that are working:

-fullscreen-huge non-repeated-tile map (6400x4800 pixels)-mp3 music-crappy placeholder sound effects-5 different levels of zoom-multiplayer support (LAN only currently)-no theoretical player limit... it will just degrade the game performance

Things not yet working:- advanced game menu settings- world boundaries

Has anything ever worked on JGF? I tried different games a couple of times in the past and none worked. May it be because of SQL-errors, none-existent jnlps, libs etc.

In general, everything works on JGF. But no-one posts "hey, I just downloaded something and it's working!" they only bother posting when something goes wrong or their JVM doesn't do what is expected.

EDIT: at the moment, of course, authors are free to upload crap that isn't even JAR files, let alone a working game. Which is why all the effort is going into trying to make a publishing system so that games only appear once tested, and AUTHORS CANNOT ALTER THEM once published (they'd have to make a new version, and get it re-evaluated and re-published).

But this is an awful large amount of work to do properly without makign life painful and difficult for people. I would really really welcome detailed designs for how to do it...

why don't you look for a QA person to do extensive testing of your server?

Well, professional QA obviously costs large amounts of money which would have to come from somewhere, and it's well known for generating large numbers of extra bugs with little or no help in solving them (stereotype).

So, I'm not sure how it would help .

However, rather than keep quiet about any ongoing issues, I'd appreciate it if you'd reply to this:

For instance, can YOU guess any reason why the same JNLP works on my windows PC with java 5 but not on yours? I'm stumped right now . But if you can give me detailed bug reports there's a chance a pattern coudl emerge which would help solve it.

Webstart problems are often like this, because the debugging info from sun is usually either completely unrelated or deeply unhelpful. For instance, look at what it reports when the URL presented it with a certificate! Far from helpful .

"I have tracked this problem down to a problem with the HTTP cache headersreturned from the slimserver. Most content, including the jnlp file, isreturned with an Expires header on 1st Jan 1970. Some versions of IEdownload the jnlp file, delete the file since the content has expired, andthen launches the Java Web Start helper application. That's not particularlyuseful and explains why JWS cannot find the jnlp file."

And, lo and behold, I use Mozilla. And if I clear it from the cache and try MSIE, it crashes in teh same way.

Now, I've looked at the cache headers using Ethereal (packet sniffer), and they appear correct (ish). So, I guess it's not exactly the same problem as the quote describes. But surely it's the same base problem - that the vile internet explorer deletes the file just before passing it in to webstart.

Here's the headers, in case you can spot something broken that I can't see:

My best guess is that MSIE has a bug in it's handling of "cache-control"? It should be ignoring it, IIRC, but I know that MSIE has *many* bugs in it's header reading (for instance, it crashes if there's no content-length, but completely ignores it).

My best guess is that MSIE has a bug in it's handling of "cache-control"? It should be ignoring it, IIRC, but I know that MSIE has *many* bugs in it's header reading (for instance, it crashes if there's no content-length, but completely ignores it).

Followup: MSIE seems to completely ignore the HTTP specification and how it defines the "Cache-control" header - for instance, it *appears* that the presence of this header causes MSIE to "not cache this response", which is the exact opposite of what the specification states.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org