Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  JGF feature requests/annoyances...  (Read 1566 times)
0 Members and 1 Guest are viewing this topic.
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Posted 2005-06-05 23:54:21 »

Annoyance

When ever i try uploading my game logic JAR it always gets knocked off the top posistion in the list of jars for that version. I.e. if i upload it first then upload another jar it gets moved down. I then delete the jar that caused the shunting so that the correct jar is at the top. I then re-upload the deleted jar but it still causes the shunting.

This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.

Feature requests

- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
  or allow game owners to edit the generated JNLP file

- Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified.... so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?


Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2005-06-06 07:26:07 »

This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.

Specifying the main-class using the form field belwo the jar list is supposed to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it Sad - are you saying the main-class field/tag isn't working?

EDIT: if you're merely saying you don't want the hassle of doing this Wink then I'm right with you...

Quote
- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
  or allow game owners to edit the generated JNLP file

That's not a trivial change (basic SQL is poor at supporting easy custom sorts), so it's not especially likely to happen unless there's something wrong with the main-class system, or I find myself messing with that page (SQL filter + back-end processing code) for some other reason.

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

Quote
- Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified.... so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?

Yes, this is a nasty bug that was introduced a while back - and is one I've been wanting to get rid of personally for some time. It's a side-effect of two things:
  1. when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
  2. Sun's basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don't take my word for it, and I ought to double-check); IIRC (off the top of my head) you can't even change the codebase to have this effect, and/or changing the codebase doesn't work because you aren't allowed to use ".." syntax - one or the other, which is intensely annoying (and pretty stupid  / shortsighted).

The intended solution was to switch to using the "other" protocol that is built-in to webstart: the "version protocol". Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly Wink) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.

However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won't work with the version protocol.

So ... this needs more thought Sad. Rest assured, I'm working on it, but with webstart on the server you often find that every avenue you try doesn't work because of different bugs or stupidities in Sun's webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works Sad.

Thanks for the comments; if nothing else, they help with deciding what to prioritise next Smiley

malloc will be first against the wall when the revolution comes...
Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #2 - Posted 2005-06-06 12:35:51 »


Specifying the main-class using the form field belwo the jar list is supposed to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it Sad - are you saying the main-class field/tag isn't working?

EDIT: if you're merely saying you don't want the hassle of doing this Wink then I'm right with you...

Unfortunetly no... it does look for the main class in my background JAR which only contains background images when i am using a full qualified main class for a class which is in a totally different JAR. When i download the jnlp and then manually edit the jnlp file so that the jar with the main class is at the top it all works peachy.

Quote

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Quote
Yes, this is a nasty bug that was introduced a while back - and is one I've been wanting to get rid of personally for some time. It's a side-effect of two things:
  1. when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
  2. Sun's basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don't take my word for it, and I ought to double-check); IIRC (off the top of my head) you can't even change the codebase to have this effect, and/or changing the codebase doesn't work because you aren't allowed to use ".." syntax - one or the other, which is intensely annoying (and pretty stupid  / shortsighted).

The intended solution was to switch to using the "other" protocol that is built-in to webstart: the "version protocol". Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly Wink) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.

oh well i guess i will go back to how i was before and combine all the jars into one big uber jar... at least then it is garenteeed to be be first Wink

However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won't work with the version protocol.

So ... this needs more thought Sad. Rest assured, I'm working on it, but with webstart on the server you often find that every avenue you try doesn't work because of different bugs or stupidities in Sun's webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works Sad.

Thanks for the comments; if nothing else, they help with deciding what to prioritise next Smiley
Quote
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2005-06-06 18:56:54 »

Quote

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Developers producing broken code does give Java a bad name.. but  native executables aren't the solution.  Fix the JNLP file.. sure the requirement is stupid, but it is also a trivial requirement to meet.  Move on and complain about the important things.

Offline moogie

JGO Knight


Medals: 12
Projects: 6
Exp: 10 years


Java games rock!


« Reply #4 - Posted 2005-06-06 22:06:13 »

Quote

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Developers producing broken code does give Java a bad name.. but  native executables aren't the solution.  Fix the JNLP file.. sure the requirement is stupid, but it is also a trivial requirement to meet.  Move on and complain about the important things.

LOL!

I would love to but JGF as it is does not let me edit the JNLP file it generates....
Offline woogley
« Reply #5 - Posted 2005-06-06 22:40:49 »

Quote
Quote
- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
 or allow game owners to edit the generated JNLP file

That's not a trivial change (basic SQL is poor at supporting easy custom sorts)

wow, you must be using a poor  SQL implementation if custom sorting is difficult. In my experience (with MySQL, at least), using the "ORDER BY" keyword sorts pretty nicely.

Lets say you added a field to the jar table called "priority" (unsigned int or whatever). You could have the author set which priorty the JARs have via some kind of list (<select> should help with this), the lower the priority value, the higher the priority (i.e. 1 would have more priority than 3).

Then you could sort the JARs by priority with a simple SQL statement:
1  
SELECT * FROM `table_of_jars` ORDER BY `priority` ASC

That would return a result set with the highest priority on top

But this is all just a guess because I don't know your SQL implementation (Postgre, mSQL, etc) and I don't know how you have your DB set up..
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2005-06-07 11:07:49 »

wow, you must be using a poor  SQL implementation if custom sorting is difficult. In my experience (with MySQL, at least), using the "ORDER BY" keyword sorts pretty nicely.

SQL was not designed to do non-relational stuff; this kind of sort "I want one item in one place, and everything else doesn't matter" is not a relational sort.

*Nothing* in SQL is particularly hard - even making a hierarchical XML DB only involves time and slow DB performance - but everything is relative.

For instance, editing a template file by hand (takes 3 seconds), or fixing another feature which needs to be fixed anyway (if something wrong with the main-class attribute) takes a lot less time than altering SQL, debugging it, adding unit tests, etc.
Quote

malloc will be first against the wall when the revolution comes...
Offline woogley
« Reply #7 - Posted 2005-06-07 12:19:13 »

SQL was not designed to do non-relational stuff; this kind of sort "I want one item in one place, and everything else doesn't matter" is not a relational sort.
I wasn't implying that the rest of the JARs don't matter, that's why I added the "ASC" keyword to ensure the next highest priority JAR was next in case the user found the first JAR to be corrupted or something. If I was implying "everything else doesn't matter," I would've used "LIMIT 1" in the query Wink

And since SQL has the lovely "LIMIT" keyword, I don't see where its not designed to single out one row of data.. but thats up to opinion I suppose

...takes a lot less time than altering SQL, debugging it, adding unit tests, etc.

Are you sure you're just not a wee bit on the lazy side Wink A simple SQL query such as that shouldn't take any debugging and wouldn't need very many tests at all Tongue

But still, I'm not sure how your DB is setup, so I don't know how complicated it would be for you..
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #8 - Posted 2005-06-07 18:43:35 »

Quote
the next highest priority JAR was next in case the user found the first JAR to be corrupted or something.

would seem a great idea, but then - [people writing the webstart client] would be writing code that checked each jar in turn, and, um...well, that's what you'd expect in the first place, as the *right* way of doing it, and they already chose not to Sad.

Quote
And since SQL has the lovely "LIMIT" keyword, I don't see where its not designed to single out one row of data.. but thats up to opinion I suppose

It doesn't really matter right now, and this isn't a reason for not doing it now, but FYI generally I want as few SQL queries as possible in this: the JNLP gets accessed rather a lot of times each time a game is played (4, usually!) and the SQL queries currently make it 4 times slower than it is with just all the logic code.

And bear in mind this is accessed EVERY time a game is started, anywhere, even if there's no web browsing going on...

Quote
Are you sure you're just not a wee bit on the lazy side Wink A simple SQL query such as that shouldn't take any debugging and wouldn't need very many tests at all Tongue

Indeed I am sure, because there's a shed-load of stuff on the todo list, and anything that reduces that workload increases the amount that gets done. This isn't laziness, it's pragmatism Grin.

You're lucky if "a simple SQL query" never takes "any" debugging. Since SQL has no compile-time checking (well, on JGF there's a little, but still only 50% coverage or so) any typo takes typically a fair number of minutes to discover and fix (compile, upload, restart server, navigate to relevant page, invoke SQL query, check result, find broken query in log file, go back to source, fix, recompile, and check again...).

Shrug. Obviously I'd rather be fixing things than typing this, but haven't got source access at the mo (still at work).

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (40 views)
2014-09-24 16:13:29

Pippogeek (31 views)
2014-09-24 16:12:22

Pippogeek (21 views)
2014-09-24 16:12:06

Grunnt (47 views)
2014-09-23 14:38:19

radar3301 (29 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (44 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06

BurntPizza (55 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!