Thanks :).
It allows relative requests too, so if you have a JAR with a subdirectory “images”, you can do …
getResource( “images/filename.jpg” );
EDIT: I think I may just drop everything else at some point today and put up a FAQ of things like this that are ultra-common questions, still.
I’m here 
At last, you decide to make it webstartable moogie…
[quote]But… the GTGE copy to clipboard clearly doesn’t work because copy/paste did nothing.
[/quote]
Huh? Are you sure blah3x? What OS do you use?
It use JTextArea.selectAll(); and then JTextArea.copy(); I tried it just now and got no problem…
[quote]What is the peferred way in to get the paths of the resources?
[/quote]
Loading image should be simply getImage(“graphics/titlescreen.jpg”);
And loading resource : bsIO.getURL(“graphics/titlescreen.jpg”); that returns the URL of the resource.
Or bsIO.getStream(…) to return the InputStream.
You should ask this to me instead moogie.
So is the networking bugs solved?
PS: I’m Paupau, GTGE Developer
Linux. And clipboards on most OS’s are non-trivial (windows, OS X, linux). Most OS’s have multiple clipboards, although most manage most of the time to make something that appears in one appear in all (windows is especially good at this).
Off the top of my head, JTextArea might be the broken gui component that you shouldn’t use (but I can never remember which is the one that Sun waited 5+ years to fix, and then only partially so. It might be the other one … JTextComponent ???).
Anyway, copy/paste requires some effort to get 100% right, and even so you may be dependent upon OS quirks. I have a sneaking suspicion that webstart does something moronic, like preventing all running code from accessing the clipboard, silently (!), or wiping the clipboard when it exits - possibly in an attempt to save themselves from having to fix future security bugs in their code when it is found leaking access to the clipboard.
Can’t help. GTGE seems to wait a few seconds and then terminates the JVM?; AFAICS webstart is delbierately obliterating the clipboard on exit.
Also saw a bug just now, with default params, 800x600, no FS, where the window was instead 800x100 or similar, and not resizable.
I seem to be getting a null returned when using the suggested method:
Thread.currentThread().getContextClassLoader().getResource(str)
where str=“data\graphics\titleimage.jpg”
This only happens when the game is converted into a executable JAR…
i am totally at a loss on the 800x100 bug… i am telling the library to change to the selected resolution… I am not sure whether the library even works on linux… maybe role can help us here…
role: I am trying to get the game webstartable in order for people to try it networked to see if you are an isolated case… so far no one has been able to give me any suggestions as to why you get that message saying you cannot join a multicast group.
doh! /me slaps head
I am still using platform dependant file seperators when the specification asks for “/” seperated!
So i changed that and now it no longer gets a null exception, rather it now gets a java.lang.runtime exception when i use the .getFile() method of the returned URL so i can use the GTGE library to load the images…
here is a stack trace when i tried the game as a self executing JAR:
java.lang.RuntimeException: ERROR: getURL (mode=Working-Directory) from: D:\temp
\temp\file:/D:/temp/temp/AnacondaWebstart.jar!/data/graphics/titleimage.jpg
at com.golden.gamedev.engine.BaseIO.getURL(Unknown Source)
at com.golden.gamedev.engine.BaseIO.getURL(Unknown Source)
at com.golden.gamedev.engine.BaseLoader.getImage(Unknown Source)
at com.golden.gamedev.GameObject.getImage(Unknown Source)
at com.moogiesoft.AnacondaNet.game.MainMenu.initResources(MainMenu.java:
44)
at com.golden.gamedev.GameObject.start(Unknown Source)
at com.golden.gamedev.GameEngine.startGameLoop(Unknown Source)
at com.golden.gamedev.Game.start(Unknown Source)
at com.golden.gamedev.GameLoader.start(Unknown Source)
at com.moogiesoft.AnacondaNet.game.AnacondaNet.main(AnacondaNet.java:94)
at com.moogiesoft.AnacondaNet.game.SettingsDialog$StartGame.run(Settings
Dialog.java:205)
at java.lang.Thread.run(Unknown Source)
You can not open up the file, because there is none. The file is an entry in a zip file.
I don’t know how GTGE does it. But there must be a way you can give it a URL or a stream and not a File.
At least the copy to clipboard things works very well in my Windows, it’s only a cosmetic anyway
Developers (GTGE users) can change it easily to make their custom error notification stuff, perhaps directly send the error to their mail.
[quote]Can’t help. GTGE seems to wait a few seconds and then terminates the JVM?
[/quote]
Nope, it will terminate the JVM if only the error notification dialog is not focused.
To copy the exception manually, why not select the JTextArea manually and copy it with Ctrl+C
[quote]i am totally at a loss on the 800x100 bug… i am telling the library to change to the selected resolution… I am not sure whether the library even works on linux… maybe role can help us here…
[/quote]
GTGE works fine in Linux and MacOS X, many tester that have tried in Linux, MacOS X and got no problem. Ummm MacOS users have a slight problem, but not too worrying.
[quote]so far no one has been able to give me any suggestions as to why you get that message saying you cannot join a multicast group.
[/quote]
Too bad, I really want to try it with my friends at work. 
Hope you can fix it immediatelly.
[quote] java.lang.RuntimeException: ERROR: getURL (mode=Working-Directory) from: D:\temp
\temp\file:/D:/temp/temp/AnacondaWebstart.jar!/data/graphics/titleimage. jpg
[/quote]
Guess the exception is quite clear, the titleimage.jpg can’t be found from… urgh what path is that!?
See the mode (mode=Working-Directory), you still using Working-Directory.
For JAR, you should use either BaseIO.CLASS_URL or BaseIO.CLASS_LOADER, CLASS_URL is the default one, and I use it all for my webstart game.
BaseIO.WORKING_DIRECTORY can’t be used, because now the resources is inside the executable JAR.
To get image simply use: getImage(“data/graphics/xxx.png”); No need fancy things.
This is I used for all my webstart game, and it works in Windows, Linux, and MacOS without problem.
For URL, use bsIO.getURL(“data/graphics/xxx.png”); it returns the URL of the xxx.png
And bsIO.getStream(…) to return the InputStream.
GTGE is very simple to use, you make it complicate by yourself.
And remember, the resources (images/sounds/etc) now must be INSIDE THE JAR and relatively to the game main-class.
So if the game main-class packaging: com.game.MainClass
And you get the images with getImage(“data/graphics/xxx.png”); the xxx.png must be in com/game/data/graphics/xxx.png and inside the JAR.
Right. and WHAT DO YOU THINK HAPPENS WHEN I SWITCH TO ANOTHER WINDOW TO COPY AND PASTE!?!?!
Sigh. That was NOT a good idea for a “feature”.
Doesn’t work, the app exits, wiping the clipboard.
Well, that’s because when in fullscreen mode, the error notification dialog (JDialog) can’t be selected (I don’t know how to make it get focused).
So if the user trying to click the dialog but the dialog can’t get focused, it will automatically terminate the JVM after sometime by calling System.exit(); instead of hung.
Common user don’t know (I think) pressing Alt+TAB to get back to window and kill the hung game process from task manager.
So I take this solution If the error dialog not get focused, I guess the player not interested at the exception anymore, then I kill the hung game.
This is not feature, but a workaround
[quote]Doesn’t work, the app exits, wiping the clipboard.
[/quote]
Wiping clipboard??? How can??
After you manually copy it with Ctrl+C, the clipboard is wiped by the game? Humm weird…
Okay, now I update GTGE so it waits for 5 seconds of inactivity (not focus) of the error notification dialog before shutting down the game.
Note: I update GTGE, not moogie game (AnacondaNet).
Had a quick look through the webstart docs, since I’m working on webstart stuff and had the window open anyway, and noticed that you never have access to the clipboard if your webstart app is not using “full permissions”. Doesn’t matter what you do, you simply don’t have access (allegedly, not confirmed myself)… unless you use the custom API provided by Sun for doing clipboard access from within webstart ;). I guess, from what you said, you’re not using that? It may be that it “works for you” simply because you’re using windows, and are taking advantage of a bug that gives you clipboard access even when you shouldn’t have it. Shrug.
Have you tried it at your work yet? maybe it is only your home computer having issues with the game?
I have never used JARs before… i find them very annoying (same with Webstart ) as most non-java people have issues with both and some java people like myself have issues as well. But enough of my ranting!
I really did not want to make my data directory deep inside the directory structure of the JAR package but i guess i will admit defeat and attempt to do that.
all i wanted was people to test out the network play! oh well i guess it has been a “learning” experience.
Jar’s are really very very easy to use, and code that breaks on jars was broken already, you just didn’t know it yet.
You don’t need to, and I agree it sounds painful and irritating. I can only suggest that you stop using GTGE or find a way to make it behave “normally” - most of us wouldn’t dream of doing that arrangement, since it’s non-standard and not usually helpful.
If you just plain, ordinary jars the way they were designed to work then it’s no more complex than “zip [directory name]” (funny, that. JAR’s are, in fact, zip files - you can even use zip or winzip to create them if you like…)
Broken you say 
The Executable JARred version works fine locally:
http://www.geocities.com/budgetanime/anacondanet.html
however when it is made webstartable it seems to get borked… however i believe i have resolved the issue but i cannot seem to use the JGF to create the jnlp sue to some sever side issues.
[quote]Broken you say
The Executable JARred version works fine locally:
http://www.geocities.com/budgetanime/anacondanet.html
[/quote]
Yes, I mean what I say. You can hard-code a path to C:\Windows(something) in a JAR, and it will “work” when run from the command line.
But just because it runs does not mean that your code is correct. It is never ever correct to hard-code C:\ into a java program (unless you are deliberately trying to make it windows only). When you move to webstart, bad programming things like this that you were lucky enough to get away with won’t continue to work for you.
Ah, now i understand. You are assuming i am using a platform dependant hard coded absolute path…
What i find strange is that there seems to be multiple ways of obtaining the current directory but not all are supported for different deployment options.
The point is that you never need to know the absolute path to current directory. You always use relative paths with the classloader. Then the loading works the same no mather how you deploy…
does it work for directory structures below the current working directory? i.e. “...\data\graphics” etc. I would like to do this so that the resources are not deep in the package structure.
is “.” standard across all platforms?
NO, files do NOT go deep in the package structure - ever - it’s just that GTGE’s methods (which most of us here have no idea of since we don’t use it) does that for some reason.
Files are loaded from the root of the jar file, so just jar your files, filename1.jpg, f2.jpg, etc, and then use .getResource( “filename1.jpg” ) or getResourceAsStream( “f2.jpg” ) etc.
[quote]does it work for directory structures below the current working directory? i.e. “...\data\graphics” etc. I would like to do this so that the resources are not deep in the package structure.
is “.” standard across all platforms?
[/quote]
Well, there is no current directory. There is just the directory structure of the jar. All paths given must be relative to the root. There is nothing below the root. To see how it looks open the jar in WinZip or similar. Make sure the paths are relative. It’s possible to create a zip with full absolute paths, and I don’t think that will work.
You must always use forward slashes. Your always allowed to start with a forward slash. So if you wan’t to get test.jpg in the data\graphics folder you would use “/data/graphics/test.jpg”. That will work on all platforms. In winzip the “path” will be shown as “data\graphics”, “name” as “test.jpg”. If it don’t show that in winzip then you have made a mistake making the jar.