Problems with deployment

General Discussion
1

Hey,
So really struggling with deployment.
Initially when I gave out my jme game as a .exe, but quite a few people could not run it. Unfortunately I have no indication as to what those errors were/are at the moment and have been unable to recreate.

So, i’m trying to have this run as an applet. However, the applet gets stuck when loading on “Validating packages”.

I have web start enabled with self-signed generated key and local execution.
When I do this with no signed key, it loads until past “Validating packages” and then just goes white and doesn’t run. This worked back in May fine :S.

I’ve also seen that Java has updated their security and in order to have it run as an applet, it needs to have a trusted certificate? I’m struggling to find a place to get this! The only place I can find is nearly 200$!! Have I misread something or does it literally mean developers can no longer offer free online games without paying for this certificate or being open-source(and thus getting a free one?)?

Final thing for me to do would be to have this as a downloadable .jar file and run. But with both an online applet and a normal executable jar I ideally need this to be obfuscated whilst I’m attempting to secure funding(and once I secure funding, can move towards making this open source as I intend for other users to be able to build their own extensions/adapt to suit their needs because there’s a lot of benefit for others involved to see such customisations)!

But I have issues with this too! I can get the .jar to run, but not when obfuscated. Hence trying to get it working without obfuscation first but failing in all directions! -.-

Additionally with obfuscation I get this error:

\${platform.home}\jre\lib\rt.jar] (No such file or directory)

And have updated

<property name="proguard.library.path" value="${platform.home}/jre/lib/rt.jar"/>

To

<target name="-create-library-property" depends="-create-mac-library-property"> <property name="proguard.library.path" value="${java.home}/lib/rt.jar"/> </target>

(for anyone else that has that problem)

It builds without errors although still gets stuck at “Validating packages. data.jar” when using not signing it and when signing it with my own key(and selecting web deplyoment) I get a whole bunch of key related errors:
Warning: can’t write resource [META-INF/AUIMUAOR.SF] (Duplicate zip entry [jME3-terrain.jar:META-INF/AUIMUAOR.SF])

Similar to this: http://pastebin.com/ifpgy8Tb

Effectively, I cannot find some suitable combination to be able to release! :(.

Any help would be mega appreciated! Thankyou!!

2

Well, not directly related to your problem but some random things to consider. Java applet support is not very pervasive. It struggled for a long time but I think all of the security issues may have finally killed it. Only time will tell. I’m a long time Java advocate and even I feel like Java in the browser is probably dead. It was hard enough to convince folks that it was only a “java in browser” problem and not a more general Java problem.

Either way, if your game didn’t run before then it won’t run as an applet or webstart, either, unless it was deployment related. Most likely deployment cause is that they didn’t unzip before running the .exe (aside from the real most likely cause of the game just not running on their platform… which would be true of the applet as said.)

It might be worth spending some time getting a decent log file rolling system in place. In Mythruna and my other games, I have logging configured to log to a file and then I roll over the last one up to five versions. (client.log is the most recent, client1.log last most recent, and so on) and I log just errors to a separate ${system time}-error.log file with some additional information to help in diagnosing crashes.

No matter what approach you take in the future, you are going to want some way to let users easily report what really happened. With logging you have a ton more information:
-no log file = no Java installed (would still be a problem with applets)
-log file that doesn’t log any of the JME capabilities dump = they didn’t even make it to creating a display
-and so on.

3
@pspeed said: Well, not directly related to your problem but some random things to consider. Java applet support is not very pervasive. It struggled for a long time but I think all of the security issues may have finally killed it. Only time will tell. I'm a long time Java advocate and even I feel like Java in the browser is probably dead. It was hard enough to convince folks that it was only a "java in browser" problem and not a more general Java problem.

Either way, if your game didn’t run before then it won’t run as an applet or webstart, either, unless it was deployment related. Most likely deployment cause is that they didn’t unzip before running the .exe (aside from the real most likely cause of the game just not running on their platform… which would be true of the applet as said.)

It might be worth spending some time getting a decent log file rolling system in place. In Mythruna and my other games, I have logging configured to log to a file and then I roll over the last one up to five versions. (client.log is the most recent, client1.log last most recent, and so on) and I log just errors to a separate ${system time}-error.log file with some additional information to help in diagnosing crashes.

No matter what approach you take in the future, you are going to want some way to let users easily report what really happened. With logging you have a ton more information:
-no log file = no Java installed (would still be a problem with applets)
-log file that doesn’t log any of the JME capabilities dump = they didn’t even make it to creating a display
-and so on.

Amazing, thank you for that response. I guess the only reason I wanted it in the browser was it make it more easily accessible. But I think I’m potentially creating a problem here that doesn’t exist and there’s no need. Won’t focus anymore on running this in the browser.

4

I know that frustration.

  1. If you can, run the .jar from the command prompt on the computer where it doesn’t work. It should fail like the .exe but with a stacktrace visible.

  2. Slightly more elaborate, but what I did for Hostile Sector was to capture the stacktrace in the application and give the user an option to email it. It should be even easier to just type it into a File on the HDD that the user can email to you manually (but don’t expect them to go through that hassle unless they really want to help :slight_smile: )

Edit: speaking of a desktop application.

5

Curious since I don’t use it… is it really hard to get Java’s built in logging to write to a file? For log4j it was just part of a config file.