Automated webstart-maker: need game authors

It works! It works, it works! /me dances round in circles like a madman

I’m just uploading an update to JGF which lets you:

  • login
  • create an entry for your game (title, description, authors, etc)
  • upload screenshots
  • upload your JAR files

And then it gives you a URL with an auto-generated JNLP that will launch your game.

However…I’ve only tested it on two games so far. So, I need some authors willing to help test it. Preferably over the next 3 hours (because from tomorrow morning onwards I will have very little time to do any more work on this), but anything in the next 7 days will do.

Please email me at ceo @ grexengine.com with:

  • a list of all files your game uses
  • approximate file sizes
  • name of your game
    • attach your JNLP file if you already have one that works, so I can compare it to the auto one if anything goes wrong!

and I will give you the URL’s to upload your game to JGF.

Whatever problems you ahve, email me instantly, and I’ll use the lsit of files and filesizes and game name to browse the logfiles and either fix the problme or work through it.

Fingers crossed it’ll be working in the morning…

PS out of the many many many hours (probably multiple weeks if you put them all together) it’s taken to get here, my time was spent approx:

40% - SQL being shit, MySQL being shit, or JDBC being shit. All this comes down to just two thigns: 1: MySQL authors were smoking some serious drugs when designing a lot of its behaviour. 2: (85% of the problem) SQL has no compile-time checking in Java because JDBC is so incredibly weak.

20% - reading, re-reading, misunderstanding, and reading again the JNLP docs which are an extended waffle by someone who was a bit bored and couldn’t quite be bothered to explain anything in too much detail. There are still whole sentences I don’t understand, and as noted in other threads here some bits are the opposite of Sun’s own implementation…

15% - working around the general shitness of Sun’s File API. Lots and lots of small ways in which it makes life as difficult as possible, presumably because the original author was writing it in as short a time as possible. About the level of what I’d expect if written in one week from scratch by an intern. Definitely not something you expect from a mainstream systems language.

10% - Eclipse trying to be “helpful” and being a PITA, e.g. by inserting and deleting quotation marks using some hopelessly broken so-called “algorithm” which always does the precise opposite of what you want. Eclipse taking up so much damn memory that I have to wait 2+ minutes because I … typed the letter “d” in the middle of a multiline comment. Why swap then? God only knows…

So, all in all, it’s taken more than 6 times as long as it should have done. But…it’s done. Finally.

That’s just 85%. =/

[edit:]

Oh, nevermind, I guess that was your point. :wink:
The remaining 15% would be “actually implementing”, I guess.

Curios to see you you’ll manage to guess the JNLP extensions needed :slight_smile:

And if anyone’s interested in seeing how this testing is going, then there’s this little page here:

http://javagamesfactory.org/views/all-games-list

which will show each game as soon as it is initially added to the DB. I’ll try to get a proper implementation of games pages, with at least a working ratings system, ASAP once the webstart-maker is finished being tested.

Sure is one hideous site atm!

Cas :slight_smile:

[quote]Curios to see you you’ll manage to guess the JNLP extensions needed :slight_smile:
[/quote]
If I understand what you’re saying…the secret is to also have JGF hosted copies of all of them, and a series of checkboxes:

Your game needs:
LWJGL: 0.94 ? 0.93 ? latest ?
JOGL: …
jME: …

etc. It can then automatically insert a link to an extension file from the appropriate technology.

Of course…the next step is to move the tech JNLP’s into being auto-generated too ;D.

Will you be hosting pre-alphas?

[quote]Will you be hosting pre-alphas?
[/quote]
Good question: the term “alpha” is just because I had no better suggestions come in, and officially we’re still testing :). It has no special significance attached.

What happens is that the game-editor (specific role who overseas all games on the site) has the power to create new “allowed releases” and write a description for each of them. Most releases anyone can make for their game. Some releases - e.g. the “official, JGF tested” release which are the only ones allowed to appear on front page of site etc - can only be created by game-editors (once a normal release has been tested, they can promote it to an official one).

Roughly speaking. So, the idea is to allow you to create a “latest version” which you can update as much as you want, but also have an “official, tested version” (which probably won’t be COMPLETE, simply tested to prove that it WORKS) so that people visiting the site don’t get lots of broken games…

It’s broken. MSIE refuses to send the HTML FORM to the jgf server, for no reason that I can even begin to guess at.

On the site, you surf around, fine.

You fill out the form,and hit submit. It has a URL target for submission of “/controllers/create-game”.

MSIE says “server not found or DNS error”.

You can do a GET to that same address and it works (server returns a 404 not found / 500 invalid request cos there’s no file of that name :))

So WTF is wrong with MSIE ??? Sob Sob Sob

[quote]Sure is one hideous site atm!

Cas :slight_smile:
[/quote]
Gulp. I only today discovered how vile that yellow looks on some CRT’s. My CRT it looked OK, my LCD it looks perfect, but on someone else’s CRT instead of being a very white/pastel parchment colour it looks like banana custard :(.

Like the aged skin on day old skool banana custard, too :x

Cas :slight_smile:

Welcome to the wonderful world of monitors. :frowning:

Let me change the subject of this thread a little:

I desperately need a solution to the problem that MSIE is refusing to submit the main form for uploading games

Without this, we cannot launch the new version of JGF, becuase it’s preventing game uploads. I have absolutely no idea what is wrong. This is pretty desperate.

Up to date info here:

http://javagamesfactory.org/views/newsitem/?id=17

Basically, go to the DEVELOPERS tab, then do “submit game” on the left, and fill out the form and submit it. With MSIE, it returns an inexplicable DNS error, of all things. Sob. Happens to everyone so far, various versions of MSIE. Haven’t double-checked with Moz, Opera, etc.

PS feel free to create “fake” games which I’ll delete later once this is solved!

Hi Adam,

Might I suggest this tool for helping you diagnose the problem? It allows you to see exactly what IE is doing at the socket level. :slight_smile:

I ran your site through Charles, and found that the real problem is that the server is returning HTTP Status 0 (!) which IE doesn’t know how to cope with. The cause is:

java.io.EOFException: EOF reading HTTP headers

No stack trace, sorry. :frowning:

BTW, why do the screenshots have to be JPGs? PNGs should compress nearly as well, and will look much better.

While the IE bug get fixed, you should allow developers to upload with another browser like Firefox. Simply add a notice on the welcome page saying that JGF has problems with IE to upload games.

[quote]Hi Adam,

Might I suggest this tool for helping you diagnose the problem? It allows you to see exactly what IE is doing at the socket level. :slight_smile:
[/quote]
Good idea. I’d briefly considered using a packet sniffer, but thought “look, it’s returning a DNS error, that can’t be anything wrong with the server, can it?” so had put it way to the bottom of list of things to try :(.

Thanks! The chances of there being a problem with that would have been approx 0.01% until very recently since the code has been run without change in many servers for more than a year with most scenarios happening eventually.

But…I patched the status-code code with a 2-line change just last week whilst trying to solve Cas’s problem with his broken ad-ware blocker. So it looks like I broke JGF’s version. Doh!

Anyway, will focus on this now. I was barking up the wrong tree entirely (thinking it was a problemwith the DNS server)
[/quote]
BTW, why do the screenshots have to be JPGs? PNGs should compress nearly as well, and will look much better.
[/quote]
LOL a silly reason: KISS.

  1. Had to hard-code the image filename(s) into the “view game” page

  2. Trying to get the uploads ready before the start of this week, didn’t want to have to handle the HTTP semi-standardized automatic image retrieval system (browser makes a request for an extension-less image).

Because the screenshots are NOT being served by the standard file-service that comes with the grexengine, but by a custom thing for the CMS which is more tightly integrated with the DB, and because the CMS isn’t production ready, if I wanted automated image selection I’d need to implement / finish the prototypical implementation mysefl.

  1. MSIE doesn’t support PNG, so that’s out of the question if only one extension is to be supported.

I hate MS’s attitude to IE (“we bribed our way out of the court case, so now let’s leave our browser broken in major ways it would take us a few hours to fix because … we can”) but shrug have to live with it.

[quote]Hi Adam,

Might I suggest this tool for helping you diagnose the problem?
[/quote]
Please could someone capture that form submission for me? I’m on slow dialup here, and I can’t afford the time for ethereal (8+Mb) and for some reason log4j has its knickers in a twist and isn’t enabling the http-traffic logger (no idea why not).

I think the problem is now a parse failure in the multipart HTTP form submitted by MSIE. It is possible that there’s a bug in IE’s implementation of that, but more likely I just vaped something by accident and eclipse saved it without me realising I’d done it :(.

So, the most important part I need is a trace of PRECISELY what data MSIE is streaming (preferably with line breaks intact) to the server. I’ve got the HTTP headers, but as I said l4j isn’t giving me the raw form (the encoded body) which I need.

Please, someone (anyone) post it here or mail it to adam at grexengine.com

Otherwise it could be several weeks before I can even try to fix this (don’t have much time right now)

[quote]Please could someone capture that form submission for me? I’m on slow dialup here, and I can’t afford the time for ethereal (8+Mb) and for some reason log4j has its knickers in a twist and isn’t enabling the http-traffic logger (no idea why not).
[/quote]
Well, I’m not going to upload an 8Meg file, but I do have the capture that I used to test the error before:

-----------------------------7d51cc159030c
Content-Disposition: form-data; name="action"

creategame
-----------------------------7d51cc159030c
Content-Disposition: form-data; name="name"

Blah
-----------------------------7d51cc159030c
Content-Disposition: form-data; name="sentence"

Blah Blah Blahh 
-----------------------------7d51cc159030c
Content-Disposition: form-data; name="paragraphs"

Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh Blah Blah Blahh 
-----------------------------7d51cc159030c
Content-Disposition: form-data; name="screenshot280"; filename=""
Content-Type: application/octet-stream


-----------------------------7d51cc159030c
Content-Disposition: form-data; name="screenshot64"; filename=""
Content-Type: application/octet-stream


-----------------------------7d51cc159030c
Content-Disposition: form-data; name="logo64"; filename=""
Content-Type: application/octet-stream


-----------------------------7d51cc159030c
Content-Disposition: form-data; name="webpage"


-----------------------------7d51cc159030c
Content-Disposition: form-data; name="submit"

Create Game
-----------------------------7d51cc159030c--

[quote]I think the problem is now a parse failure in the multipart HTTP form submitted by MSIE. It is possible that there’s a bug in IE’s implementation of that, but more likely I just vaped something by accident and eclipse saved it without me realising I’d done it :(.
[/quote]
I used to do my own parsing of multipart data. Then I found out it was randomly failing just for the hell of it. That’s about the time I moved to the Apache Commons component for Multipart handling. Haven’t had an issue since. :slight_smile:

[quote] 3. MSIE doesn’t support PNG, so that’s out of the question if only one extension is to be supported.
[/quote]
Sorry, Blah, but that’s actually outright wrong. IE supports PNG just fine, it just doesn’t support transparencies. Since you’re accepting screenshots, transparency isn’t a problem. :slight_smile:

The logo is more of an issue. However, JPGs for logos look like crap. If you don’t want PNGs, then you should allow GIFs uploaded for those.

[quote] 1. Had to hard-code the image filename(s) into the “view game” page

  1. Trying to get the uploads ready before the start of this week, didn’t want to have to handle the HTTP semi-standardized automatic image retrieval system (browser makes a request for an extension-less image).
    [/quote]
    Dunno about your CMS, but I would map /images/.png and /images/.jpg to something like MyImageServlet. The servlet would take requests for images, then parse out the filename and extension. The filename would be used as the key to find the right image in the CMS, and the extension would be used to produce a MIME of “image/”+extension. :slight_smile:

BTW, did I mention that it would be nice to auto-resize the screenshots for the user? :wink:

Sorry, I meant “cant afford to wait for damn ethereal @ 8mb download for windows!”

Thanks! I’ll see if I can spot the problem, then have a 2nd look at the apache stuff if I’m still stuck.

I consider that to count as not supporting it :), since one of the primary sellingpoint features of PNG is not just alpha but an entire alpha channel, making things look pretty.

Again, under KISS, I had to bear in mind “if Im going to pick one format, which will it be?” hence giving in to the one where we wouldnt get buggered support in things like logos.

Shrug. Making the image type “anything you want” is going to happen soon anyway.

That assumes that images only live in one directory. In fact, being a CMS, they live all over the place (because they are classified by what they’re attached to as much as by what they are) AND there’s no prefix to tell the filetype - you simply don’t know until the file has been identified and looked up in th eMIME mapping - and so it requires a more general-purpose solution.

It should be easy to fix (I think), since there’s already a table-based MIME lookup going on, it’s just a question of splicing in the code to do extensionless file searches and writing the unit tests, checking it all works, etc. Just time that I don’t have to spare right now :(.

What I’d probably do is, when a request comes in for a file which is not found, do a search for all files with that name as prefix, and look at the MIME types for all. If all are the same, then use the q= tag in the HTTP header from browser to pick one to send.

Or something likethat.