There is no way to pass additional, application specific information to a loader.
Please change that, i post a solution that should not break existing user code and requires just minimal engine changes:
In DesktopAssetManager.java, please change the following functions:
[java]public Object loadAsset(String name, Object aux)
{
return loadAsset(new AssetKey(name), aux);
}
// allow legacy code pass without changes
public Object loadAsset(String name)
{
return loadAsset(new AssetKey(name), null);
}[/java]
further, please change the following function:
[java]public <T> T loadAsset(AssetKey<T> key, Object aux)
{
// … //
try {
o = loader.load(info, aux);
} catch (IOException ex) {
// … //
}[/java]
That would also need changes in interface AssetLoader and minimal changes in implementing loaders
[java]
public Object load(AssetInfo assetInfo, Object aux) throws IOException;
[/java]
The advantage would be, that you can pass all kinds of information (either by string or by simply creating an auxillary class for that) to the loader.
It would also allow you to create your object and let your custom loader fill it, like this:
[java]MyObject obj = new MyObject();
obj.doSomethingStupid();
getAssetManager().loadAsset(“something/myfile.foo”, obj);
[/java]
I also looked into the getExtension function of AssetKey, and i think a different approach should be used. The current way is to just scan for the last dot, and in case of xml, the dot before – a real hack.
What about people that want files ending on “-n.png” just handled differently than files ending on “-t.png”? I think, AssetKey is just the wrong place for that. A better approach would be to go thru all AssetLoaders and pick the best fitting one, that means, comparing the registered last sequence of the loaders with the files name and pick that one, that has the longest equal sequence. That would allow for registration of a “-t.png” loader that doesent gets called for “foo.png”, while you could still register “.mesh.xml” and “.skeleton.xml” differently without blocking other xml-extensions. It would also be possible for an application to register a loader for a “foofile”, that gets called for a file that is just named so.
If you want to pass additional data to AssetLoaders/AssetLocators, please extend AssetKey and provide the necessary data members.
While I agree that the current solution is no the best ,
I think this: A better approach would be to go thru all AssetLoaders and pick the best fitting one, that means, comparing the registered last sequence of the loaders with the files name and pick that one, that has the longest equal sequence.
Will be pretty bad with many assets this will lead to a lot of microlags.
Thats what the AssetKey is for, you’d create a special AssetKey for your file type. The asset type is defined by the letters after the last dot, the rest of the meta info is stored in the AssetKey. You can do anything you want with the names using a loader, for example for the NeoTexture loader I accept loading different images using a name?imagtype syntax. Thing that would actually be nice is a proper, unified system to add parameters to the name. Otherwise I dont know what this tinkering with .xml and other endings helps you… Just accept that the ending defines the type in and for jme3. The asset key (the string) is an important entity, it has to be unique and contain information about the type. Our convention is to use the suffix for this because it comes preconfigured with many file types 
OK, lets split this in two…
First branch is the suggestion of adding another parameter to the loadAsset-function, i realy cant think of any disadvantages. Allowing generic pointers (java-theologists may call them references) is a very usefull way of passing customizable information in and out without having to predefine how that data is to be organized and therefore without applying unneccesary restrictions. A very good example is the change of Win16’s WPARAM and LPARAM definition in Win32 API to something that can be used as anything ranging from simple integers to pointers.
The second branch is my suggestion of a more generic way of organizing suffixes. No, Phoenix, id would not introduce microlags, it would in fact be faster. What you currently do is split the string, to something very McGywer for xmls, and then tell your assetloader-collection to get the key with the fitting extension string. The collection handles string comparsion for you but that doesnt mean it comes in nulltime.
So my (faster, more generic, better usable) way would be to…
• leave the string as it is,
• set up an integer iMatch to 0 and an integer iIndex to -1,
• loop thru the collection and compare the AssetKeys stored ending with the string.
• If its equal, set up iMatch to its lenght and iindex to its index in the collection.
• Now you skip all AssetKeys with stringlenght <= iMatch (really fast) and just compare the ones that are longer.
• If you find one matching, you have found a better fitting one and set up iMatch and iIndex accordingly
At the end, you take the AssetKey of iIndex if you have something other than -1…
Fast, easy, relying and customizable.
Well, for the .mesh.xml.porn.wikileakdoc.encoded.byrhavin filetypes a better handling might be interesting (however I personally think double dotted endings suck, in ogre they just about make sense because theres the binary format too…) So if you come up with code handling the endings better (and maybe additional parameters) that would be cool. For a “generalized” loader with options method in assetLoader… I don’t quite know… Theres the generic loadAsset() which could use any data saved in the Key… Or theres very special loadMaterial() loadModel() etc. that just get along with a String… I don’t really see the “in between” where this wouldn’t just be a feature creep inside the loader system…
(Remember all arguing I do is to prevent jME3 becoming an engine bloated with features that all work semi-good and have no logical connection like in jME2, and constructive input is always very welcome!)
Cheers,
Normen