I think I’m a little confused with how and what is really this method intended for. I’m trying to use it to load any asset type given by a path. The thing is that depending on the asset type it throws a cast exception. Are this castings meaning to give that exception if given assetkey isn’t specific one, or is this just multiple bugs involving the same no-check error?.
I did a pull request fixing one of them but after finding a second one I started to doubt about if this is how the loadAsset(String) must be used. As an example, the fix is:
If this are bugs, I’ll continue requesting fixes while I find them :chimpanzee_closedlaugh: , if not, I’ll cry and find another way to make what i want :chimpanzee_cry:
I think the idea is that if you know what you are loading then you should use the appropriate method to load it… whether model, texture, etc… The loadAsset(String) method is likely for loading your own stuff.
What is the use-case for blindly loading stuff without knowing what it is? Just curious really.
I think it’s probably true that these methods shouldn’t crash like that but it’s also an unusual set of circumstances that causes it.
Well. In the case I want to load anything drop by an user on the “game” screen, with the current system I would have to make a “switch” over all the supported extensions (but this extensions could change over the time so I’ll have to maintain that switch manually). I also could create a “registration” system for supported asset types but I would still have to maintain it if any jme plugin or core adds support for other assets so, I was wondering if there isn’t a way to get the correct AssetKey implementation by the extension from the current assetmanager.
If not, the loadAsset(String) could work in a way that creates the correct key based on the extension (yes, it would require the correct files to have the correct extensions). It also could work analyzing the file header priory to creating the assetkey and making all the key things.
There are many decisions that JME makes that specifically do NOT support “random graphics editor”, though. You are likely to have an uphill battle to add features that are generally only useful in that use-case.
To be able to drop anything into your game, you are going to absolutely want to keep a close hand on whatever types you support and probably want to go with a ‘whitelist’ approach anyway.
…else what you are you going to do with a PNG when they drop it in versus a .blend file? Whatever switch you are using to decide what to do with Node versus Texture could be just as easily coded for file extension.
Basically, features that are not actually needed by a game are unlikely to be added… especially when it is trivial for the special cases to support this externally. At least that’s been the case any time I see something like that come up, and I generally agree with it.