Hi all, I have already reported this bug on the Git repository but was hoping for a workaround in the meantime.
I am running macOS High Sierra version 10.13.1 and downloaded JME v3.2.0-stable-sdk1 to use inside Eclipse Oxygen Release Candidate 1 (4.7.0 RC1).
I have set up a SimpleApplication with a GameState that extends AbstractAppState and my SimpleApplication (Game.java) is informed of this state.
I can run the application once and I verified that the state was loaded in and running properly. After trying to run the application again, however, I hit a NPE as soon as I launch. I have changed no code; from what I am reading from the log, JME is trying to load a version.properties file but it isn’t finding it so crashing? I have tried telling my Game class to not load defaults for the AppSettings but this doesn’t even get a chance to be called.
The crash log is below (thankfully, it’s short!):
Exception in thread “main” java.lang.ExceptionInInitializerError
at com.jme3.system.AppSettings.(AppSettings.java:222)
at immersiveworks.upgradeit.launch.Main.main(Main.java:11)
Caused by: java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:434)
at java.util.Properties.load0(Properties.java:353)
at java.util.Properties.load(Properties.java:341)
at com.jme3.system.JmeVersion.(JmeVersion.java:51)
… 2 more
This wasn’t a problem when I was testing on my Windows PC so I feel like this is a Mac-specific bug?
This looks to me like it’s a problem with your configuration file. By default, the first time you start jME you get a settings dialog. Subsequent runs load settings from a file with the choices you initially made. Since the trace is coming from the JmeVersion class I’m not positive that it’s that file that’s causing the failure, but I’d suggest tracking down that settings file and deleting it. In your main() you can also call app.setDisplaySettings(true) (verify exact method signature, I’m posting from my phone) to force it to show the settings dialog with every run.
Another thing worth noting:
You are talking about v3.2.0-stable-sdk1 which is our SDK (our custom IDE), but then you talk about Eclipse.
Have you downloaded the SDK to extract the jars there? Or are you using the SDK? Or are you using Eclipse with v3.2.0-stable from maven or such?
The SDK’s last verified working release is v3.2-alpha1-sdk1, neither beta nor stable do work at the moment since the build system crashed during the upload of files.
This might be the cause and if not it helps clearing up confusion.
Hi again, thanks for the support. I grabbed the SDK from GitHub to extract the jars as you stated. I will take another look at running through maven to see if I can resolve the problem as I cannot find the config file anywhere in my running directory. I’ll also check for the alpha build and see if I can get things running. Thanks all for the support so far.
Note that now you could also use the v3.2.0-stable-sdk1 finally. I’ve managed to make it build sucessfully.
That way of getting the engine is completely ridiculous though.
I think you can also get the zip from Releases · jMonkeyEngine/jmonkeyengine · GitHub
Got to hand it to amazon, they can turn something as simple as a drinking a glass of water into a river rapids navigating, boat overturning, drowning mess like no one else.
Personally I got this working by adding far more jar files to my build path than I actually need? But, hey, got everything up and working as intended. So thanks all for the support!!
As others already mentioned, you might be setting up it in a very strange way.
The SDK is Netbeans with lots of nice GUI tools (is similar to the Unity or Unreal editor). The jME SDK is not the jME engine. It is a modified Netbeans IDE that uses the jME engine.
You can also use the source of jME directly (with Eclipse or pure Netbeans or IntelliJ or other tool).
The jME SDK is also nice to prepare assets (like 3d models or terrains) for your game project - so it’s SDK(Netbeans) to make assets game-ready and Eclipse or IntelliJ or other tool for Java coding - if used in this combination.
I advice you to read the links I posted and follow a standard way. That might not only lead to less confusion but also to quicker answers in the forum - since then you can state which standard way of using jME you do.
Having switched back to Windows, I figured the problem would be resolved. But I have hit the same snag regarding the JmeVersion.java file failing to parse the version.properties file inside the jar!
I followed every step as outlined in the guide but cannot work out why this error has cropped up again! It occurred with the same error log, too:
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.jme3.system.AppSettings.<clinit>(AppSettings.java:222)
at com.jme3.app.SimpleApplication.start(SimpleApplication.java:113)
at immersiveworks.upgradeit.main.Main.main(Main.java:10)
Caused by: java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Unknown Source)
at java.util.Properties.load0(Unknown Source)
at java.util.Properties.load(Unknown Source)
at com.jme3.system.JmeVersion.<clinit>(JmeVersion.java:51)
... 3 more
My system won’t let me run the SDK which is why I’ve been trying to get this to work with Eclipse
I have just downloaded a clean version of the jme3-core-3.2.0-stable.jar from Bintray and run my project with just this .jar file as a referenced library and I still get the same crash
(P.S. Thanks for the prompt responses and continual attempts at assistance, I appreciate it greatly!)
Due to administration limits on the laptop I am currently working on (a company-provided laptop), I can’t run the SDK at all. This isn’t a jME bug, just a company annoyance!
The portal version does, however, work, and I’ve got a project set up and running. Not quite the interface I am used to working with Eclipse for a number of years but at least it is working again!
Ah good to know!
Maybe that’s also the reason why the projects fail?
Usually the settings / java properties are stored in the Registry which might be restricted for your device.
This should however not affect Mac OS X and should still not work when using the portable SDK
And FYI the phrase
was because the sdk builds before that were incomplete as they stopped in just that moment where the disk space ran out, so there were half-filled class files etc.