Hello Game development pros. I recently discovered jmonkeyengine and decided to set it up. when I was done, to test it I decided to run the HelloWorld program provided in the tutorials.
However, when I run it I get this weird error I’ve never seen before:
Info about me: I have a bit experience in networking with java and web servlets and have made a few 2d games (the point is i’m not a total noob to everything).
I use netbeans for my work, and I’m trying to get it to work with JME.
Yes, I have tried searching the forums but nothing has been helpful.
Golden brownies to the fellas that help me! XD
you need to tell java where to look for the native lwjgl library (lwjgl.dll for example).
On the command shell its: -Djava.library.path=.lib/lwjgl/native/win32
you need to add this somehow to the project options in netbeans
hmm does anyone know how to do that?
Would lwjgl be something that is seperate from jmonkeyengine?
here is the set up guide from the wiki.
http://www.jmonkeyengine.com/wiki/doku.php?id=setting_up_netbeans_6.1_for_jme_2.0
If you still have trouble you can try the way lwjgl is solved in Maven Setup Guide:
http://www.jmonkeyengine.com/wiki/doku.php?id=jme_maven_setup#lwjgl_native_libraries
Or just use the whole guide… or ask again for help.
Similar Topic (same):
http://www.jmonkeyengine.com/jmeforum/index.php?topic=10068.0
That might be true but having the newest version of lwjgl on your jre would make it break backwards compatibility? If the newest version works where an old one is expected I don't see the problem.
IMO native files should be inside the jar file with the rest of the lwjgl files and avoid the problem altogether, I have seen it done with some libs that depend on dlls or native files just like lwjgl does.
What happens when jME upgrades to another LWJGL version (like what just happened w/ 1.0 to 2.0)? Also, what happens when the user's JRE upgrades? (Those libraries will not be updated, and ALL lwjgl apps will break)
That might be true but having the newest version of lwjgl on your jre would make it break backwards compatibility?
So basically you are saying that it's fine if older applications break as long as the newest stuff runs? I would strongly disagree...
IMO native files should be inside the jar file with the rest of the lwjgl files and avoid the problem altogether, I have seen it done with some libs that depend on dlls or native files just like lwjgl does.
This would be fine as long as: the native library will upgraded when the JRE is upgraded OR if it is a custom library written by the designers of the application (and not used by any other app), in which case it becomes their responsibility to make sure the libraries are always available and up to date.
I KNOW you spent a fair amount of time on your tutorial and I am not asking you to take it down; but simply to make sure it is as accurate/complete as possible and shows an example of proper software development techniques...
(a lot of ppl may be using the stuff you show them in all sorts of projects, not just jME ones, for a long time; best to start them with good habits :))
basixs said:
What happens when jME upgrades to another LWJGL version (like what just happened w/ 1.0 to 2.0)??? Also, what happens when the user's JRE upgrades? (Those libraries will not be updated, and ALL lwjgl apps will break)
That might be true but having the newest version of lwjgl on your jre would make it break backwards compatibility?
So basically you are saying that it's fine if older applications break as long as the newest stuff runs? I would strongly disagree...
IMO native files should be inside the jar file with the rest of the lwjgl files and avoid the problem altogether, I have seen it done with some libs that depend on dlls or native files just like lwjgl does.
This would be fine as long as: the native library will upgraded when the JRE is upgraded OR if it is a custom library written by the designers of the application (and not used by any other app), in which case it becomes their responsibility to make sure the libraries are always available and up to date.
I was asking if backward would be broken, if that's the case you are absolutely right.
This problem is not a JME problem, it's a lwjgl problem. All natives should be inside the official lwjgl jar (file size is a lame excuse).
When you talk about proper techniques I think having a centralized place to add libraries is a better solution than distributing a copy in each of your applications and having to solve it in every application that uses that library is not a good habit. If versioning is handled properly you should never break backward compatibility (i.e. lwjgl1.0.jar vs lwjgl2.0.jar).
With that mindset I chose to do it the way I did. The problem with that are the limitations in lwjgl distribution and the JVM to handle dependencies properly (java 7 ftw). It might not be the best solution but the other solutions aren't good enough for me either.
Use my solution at your own risk but at least it will get you up and running in no time, you can later figure out how to do it properly.
While you are entitled to your opinion, bear in mind that since no other tutorial does it this way you are possibly causing some bad future problems for new people which in turn will cascade down to the people that are trying to help them. In short, your decision may have some pretty far reaching consequences…
MAYBE (and this would take a little bit) we should teach people how to build w/ Ant Scripts… That would solve a LOT of problems, including this one; and unify the building process…
Ok I don't want to turn this into a who is right and who is wrong thing. I proposed a new way of doing things due my own frustrating experiences as a new user. Seeing this issue popping up once a week should at least make you consider different ways of doing it because it is clearly not simple or easy or straight forward to do the setup as it is now.
I don't want to be annoying and I will not push the issue further but please consider a different solution.
i uninstalled netbeans and decided to get 6.1 so that i could go exactly with the tutorial. whenever I clean and build, I get this note:
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
is this possibly connected to the lwjgl problem?
I think it is quite clear that either our documentation on the setup process is not clear enough, or not easy enough to find. I don't think changing the "package" is really necessary, because in all reality its not all that difficult provided you know how to do it, or you have good instructions in front of you.
I propose adding to the downloads page a direct links to the wiki page for setting up jME. And we need to make sure that the setup guides are complete and easy enough to follow that people don't miss this critical step. Also, making a note about this in the FAQ would be appropriate.
I will do this in the coming days if someone doesn't beat me to it.
hunterbdb said:
i uninstalled netbeans and decided to get 6.1 so that i could go exactly with the tutorial. whenever I clean and build, I get this note:
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
is this possibly connected to the lwjgl problem?
Those are just warnings (not specific to any one library) and can be ignored.
I followed the tutorial EXACTLY, and it doesn't even work.
I'm pretty frustrated with JME. This thing is impossible to set up, so how can people use it?
This is dissappointing. I understand now why nobody makes java games.
JME seems like something that is for file-gurus who are "in the know", the knowledge circle of configuring game engines. I'm just a programmer looking for a new area to work with in java.
I do understand your frustration, however the setup jME uses is also used by a lot of other system; especially open source packages. jME is supplying a LOT of functionality to the end user, and as such as quite a few external dependencies. Take what you have learned here (hopefully you will stick around while people try to help you) and try to make your releases with as little external dependencies as possible (ie. include all the necessary lib and jars directly into any release).
For advice, I would recommend starting over with the NetBeans and SVN tutorial (no offense intended towards the Maven tutorial, 'its just tried and proven'). I had to do it at least 3 times before I saw what steps I was missing…
hunterbdb said:
I followed the tutorial EXACTLY, and it doesn't even work.
Looking at the netbeans 6.1 setup guide linked earlier, the only mention of including the natives is at the very end, in the Project Setup section. In fact, its not even explained what that is for.
This is exactly what I am talking about. In my opinion it needs to explain to the user what and why each step is. Not picking on this one tutorial, as I'm sure most of them are this way. We need to go through them and EXPLAIN things, helping people help themselves and learn.
I haven’t used netbeans for quite a long time (eclipse being my current ide), so out of curiosity, I downloaded it and attempted to follow the instructions (using Netbeans 6.5 on Windows Vista). Guess what - no real problems setting it up at all (and using netbeans 6.5, the instructions are still appropriate).
The only slightly confusing part in the instructions is under the jME2Physics Compilation - Compile Sources it says :-
Set the VM OPTIONS to: … - but doesn’t mention having to change the category to Run: first to find that - maybe thats a change in Netbeans6.5 tho, and I know, fairly trivial to find, but as we seem to be in hand holding mode…
So all that was exactly as done in the page mentioned by core-dump, and the JME samples all ran fine when using right click-run from the project.
I then thought, ok I’ll see what the problem with the tutorial is then (the OP didn’t mention what or where).
If it’s the one at http://www.jmonkeyengine.com/wiki/doku.php?id=tutorial_1_-_learning_jme_2 the one mistake I made first time was not clearing the checkbox for “Create Main Class” - (my bad, didn’t read the dialog properly) but after deleting the main class it all worked fine.
If it’s the one at http://www.jmonkeyengine.com/wiki/doku.php?id=starter:hello_world. Surprise surprise - its the age old JME1 tutorial being used with JME2 code, but that won’t even compile let alone run - so im assuming its the other one. Changed “app.setDialogBehaviour(SimpleGame.ALWAYS_SHOW_PROPS_DIALOG);” to “app.setConfigShowMode(ConfigShowMode.AlwaysShow);” and presto - worked fine.
So to the java developer who is used to Netbeans - delete all , start again , follow ALL the instructions (not just the ones you think are appropriate) and guess what - it works !
Okay, I got it working. I decided to go back and review what made it confusing to me, so that we can help new people like myself better.
http://www.jmonkeyengine.com/wiki/doku.php?id=setting_up_netbeans_6.1_for_jme_2.0
in this guide, I was a little confused about where the dist folder for jme2physics would be, because it says it's in the svn, when REALLY it is in the java application.
oh, and also I was having trouble because as you said, I was using the wrong helloWorld program.
Noobs, make sure you use the right version of a program so you don't pitfall like I did! XD
thankyou all for your help. Golden brownies for all of you!
Glad you got there in the end . . .
It helps if you provide all the details when looking for help - saying which tutorial and providing the link would have made it instantly obvious to many round here (the JME1 / 2 crossover causes much confusion).
All the tutorials in the wiki are editable, if you find something unclear and work out a solution, then make the change and help make it clearer for future people.
From my day job, I know it is really hard to write tutorials aimed at beginners when a lot of what is in there is stuff you take for granted so it helps if the end users can point out the confusing parts (and preferably make the changes in a way they understand).