in DesktopAssetmanager.java,
[java]AssetInfo info = handler.tryLocate(key);[/java]
sets up Assetinfo with a folder-path relative to the located AssetLocator. But there is no way to get the actual path loaded from, whitch is bad if you want custom loaders to be able to specify files relative to themselves or even know from where they’re loading their own file. All you get is the Path relative from the asset-managers collection of locators. The information is there, located in AssetInfoFile.file, but that field has no public getter, so please either provide one (it a one-liner that shouldn’t harm!) or please let AssetInfo reference the currently used Locator.
t.t how many times more? Its your filesystem. There is no root beyond it. It could be a friggin webserver!
thats the point: i need a way to get the path! The suggestion of using AssetInfoFile.file would only be a workaround, but at least it would work in my current situation.
Look: You load – lets say – http://vatican.va/nudes/list.xml, and you want that xml specify additional gifs that you – we already had that discussion, you know? – cant load via assetmanager because they are not used as textures only and Assetmanger, while loading BufferedImages, does not provide BufferedImages. So you need some way in the AssetLoader to get “http://vatican.va/nudes/”
We can even span this further, guess you have two locators registred: http://foo.com/stuff/assets/ and http://bar.com/stuff/assets/, from both you want to load a file referencing other files relative. You’d end up loading both references from the first fitting locator, not from the current one if you give those references back to AssetLoader.
If you add http://vatican.va/ to the list then you will get the path as nudes/list.xml, wouldn’t that work for your purpose?
The point of the AssetManager is to create a VFS (Virtual File System) on top of your assets. When you provide a method to get the root path of the asset, you’re violating the constraints of the VFS.
OK, but that would need me to replace at least AWTLoader with a complete rewrite° and – worst case – DesktopAssetmanager with a derived class – something i’d like to dont do, because it could introduce differences if something in those original classes changes. having acces to the rootpath would circumvent that because i could implement my stuff outside of JM3.
° unless extractImageData would be declared protected and the other functions static.