Move to absolute locators

I just commited a big change to SVN that essentially forces full absolute locators usage. Absolute locators require you to load assets with full paths, can't load assets named like mytex.png for example. This change effects all loaders as well, for example the ogre loader will search for materials and skeletons in the same directory as the meshxml model.



In other words… anybody who currently uses jME3 for anything is likely to end up with a big pile of broken code. :slight_smile: Sorry about that but this engine is still alpha and I want it to be the best so designs will change.



Also based on some complaints I had from users I am going to change the input system to use something more like darkfrog's binding system rather then the current listener-based one.

May I ask, what is the reason for this? I mean that with absolute path it is quite difficult to refactor resources, move them to different directory or something like this.  So what are actually the benefits? Can't see any at the moment, but going to download latest snapshot anyway :slight_smile:

Please define "full paths". Do you mean relative to the root of the classpath (for example /res/1.png) or relative to the root of the file system?

KevinK said:

May I ask, what is the reason for this? I mean that with absolute path it is quite difficult to refactor resources, move them to different directory or something like this.  So what are actually the benefits? Can't see any at the moment, but going to download latest snapshot anyway :)

If you like flat paths you will still be able to add any path you like to the "root" of the assetmanager.

The problem now is that when you have two ships with a hull.jpg as texture it wont be possible to tell the two textures apart anymore. This applies for other areas as well, full paths are the only real solution for clean asset management, just like package names are for class management.

Cheers,
Normen

Edit: So "full paths" means a root that the assetmanager maintains, the classpath is in that root and any folder or jar etc. you add is in it too.
KevinK said:

May I ask, what is the reason for this? I mean that with absolute path it is quite difficult to refactor resources, move them to different directory or something like this.  So what are actually the benefits? Can't see any at the moment, but going to download latest snapshot anyway :)

But after you refactor you can bask in the benefits of using an absolute path based system :)
Really you gotta ask why were directories created? Why can't we just store all the files on our harddrive in the same directory? So your OS, your software, etc will all exist in the same directory. No this doesn't work, folders allow you to organize your files, they become much more effective the more files you have. In my opinion the new organization of resources in jME3 is a lot cleaner than it was before.

Good… xD I was having trouble locating my own files.

This update was definitely needed.

Thank you.


  • Mikkel



    EDIT: Is there any way to locate files from a data directory that is in the same directory as your bin/src folder?



    project/bin

    project/src

    project/data/textures/files



    Thanks in advance.
normen said:

Edit: So "full paths" means a root that the assetmanager maintains, the classpath is in that root and any folder or jar etc. you add is in it too.


Thanks for clearing that up.

Well I have currently the problem, that i don#t really knwo how to convert my code :confused:



currently I have:


      manager.registerLocator("/de/empirephoenix/models/", "com.jme3.asset.plugins.ClasspathLocator","material","meshxml","jpg");
      



I use just throw anything in the folder and be happy, not optimal but for the moment ok, guess I can just add subfolders as soon as the new system works.

Empire Phoenix: Just remove the list of extensions and it should work just as good as before.

thanks, works now :slight_smile:

Want to suggest a lower case checker for the classpath locator.



For whatever reason my texture names get changed around to all uppercase and the classpathLocator seems to get confused unless I add a toLowerCase line to the locate() function.



Thanks,

William

kirdel said:

Want to suggest a lower case checker for the classpath locator.
For whatever reason my texture names get changed around to all uppercase and the classpathLocator seems to get confused unless I add a toLowerCase line to the locate() function.
Thanks,
William

I guess thats on some windows system? I would not favor case-insensivity as classpaths are case-sensitive too..

Just tested and the mac needed as well. This is loading in a lot of textures from a jar file for an ogrexml environment.



Adding after line 56 of ClasspathLocator.java



name = name.toLowerCase();



fixed the problem (for me at least).



William

Problem is, ZIP/JAR is case sensitive. So if someone has a file in a zip they want to get that has upper case letters (like MyTexture.png), it won't find it with your code.

Blah.



This is my fault. I was using two different sets of texture packages. In one some textures had names like MyTexture.png and in the other I had lowercased everything.



Sorry sorry.



Thanks all,

William

No problem