Hey guys,
I just updated to the latest JME today to fix an emitter bug. However, I now get the following exception when trying to load:
“C:/Projects/SuperCoolAwesomeness/CoolStuff/assets/compass.png” doesn’t match “C:/Projects/SuperCoolAwesomeness/CoolStuff/…/CoolStuff/assets/compass.png”
Although as strings it’s true they don’t match, when fed to the OS they lead to the same file.
When I register the locator, the path I give contains “…” I need this because of installation directory stuff
Is there a suggested solution? Is this a bug or a feature for general OS’s? I’m using Win7
This was added recently because we are trying to make sure that asset paths work the same in all environments and it takes a lot of code to validate relative asset paths. Maybe for FileLocator this check is going too far… but I don’t use FileLocator so I’m not familiar with it.
Can you explain more about why you need the “…”? I don’t really understand that part.
i had the same problem, the 2 filenames are different !!! Look closely they have different case.
hElLO != HeLlo
Can you explain more about why you need the “..”? I don’t really understand that part.
Unfortunately, I don't have control over how the installation of the application I'm working on works. So the directories where the assets are contained may be placed anywhere.
I am only given the names of the files I need to load (in this case "compass.png"), and the path to where those files are located. The paths are relative paths from the current running directory. So maybe something like /../../../../assets/
In my code, I register the location as something like this:
[java]assetManager.registerLocator(RELATIVE_ASSETS_PATH, FileLocator.class.getName());[/java]
hElLO != HeLlo
That's true, but in this case the file names are the same
For the time being I took out the check in the FileLocator
Yeah, FileLocator probably needs some tweaking… it actually knows real paths and can therefore do a better check, I guess.
From what I learned is, the system is not that friendly to file resources. Had the same findings as you have. The asset system is programmed against classpath entries, no system independant file pathe entries or file path/name parsing. In the end I ended u in writing a Fullquallified Path locator, which is also not that briliant, because in some cases the root and filename parsing break up. (for example the file loads but you wil get Geometry meshes with names of the full quallified path 
).
The problem with the registration is (especially for converter apps) you are not able to unregister.
Having several assets with the same name will leave you with the first one (registered) to server the AssetInfo.
Windows filenames will be a pain in the a…
it doesnt work because propably you have wrong slash !!! You must use “/” as a slash - file seperator.
No, it doesn’t work because the file handling code was recently modified to do extra checks and it now fails to consider foo/Bar.png and foo/…/foo/Bar.png to be the same file. But it used to.
Omg, I hope the AssetKeys at least also don’t report them anymore too then… I know I often got names like these from the objects themselves (e.g. j3m creation).
normen said:
Omg, I hope the AssetKeys at least also don't report them anymore too then.. I know I often got names like these from the objects themselves (e.g. j3m creation).
You mean names with relative paths?
Yes, the ogre importer (i think) creates texture names with /…/ in them, I saw this when I added the “create j3m” feature to jMP (or was it when using the OgreImporter for WorldForge?).
Actually, since we check against a fully resolved path this may be easier to fix than I thought. I have to do some doodling to see.
I think the best way to resolve the issue is to get a canonical path before passing it to the AssetManager. This includes the OgreXML importer