File locator error

I try to load a simple image file. But unfortunately the FileLocator throws an exception.

I run this piece of code:


assetManager.registerLoader(AWTLoader.class, “jpg”);

assetManager.registerLocator(".", FileLocator.class);

Texture t = assetManager.loadTexture(“11.jpg”);


and this is the exception I get:

com.jme3.asset.AssetNotFoundException: Asset name doesn’t match requirements.

“/home/marcin/workspace/jMonkeyEngine3/11.jpg” doesn’t match “/home/marcin/workspace/jMonkeyEngine3/./11.jpg”

at com.jme3.asset.plugins.FileLocator.locate(

at com.jme3.asset.ImplHandler.tryLocate(

at com.jme3.asset.DesktopAssetManager.loadAsset(

at com.jme3.asset.DesktopAssetManager.loadTexture(

at com.jme3.asset.DesktopAssetManager.loadTexture(

at com.jme3.asset.DesktopAssetManager.loadTexture(

at com.jme3.scene.plugins.blender.textures.TextureHelper$Game.getTexture(

at com.jme3.scene.plugins.blender.textures.TextureHelper$Game.simpleInitApp(


at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(



Obviously the paths:




point exactly to the same file. The problem is that the FileLocator compares the strings of these paths and they do not match.

This happens on Ubuntu 11.04.

As I remember I didn’t have such problems when using windows.

If will happen on all platforms if you use relative paths in the register call. It’s something that needs to be fixed in the asset manager.

In the mean time, you can try changing:

assetManager.registerLocator(".", FileLocator.class);


assetManager.registerLocator( new File(".").getCanonicalPath(), FileLocator.class);

yeha, I changed it the way Pspeed says and I can confirm it works that way.

@momoko_fan just checked in a fix that should alleviate this particular issue:

It allows any relative path to be used as the file locator root.

So the worldforge asset pack is still broken now, right? And some of peoples j3o’s or data as well because the /./ paths are not generated anymore? I was specifically asking to make the fix so that it reduces these paths… -.-

There’s not much we can do. Those asset paths are already in the j3o files. The only thing I can suggest is that you fix it manually, by e.g. exporting to XML, changing the paths, and then export back to J3O.

As for WorldForge, that can be fixed by regenerating the pack.

Oh man, all this for a silly case check…

One of the asset name requirements is that relative paths aren’t allowed. This isn’t just about case sensitivity

But why can’t we use relative paths???

If the file of the asset is already found and we know it is a file, why does it need the absolute path??

Anyway you give the file itself to the AssetInfoFile. You can get the absolute from it if you really wan it.

Momoko_Fan said:
One of the asset name requirements is that relative paths aren't allowed. This isn't just about case sensitivity

You can just reduce it when its passed, the name you get then will be fine. This is mostly what the user enters, not some specific name thats known, especially in the case of the FileLocator.

The issue with reducing it when its passed is because then you have multiple ways to identify the same file. The asset manager cannot distinguish between A/B.png vs, A/C/…/B.png which will cause the same file to be loaded twice.

Yes I got that part, but when you reduce the name just after it has been passed then they are both the same…

A/C/…/B.png → A/B.png == A/B.png

When who reduces the name?

The issue is loadAsset( “A/C/…/B.png” ) right?

The AssetKey constructor. Its more like A/./B.png thats the problem as the FileLocator would produce these before so they are in j3o’s and world forge asset pack etc.

Ok, I added a method that reduces the relative elements in the AssetKey constructor as according to @Momoko_Fan they are not allowed anyway :stuck_out_tongue:

This fixes the old j3o files, WorldForge models and avoids that any relative paths are ever used as the asset name (e.g. from user input).

But I thought old j3o files loaded the AssetKey directly though BinaryImporter and Savables?

The same method is also used to check when the key is deserialized, it does nothing if theres no relative elements.