So the case is this:
For some reason, adding a Waypoint sometimes leads to this exception complaining about a corrupted key.

java.lang.IllegalStateException: Error in org.openide.nodes.EntrySupportDefault with entry Children.Keys.KE[(-3.2392411, 0.33327007, -0.18502045),0] from among entries:
  Children.Keys.KE[(-3.2392411, 0.33327007, -0.18502045),0] contained: false
  Children.Keys.KE[(-0.95363027, 1.35918, -1.4305115E-6),0] contained: false
  Children.Keys.KE[(1.5856057, 1.3173374, -2.4937344),0] contained: false
  Children.Array.AE[] contained: true
probably caused by faulty key implementation. The key hashCode() and equals() methods must behave as for an IMMUTABLE object and the hashCode() must return the same value for equals() keys.
mapping:
  Children.Array.AE[] => Children.Info[Children.Array.AE[],length=0]
  Children.Keys.KE[(-3.2392411, 0.33327007, -0.18502045),0] => Children.Info[Children.Keys.KE[(-3.2392411, 0.33327007, -0.18502045),0],length=1]
  Children.Keys.KE[(-0.95363027, 1.35918, -1.4305115E-6),0] => Children.Info[Children.Keys.KE[(-0.95363027, 1.35918, -1.4305115E-6),0],length=1]
  Children.Keys.KE[(1.5856057, 1.3173374, -2.4937344),0] => Children.Info[Children.Keys.KE[(1.5856057, 1.3173374, -2.4937344),0],length=1]
    at org.openide.nodes.EntrySupportDefault.checkInfo(EntrySupportDefault.java:312)
    at org.openide.nodes.EntrySupportDefault.updateOrder(EntrySupportDefault.java:357)
    at org.openide.nodes.EntrySupportDefault.setEntries(EntrySupportDefault.java:292)
    at org.openide.nodes.EntrySupport.setEntries(EntrySupport.java:83)
    at org.openide.nodes.Children$Keys$2.run(Children.java:1573)
    at org.netbeans.modules.openide.util.DefaultMutexImplementation$1Exec.run(DefaultMutexImplementation.java:1016)
    at org.openide.nodes.Children$ProjectManagerDeadlockDetector.execute(Children.java:1938)
    at org.netbeans.modules.openide.util.DefaultMutexImplementation.postRequest(DefaultMutexImplementation.java:1022)
    at org.netbeans.modules.openide.util.DefaultMutexImplementation.postRequest(DefaultMutexImplementation.java:985)
    at org.netbeans.modules.openide.util.DefaultMutexImplementation.postWriteRequest(DefaultMutexImplementation.java:356)
    at org.openide.util.Mutex.postWriteRequest(Mutex.java:388)
    at org.openide.nodes.Children$Keys.applyKeys(Children.java:1582)
    at org.openide.nodes.Children$Keys.setKeys(Children.java:1526)
    at com.jme3.gde.core.sceneexplorer.nodes.JmeVector3fChildren.refreshChildren(JmeVector3fChildren.java:79)
    at com.jme3.gde.core.sceneexplorer.nodes.JmeMotionPath.refreshChildren(JmeMotionPath.java:231)
    at com.jme3.gde.core.sceneexplorer.nodes.actions.MotionPathPopup$3.actionPerformed(MotionPathPopup.java:121)
    at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
    at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2346)
    at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
    at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
    at javax.swing.AbstractButton.doClick(AbstractButton.java:376)
    at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:833)
    at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:877)
    at java.awt.Component.processMouseEvent(Component.java:6525)
    at javax.swing.JComponent.processMouseEvent(JComponent.java:3324)
    at java.awt.Component.processEvent(Component.java:6290)
    at java.awt.Container.processEvent(Container.java:2234)
    at java.awt.Component.dispatchEventImpl(Component.java:4881)
    at java.awt.Container.dispatchEventImpl(Container.java:2292)
    at java.awt.Component.dispatchEvent(Component.java:4703)
    at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4898)
    at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4533)
    at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4462)
    at java.awt.Container.dispatchEventImpl(Container.java:2278)
    at java.awt.Window.dispatchEventImpl(Window.java:2750)
    at java.awt.Component.dispatchEvent(Component.java:4703)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:751)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:702)
    at java.awt.EventQueue$3.run(EventQueue.java:696)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
    at java.awt.EventQueue$4.run(EventQueue.java:724)
    at java.awt.EventQueue$4.run(EventQueue.java:722)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:721)
    at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I currently have no clue and our keys aren't that easy (we currently use the vectors as keys instead of dataObjects. Maybe use Arrays instead of Keys?)

I'll look into it when I got some distance from that all ^^

Edit: see this happens when the hashCode of a key changes (see: https://huionn.wordpress.com/2012/08/20/api-design-defensive-and-explanatory-error-message/)

As for that we will either use an overload of Vector3f (which saves the hashCode on constructor) or (which is better because we could experience duplicate keys without that) using Index.ArrayChildren

This Issue is quite simple but since I'm not under Windows right now, I'll open this Issue for anyone to fix/as a reminder for me:
https://forums.netbeans.org/topic48135.html

In short: Use ResHack to change the Icon of netbeans/harness/launchers/app.exe
Note: That app is downloaded automatically so we need some "override" and thus manually update the icon each new netbeans version (shouldn't be a problem, though it leads to bad errors when not done).

Maybe using https://github.com/erocarrera/pefile for editing? However I feel bad in adding python as a dependency just for that. Maybe there's a nice java solution?

https://github.com/mirror/launch4j/blob/master/src/net/sf/launch4j/RcBuilder.java This is launch4j's RCBuilder however those .rc's have to be compiled (e.g. by wrc).

From @ghost on March 24, 2014 19:35

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=582

I have noticed the SDK crashes when returning from sleep mode. I believe this to be related to the openGL preview window that is available in the SDK.

Crash 1: returning from sleep mode, openGL preview is up already displaying a model. crash throws many blank error boxes, must force quit application.

Crash 2: returning from sleep mode, openGL preview is not up. I added a model via import, when I went to go preview it in the SDK then crashed the same as before. Major note: SDK then went on to delete the original model file from my disk; luckily the model was still open in Blender, so I simply resaved the file and re-wrote it to disk.

Windows 8, 64bit

Copied from original issue: jMonkeyEngine/jmonkeyengine#93

From @Ali-RS on March 2, 2016 19:0

Rotating a model in scene composer is not done correctly and Parent node box not rotating along with mesh box and cause problem in transforming model in scene.
see detailed description here :
http://hub.jmonkeyengine.org/t/bug-report-problem-with-rotating-models-in-scenecomposer-in-sdk/35224

Copied from original issue: jMonkeyEngine/jmonkeyengine#437

When you try to debug something which calls core code you only see the jvm assembly.
I think we already download the source packages, we only need to link them into the netbeans project to be found by it.

When building SDK it downloads Blender 2.76 which is assigned in
nbi/stub/ext/infra/build/products/blender-windows-x64/build.properties also for Mac and Linux
but blender 2.75 being located in sdk/jme3-blender/src/com/jme3/gde/blender/BlenderTool.java

File blender = InstalledFileLocator.getDefault().locate(getBlenderOsSettingsPath() + "/2.75", null, false);
So when i double click on a .blend file in sdk i get this error "Error finding blender settings".

The situation is simple:
You run an "old" Java Version (like my OS X ships with 1.8.0_40-b27) and the SDK tries to download exactly your java.runtime.version as JRE (assuming that this is a way to have an relatively up to date version number).

Now the problem is that attempting to download the JREs leads to 404's for all JREs except from the mac osx version. (This could be due to the fact that this special build was mac only or it's just as it is).

Regardless of that a Java 7 user shouldn't ship his game with Java 7 anymore.
The Workarounds currently is downloading the files manually to BasicGame/resources/desktop-deployment/jre-windows-x64.tar.gz

Do you have a better idea? RegExping the Oracle Page or relying on some different page feels like provoking further issues.

I have created plain new jmonkey project from the wizard, enable android android deployment, installed Android SDK Manager set configuration on Android Device and yet the default emulator is executed. ( I m pretty sure that I set my device because on jmonkey 3.0 I`ve managed to deploy it on device)

From @ghost on March 24, 2014 19:34

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=411

Copied from original issue: jMonkeyEngine/jmonkeyengine#45

If you try to find any jme-plugin under 3.1 (e.g. jme3-ai) those packages don't appear in the dialog.
The reason is that they are under 3.0 in http://updates.jmonkeyengine.org and have to be copied and maybe modified for the new version.

When I'm using scene composer I often find it annoying that I have to right click the scene j3o file instead of the actual terrain node.
I think that it would be way more logical to have the button available in the terrain node right click menu.

The Code Checks Module is relying on a deprecated Netbeans API:

jme3-code-check/src/com/jme3/gde/codecheck/hints/TempVarsHint.java:20: warning: [deprecation] AbstractHint in org.netbeans.modules.java.hints.spi has been deprecated
[ant:nb-javac] import org.netbeans.modules.java.hints.spi.AbstractHint;

The thing is, we have to upgrade from extends AbstractHint to implements Hint
See here

Actually we don't have to Implement the Hint but rather uses it's Annotations.
This unfortunately is more than a small refactoring. See here

It seems to be Deprecated in 8.0 so it's really low priority, but when you want to learn a bit about Netbeans API and do some chilled refactoring, this one is for you :)

From @Nehon on February 21, 2015 19:50

Sometime, I have this exception in the SDK
java.lang.AssertionError
at com.jme3.util.NativeObjectManager.deleteNativeObject(NativeObjectManager.java:140)
at com.jme3.util.NativeObjectManager.deleteUnused(NativeObjectManager.java:188)
at com.jme3.renderer.opengl.GLRenderer.postFrame(GLRenderer.java:853)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuffer.java:128)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.java:156)
[catch] at java.lang.Thread.run(Thread.java:745)

Can't reproduce it systematically though

Copied from original issue: jMonkeyEngine/jmonkeyengine#214

See jMonkeyEngine/jmonkeyengine#330, since the core is basically decoupled from Nifty it's our responsibility to use the more recent version and also upgrade the templates or whatever is needed.

So, #31 (or rather 970463a) introduced some changes:

• We use JBullet instead of Bullet-Native
• We've removed Support for Runtime Loading of .blend files.
• We've removed NiftyGUI

So the first one won't be noticed and the second one might detect bad behavior (because a typical game won't need .blend loading and even for addons/mods you should prefer .j3o as there might be some necessary changes or the import fails).

The third one has to be changed in Hello_GUI or whatever we have.
There already is a Wiki-Page about Libraries, however it states on how to split the 3.0 "jme-libraries" into more fine-grained control.
Link that Page in the Hello_* Tutorials and deprecate that 3.0 stuff, but include how to add libraries (Nifty GUI) to your project.

I'll do it once the wiki is up again.

From @ghost on March 24, 2014 19:34

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=146

Copied from original issue: jMonkeyEngine/jmonkeyengine#8

After making changes to a new scene, it can't be saved. If closing and click yes in the confirmation popup, the scene can't be opened anymore.S.D.K problem with the latest alpha version.

From @MeFisto94 on February 27, 2016 23:44

Opening the Lighting.j3md in ShaderNodes leads to a NullPointerException.
The Exception itself isn't interesting, but we should find out what goes wrong so that the ShaderGenerationInfo == null

See MeFisto94/jmonkeyengine@4b177ca for where the NPE happens.

Copied from original issue: jMonkeyEngine/jmonkeyengine#429

Simple Issue:
We have that great .fbx->.j3o or .fbx -> .blend functionality nobody knows off because it's not exposed enough.

That and we need a double click action aswell.

From @ghost on Mar 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=575

Copied from original issue: jMonkeyEngine/jmonkeyengine#88

From @Triangle345 on February 12, 2016 2:24

After changing mesh names in blender on an already converted blend file (j3o), jmonkey asks whether or not to apply the blend changes. After clicking yes, inspection of the j3o scene shows that the old mesh names remain in the scene graph along with the new ones. It seems that these old names should be removed. A current work around is to simply reconvert the blend file and create a new j3o in which case the old names are completely gone from from this newly created j3o.

Copied from original issue: jMonkeyEngine/jmonkeyengine#410

I was working on #37 when I figured out that ReadOnlyPrimitivesHint does not work.
As far as I understand it it's purpose is to prevent people from using stuff like
node.getLocalTranslation.set(/*Whatever*/);
I tried it on my fork. Didn't work. Tried it on this repo. Didn't work.
Now I could go fix it myself, but ATM I'm still moving strings to bundles.

Here is the error description taken from the SDK.

Errors occured during face triangulation: Unable to find two closest vertices while triangulating face in mesh: TemporalMesh [name=Default, vertices.size()=201]Please apply triangulation modifier in blender as a workaround and load again!. The face will be triangulated with the most direct algorithm, but the results might not be identical to blender.
The texture Kd has linear color space, but the material parameter DiffuseMap specifies no color space requirement, this may lead to unexpected behavior.
Check if the image was not set to another material parameter with a linear color space, or that you did not set the ColorSpace to Linear using texture.getImage.setColorSpace().

I used the same models in JME 3.0 with no problems. When I try to load them into 3.1 they come out a bloody mess flipped faces and polygons all over the place. I even loaded them into blender 2.76 then tried importing with the same result.

jMonkeyEngine/jmonkeyengine#270
I didn't check if it's reproducable yet, but it slipped through the move so I'll post it here.

The following is quoted :)

NOTE:
Hello JME3! I wasn't really sure what project to place this in since there is no project for the IDE/SDK, but I think this project best fits. Please feel free to let me know where it should go if not here and I can repost it.

What did you intend to do, what was the expected outcome?
I intended to import a heightmap (the one attached) into JME3. I expected it to work.

What outcome do you experience instead?
It failed for an unknown reason. However, it does appear to work in other projects in the SDK.

What steps will reproduce the problem?
I imported the attached heightmap into JME3 via the Image Terrain option in the Scene Design view. Once I had entered all of the values into the wizard and told it to begin the process, it appears to begin but then the SDK suddenly closes with the error at the end of this issue post.

Software Configuration:
Product Version: jMonkeyEngine SDK 3.0
Updates: Updates available
Java: 1.7.0_51; Java HotSpot(TM) 64-Bit Server VM 24.51-b03
Runtime: Java(TM) SE Runtime Environment 1.7.0_51-b13
System: Linux version 3.19.5-200.fc21.x86_64 running on amd64; UTF-8; en_US (jmonkeyplatform)
User directory: /home//.jmonkeyplatform/3.0
Cache directory: /home//.jmonkeyplatform/3.0/var/cache

Hardware Configuration:
CPU: Amd FX-8350, default clock speed (4GHZ)
GPU: Nvidia MSI GTX 770
Motherboard: Gigabyte 990FXA-UD3
Ram: 8GB (total, not allocated, I don't know how much JME3 has)

Console Output:

OGL: Throttling update loop.
EDT: addNotify
OGL: Enter showing state.
OGL: Visible. Create strategy.
OGL: Ceased throttling update loop.
EDT: componentResized 926, 612
############ Wizard panel listener added: org.openide.util.WeakListenerImpl$Change[org.openide.WizardDescriptor$Listener]

(java:12924): Gdk-ERROR **: The program 'java' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 34340 error_code 3 request_code 20 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Heightmap:

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=481

Copied from original issue: jMonkeyEngine/jmonkeyengine#63

From @ghost on March 24, 2014 19:34

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=136

Copied from original issue: jMonkeyEngine/jmonkeyengine#7

Sometimes, even the best websites aren't available, like for example updates.jmonkeyengine.org.

Then gradle build does this:

FAILURE: Build failed with an exception.

* Where:

Build file 'C:\Temp\jme\test\sdk\build.gradle' line: 129

* What went wrong:

A problem occurred evaluating root project 'sdk'.

> Could not resolve all dependencies for configuration ':corelibs'.

   > Could not resolve org.jmonkeyengine:jme3-jbullet:3.1.0-alpha3.

     Required by:

         :sdk:unspecified

      > Could not resolve org.jmonkeyengine:jme3-jbullet:3.1.0-alpha3.

         > Could not get resource 'http://updates.jmonkeyengine.org/maven/org/jm

onkeyengine/jme3-jbullet/3.1.0-alpha3/jme3-jbullet-3.1.0-alpha3.pom'.

            > Could not GET 'http://updates.jmonkeyengine.org/maven/org/jmonkeye

ngine/jme3-jbullet/3.1.0-alpha3/jme3-jbullet-3.1.0-alpha3.pom'.

               > updates.jmonkeyengine.org:80 failed to respond

But wait, jcenter has it covered!

https://bintray.com/jmonkeyengine/org.jmonkeyengine/jme3-jbullet/view

So is probably better to link there for the dependency.

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=596

Copied from original issue: jMonkeyEngine/jmonkeyengine#95

From @shadowislord on September 4, 2015 18:45

(Note: consider splitting these into separate issues)

• The bundled Blender 2.75a is not supported - exported models crash the SDK. One option is to simply update to an older Blender version such as 2.74.
• Projects from 3.0 SDK are not compatible with 3.1 SDK. For example, native deployment and names of the libraries have changed - hence recreating the project is required.
• The built-in documentation which is generated from the wiki has broken links - the generator has not been adjusted to the new wiki structure yet. As a result, the welcome page still says "You're using the latest version of jMonkeyEngine SDK (3.0)"
• The terrain editor no longer works correctly - erasing a texture does not work. Also the paint brush seems to be offset a bit from where the mouse is. Fixed in edd183a2be86af90f5bea680fc2b953d8bf0177f
• In the "Projects" tab, importing a new asset causes it to be selected under "Dependencies" instead of under "Assets".
• The editor is based on NetBeans 8.0, but NetBeans 8.1 has already been released. (Fixed in 03998b0 )

Copied from original issue: jMonkeyEngine/jmonkeyengine#329

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=401

Copied from original issue: jMonkeyEngine/jmonkeyengine#43

From @Shadow1Raven on December 3, 2015 18:56

Hello,

I've been experiencing several problems with the editor(s) of the jME SDK version 3.0. This includes, that I can't navigate using the arrow keys or insert a new line using enter. Thus, marking text using the keyboard is not possible. Marking text using the mouse also doesn't show any signs of markered text (e.g. a blue background and white foreground). Assuming the XML editor is different from the java editor, I must admit to experience these bugs in every editor window.
I am running the JME SDK (64-bit) on Windows 7. The SDK runs in Java 1.7.0_51, 64 bit.

Copied from original issue: jMonkeyEngine/jmonkeyengine#387

From @ghost on March 24, 2014 19:34

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=198

The installer of jMonkeyEngine SDK Alpha-2 fails to run on MacOSX 10.5 because it falsely tries to use Java 1.5 to start the installed.

Workaround:
If you have Java 1.6 installed on your computer you can temporarily rename the Java 1.5 folder in /System/Library/Frameworks/JavaVM.framework/Versions/ to some other name like "1.5backup" and run the installer. After installing the folder can be renamed back to "1.5".

Copied from original issue: jMonkeyEngine/jmonkeyengine#10

So the SDK makes heavy use of the assetManager field where it could use Application.getAssetManager().

It might also extend Application instead of SimpleApplication (now LegacyApplication).
The question is if we should implement Application or extend LegacyApplication? I'd say we can go for the latter and worry about those things later.

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=398

Copied from original issue: jMonkeyEngine/jmonkeyengine#42

Add a button to scene editor that pauses/resumes all controls in the scene so that moving spatials don't run away.
See:
http://hub.jmonkeyengine.org/t/sdk-maintenance-plan/35259/30

So this is the Issue:
When you run the SDK, we usually ask for your Project Directory.
Since 8.1, Netbeans decided to make their Splash Screen pretty aggressive.
It's on top of File Explorers and doesn't disappear when you try to stop the SDK in Netbeans.
You have to kill the java process. Also see https://netbeans.org/bugzilla/show_bug.cgi?id=258236

As a Quick & Dirty workaround (since grabbing the window is unacceptable and simply pressing Enter/Escape sucks), I'll hide the splash until the path has been loaded and reopen the splash again.

However! I will keep this Issue open so we can remove the Workaround with 8.2 again.
The workaround introduces a "fatal warning", this is due to the fact that I didn't specify any special version of the core and as such, netbeans considers this a risk since the internal api might change any time. See here: http://wiki.netbeans.org/DevFaqImplementationDependency

This infact is no problem because the next breaking change hopefully fixes the Splash and if not, it's very unlikely that "getComponent" or "setRunning" will be removed at all..

For some reason, jMonkeyEngine SDK (alpha 3) locks up when scrolling through some of my shader files in the "Projects" window. I think it is getting hung up on determining which icon to display for them. Most shader files seem to display fine, with a green gear & blue palette(?) icon (or just a blank page). However, when I try to scroll really fast to files that seem to lock things up, they have a small white page with a red ? on it. The whole SDK locks up & becomes unresponsive. I need to force close the application. It always locks up on some specific files...

Can you check for a possible lockup situation when determining shader file icons...? Any other possible explanation?

Example SimpleLight.frag file that appears to start the lockup process in my project:

#define FRAGMENT_SHADER
#import "Common/ShaderLib/GLSLCompat.glsllib"

uniform sampler2D m_Texture;
uniform sampler2D m_NoiseTexture;

#ifdef HAS_COLOR
    uniform vec4 m_Color;
#endif

uniform vec2 m_Alpha;

varying float zdist;
varying vec3 vNormal;
varying vec2 texCoord1;

void main(){

    #ifdef HAS_TEXTURE
        vec4 texcolor = texture2D(m_Texture, texCoord1);
        #ifdef HAS_COLOR
            texcolor *= m_Color;
        #endif
        #ifdef HAS_NOISETEXTURE
            texcolor.rgb *= texture2D(m_NoiseTexture, texCoord1).rgb;
        #endif
    #else
        vec4 texcolor = m_Color;
    #endif

    // basic light direction
    gl_FragColor.rgb = texcolor.rgb * (vNormal.y * 0.5 + vNormal.x * 0.2 + 0.6);

    #ifdef HAS_ALPHA
        gl_FragColor.a = texcolor.a * m_Alpha.x;
    #else
        gl_FragColor.a = texcolor.a;
    #endif
}

Class : src\jme3test\bullet\PhysicsHoverControl.java:175
error: cannot access MotionState
getMotionState().applyTransform(spatial);
class file for com.bulletphysics.linearmath.MotionState not found

From @FrozenShade666 on November 23, 2015 7:29

Having braces in next line in j3md file results in empty parameters list while creating/editing j3m file in SDK 3.0. I don't know if the problem exists in 3.1.
The engine itself can handle such syntax and all materials are processed correctly.

Copied from original issue: jMonkeyEngine/jmonkeyengine#386

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=493

Copied from original issue: jMonkeyEngine/jmonkeyengine#65

From @tonihele on September 28, 2015 19:52

Font creator doesn't create more than 256 characters. The Font Creator lets the user select the char range and even shows them on the preview, but the end result contains just one page with 256 characters max.

Easy fix would be just to produce one page with the given character range (max displayable char...). If I understood correctly, JME does read these, no matter what the max range is. Also the preview image could be inside a scrollable container. As it tends to eat up and hide all the controls when it is big enough.

Here some discussion from the forums (also pin pointed some of the code points which might be related):
http://hub.jmonkeyengine.org/t/font-creator-for-jmp/16273/30

Copied from original issue: jMonkeyEngine/jmonkeyengine#356

From @ghost on March 24, 2014 19:35

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=629

Copied from original issue: jMonkeyEngine/jmonkeyengine#109

See http://hub.jmonkeyengine.org/t/jmonkeyengine-3-1-alpha-3-released/35328/9
Either it's because we are writing an incomplete file or because the BinaryInputCapsule just can't handle empty files.

I`ve recently install 3.1-alpha4-SNAPSHOT ide and upgraded my old project to use new sdk jmonkey. When i attach my TouchListener which extends BaseAppState the console is getting spammed with this message W/hwcomposer( 181): [WKR] Timed out waiting for UIComposeThread_0... and the movement of spatial gets laggy. Can you give me some general implications what might cause this problem or what does it mean.

THIS happens when I run the project on physical android device.

Hi guys,

I was gonna try to just give Normen the heads up on this on a pm over at the forums, but er... that's out, at the moment, I don't know his email, and it's not really big enough to start a topic over.

I think that by adding the good ol' <attr name="position" intvalue="9001" /> tag into the various spots in the layer.xml files should get rid of these two warnings while building modules for the netbeans/jme3 sdk. The intvalue might affect ordering.

It's just something that I noticed and now have enough knowledge to offer a fix.

And the minor warnings are:
WARNING [org.openide.filesystems.Ordering]: Not all children in Menu/Tools/ marked with the position attribute: [NiftyGUI, OgreXML, Textures], but some are: [org-openide-actions-ToolsAction.shadow, I18N, Separator1.instance, JavaPlatformsCustomizerAction.shadow, VariablesCustomizerAction.shadow, LibrariesCustomizerAction.shadow, org-netbeans-modules-favorites-templates-TemplatesAction.shadow, org-netbeans-modules-xml-catalog-CatalogAction.shadow, PaletteManager, Separator2.instance, org-netbeans-modules-autoupdate-ui-actions-PluginManagerAction.shadow, org-netbeans-modules-options-OptionsWindowAction-separatorBefore.instance, org-netbeans-modules-options-OptionsWindowAction.shadow]
WARNING [org.openide.filesystems.Ordering]: Not all children in Menu/Window/ marked with the position attribute: [AssetPackBrowserAction.shadow, MaterialEditorAction.shadow, SceneExplorerAction.shadow, SceneViewerAction.shadow, com-jme3-gde-core-appstates-AppStateExplorerTopComponent.shadow, com-jme3-gde-core-filters-FilterExplorerTopComponent.shadow, com-jme3-gde-welcome-WelcomeScreenTopComponent.shadow], but some are: [org-netbeans-modules-project-ui-logical-tab-action.shadow, org-netbeans-modules-project-ui-physical-tab-action.shadow, org-netbeans-modules-favorites-View.shadow, org-netbeans-core-ide-ServicesTabAction.shadow, org-netbeans-modules-tasklist-ui-TaskListAction.shadow, ShowPaletteAction.shadow, org-netbeans-core-windows-actions-GlobalPropertiesAction.shadow, Output, Navigator, Debug, Versioning, Other, Web, SwitchToRecentDocumentAction.shadow, ProgressListAction.shadow, Separator3.instance, ConfigureWindow, org-netbeans-core-windows-actions-ResetWindowsAction.shadow, Separator4.instance, CloseWindowAction.shadow, CloseAllDocumentsAction.shadow, CloseAllButThisAction.shadow, DocumentsAction.shadow]

From @ghost on March 24, 2014 19:35

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=623

Copied from original issue: jMonkeyEngine/jmonkeyengine#105

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=375

this exception happened to me recently with SDK Netbeans 8.1
Using netbeans editor auto code complete with "Ctrl" + "Space" .
Example : spatial.setLocalTranslation(0, 0, 0);

java.lang.NullPointerException
    at java.lang.String.contentEquals(String.java:1066)
    at org.netbeans.modules.java.source.save.Reformatter$Pretty.blankLines(Reformatter.java:3532)
    at org.netbeans.modules.java.source.save.Reformatter$Pretty.newline(Reformatter.java:3280)
    at org.netbeans.modules.java.source.save.Reformatter$Pretty.visitBlock(Reformatter.java:1556)
    at org.netbeans.modules.java.source.save.Reformatter$Pretty.visitBlock(Reformatter.java:406)
    at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:924)
    at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:50)
    at org.netbeans.modules.java.source.save.Reformatter$Pretty.reformat(Reformatter.java:523)
    at org.netbeans.modules.java.source.save.Reformatter.reformatImpl(Reformatter.java:239)
    at org.netbeans.modules.java.source.save.Reformatter.reformat(Reformatter.java:109)
    at org.netbeans.modules.editor.indent.TaskHandler$MimeItem.runTask(TaskHandler.java:557)
    at org.netbeans.modules.editor.indent.TaskHandler.runTasks(TaskHandler.java:316)
    at org.netbeans.modules.editor.indent.IndentImpl.reformat(IndentImpl.java:365)
    at org.netbeans.modules.editor.indent.api.Reformat.reformat(Reformat.java:154)
    at org.netbeans.lib.editor.codetemplates.CodeTemplateInsertHandler.run(CodeTemplateInsertHandler.java:371)
    at org.netbeans.editor.GuardedDocument.runAtomicAsUser(GuardedDocument.java:356)
    at org.netbeans.lib.editor.codetemplates.CodeTemplateInsertHandler.insertTemplate(CodeTemplateInsertHandler.java:284)
    at org.netbeans.lib.editor.codetemplates.CodeTemplateInsertHandler.processTemplate(CodeTemplateInsertHandler.java:252)
    at org.netbeans.lib.editor.codetemplates.CodeTemplateManagerOperation.insert(CodeTemplateManagerOperation.java:298)
    at org.netbeans.lib.editor.codetemplates.api.CodeTemplate.insert(CodeTemplate.java:107)
    at org.netbeans.modules.editor.java.JavaCompletionItem.process(JavaCompletionItem.java:580)
    at org.netbeans.modules.editor.java.JavaCompletionItem.defaultAction(JavaCompletionItem.java:300)
    at org.netbeans.modules.editor.completion.CompletionImpl.dispatchKeyEvent(CompletionImpl.java:676)
    at org.netbeans.modules.editor.completion.CompletionImpl.keyPressed(CompletionImpl.java:404)
    at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:250)
    at java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:249)
    at java.awt.Component.processKeyEvent(Component.java:6493)
    at javax.swing.JComponent.processKeyEvent(JComponent.java:2832)
    at java.awt.Component.processEvent(Component.java:6312)
    at java.awt.Container.processEvent(Container.java:2236)
    at java.awt.Component.dispatchEventImpl(Component.java:4891)
    at java.awt.Container.dispatchEventImpl(Container.java:2294)
    at java.awt.Component.dispatchEvent(Component.java:4713)
    at java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
    at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:806)
    at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1074)
    at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:945)
    at java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:771)
    at java.awt.Component.dispatchEventImpl(Component.java:4762)
    at java.awt.Container.dispatchEventImpl(Container.java:2294)
    at java.awt.Window.dispatchEventImpl(Window.java:2750)
    at java.awt.Component.dispatchEvent(Component.java:4713)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
    at java.awt.EventQueue$4.run(EventQueue.java:731)
    at java.awt.EventQueue$4.run(EventQueue.java:729)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
    at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

It was fixed in build 201603150001 (it is nightly) : https://netbeans.org/bugzilla/show_bug.cgi?id=257245

I found this zip :
http://bits.netbeans.org/dev/nightly/2016-03-25_00-01-48/zip/
Is it possible to change current SDK netbeans build in gradle.properties:
netbeansUrl = http://download.netbeans.org/netbeans/8.1/final/zip/netbeans-8.1-201510222201-javase.zip

to this :
http://bits.netbeans.org/dev/nightly/2016-03-25_00-01-48/zip/netbeans-trunk-nightly-201603250001-javase.zip

From @ghost on March 24, 2014

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=388

Copied from original issue: jMonkeyEngine/jmonkeyengine#40

From @slawekmikula on May 11, 2014

Template BasicGame when creating with current HEAD SDK require older libraries: jme3 and jme3-libraries. Due to fact, that jme3 is split to many partial libraries it has to be updated to core library jme3-core and provide in simple readme in BasicGame method to add more specific libraries.

Copied from original issue: jMonkeyEngine/jmonkeyengine#136