Your dog ate your 20-sided? no worries. 
xdmgames.com - This website is for sale! - xdmgames Resources and Information.
should work in Win, Linux, and Mac, but not tested on Mac.
edit: almost forgot, use F1-F7 to roll individual dice, F8 to roll them all. use space to roll dice.
In my Powerbook G4 (OS X 10.4 PPC) it crashed twice… once with no error message, the second one with:
java.lang.NullPointerException
at main.DiceRoller.main(DiceRoller.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.javaws.Launcher.executeApplication(Launcher.java:1161)
at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1108)
at com.sun.javaws.Launcher.continueLaunch(Launcher.java:951)
at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:522)
at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
at com.sun.javaws.Launcher.run(Launcher.java:165)
at java.lang.Thread.run(Thread.java:613)
Also, you might want to change the key bindings to something more Mac friendly, since most Fs are reserved for nice desktop enhancements.
Edit: I forgot to say that I can see the Color chooser window, and once I saw the jME config window... but that is it. :|
im pretty clueless when it comes to mac, I have liblwjgl.jnilib and libodejava.jnilib in the macLibs.jar and
<resources os="Mac OS">
<j2se version="1.5+"/>
<nativelib href = "macLibs.jar" />
</resources>
in the .jnlp file, so it should work but I have no way of testing or debugging on mac
Not to get the code , but if you send me the archive, I could troubleshoot it on this computer and let you know exactly where it fails.
thanks duenez, pm sent.
Funny. The 'rolling' does not let them really roll. Did you consider using the physics picker (probably with different controls) to let the user roll them?
The d20 behaves more like a spinner in the beginning 
yeah I agree Irrisor its not really rolling, I had to keep the dice from hitting each other so I encapsulated them in "areas". when they hit each other they disappear or go flying off into oblivion (tri on tri collision prob). I could have the user roll them but it would have to be one at a time which may take too long if you need to roll them all. maybe I should change name to dice spinner 
Trimesh-Trimesh collisions should work, so you should be able to roll all of them like a person would. See TestTrimesh for a working test. What version of jME Physics did you use?
Well, I am able to run it from the source… so I have no clue what the problem might be with jnlp
On the other hand, I was able to make some dice fall through the floor. They also seem to spin a lot more than they go up-wards.
Good luck with it… if you need further help, I am willing to keep looking at it.
mud2005 said:
I thought this was a known limitation of ODE.
Yeah, seems you're right. OPCODE seems to cause serious problems with trimesh-trimesh collisions. What a pity :(
Trimesh-Trimesh collisions should work, so you should be able to roll all of them like a person would. See TestTrimesh for a working test. What version of jME Physics did you use?
Im using latest JMEPhysics from cvs. TestTrimesh is a perfect example of the problem, when the objects barely collide everything is ok. but try moving the sphere around with the mouse, I get crazy jumps quite often instead of collisions and If I drop a number of objects into a container they jump around like popcorn until they jump out or just disappear. Ive checked their location when they disappear and it returns NaN. Ive tried the same test dropping just boxes without trimesh collision and it works fine, quite stable in fact. I thought this was a known limitation of ODE.
edit: I just ran TestTriMesh after writing this and as soon as the sphere and torus hit the floor they disappeared.
edit again: I modified it so the dice go up higher
My peeking further into the code, it seems that the NPE happened before starting the jME application (i.e. right after color choosing), why don't you check for null after the JColorChooser call and set its value to a default to see if that is the problem?
Yeah, seems you're right. OPCODE seems to cause serious problems with trimesh-trimesh collisions. What a pity
Has anyone tried compiling ODE with gimpact? http://gimpact.sourceforge.net/ supposedly they have solved the trimesh collision issues.
edit: I compiled ode with gimpact, and trimesh collision looks perfect, is it possible to compile odejava-jni with gimpact? I would do it if I knew how :'(
Well I tried compiling odejava-jni with gimpact and had no luck. It seems revision 996 of ode is used in readme.txt and gimpact is not included in this revision.
I tried with latest revision and got as far as this command to compile
g++ -shared -fPIC -DHAVE_CONFIG_H -I…/src/c -I…/opende/include -O2 -fno-strict-aliasing -fomit-frame-pointer -ffast-math -Iinclude -IGIMPACT -IGIMPACT/include -I$JAVA_INCLUDE/usr/lib/jvm/java-6-sun/include/linux -I$JAVA_INCLUDE/usr/lib/jvm/java-6-sun/include -DdTRIMESH_ENABLED -c -o …/bin/odejava_wrap.o …/generated/c++/odejava.cxx
it failed with error:
…/generated/c++/odejava.cxx: In function
Times like these that I love being a Java developer.
mud2005 said:
it failed with error:
../generated/c++/odejava.cxx: In function
it most probably won't need the last transformation - so you can simply comment out the method body of that method
thanks irrisor, your suggestion worked and I got it to compile but now Im getting error:
java: /home/mud2005/odejava/odejava-jni/opende/GIMPACT/src/gim_trimesh.cpp:183: void gim_trimesh_locks_work_data(GIM_TRIMESH*): Assertion `res==0' failed.
TestDomino works so I know it was built properly but the gimpact portion of it seems to be causing error with trimesh. :?
no idea what that could mean, sorry (never used gimpact) - ask the gimpact people?
Gimpact seems to have some pretty interesting possibilities…this might be a good idea to explore implementing it as a standard in the ODE implementation of jME-Physics2…granted someone can get it to work.
Gimpact seems to have some pretty interesting possibilities...this might be a good idea to explore implementing it as a standard in the ODE implementation of jME-Physics2...granted someone can get it to work
yeah I agree, I was able to compile ode w/ gimpact in linux
./configure --with-trimesh=gimpact