I'd explicitly fixed the space thing a while back, but it was changed to using URLEncoder. Is that not working? Also, is the file from a jar or the file system?
I understand the purpose, yes. But wouldn't it make more sense to trim the beginning? So "/some/path/on/artists/machine/myTexture.png" becomes "/path/on/artists/machine/myTexture.png" and so on?
I'm using SimpleResourceLocator.
Changing URLEncoder.encode() to URLDecoder.decode() seems to solve the problem (but it might introduce other problems, because I'm not entirely sure about the intentions of the author of the original code).
URL rVal = new URL( baseDir.toURL(), URLEncoder.encode( resourceName, "UTF-8") );
changed to:
URL rVal = new URL( baseDir.toURL(), URLDecoder.decode(resourceName, "UTF-8"));
encode should be right, the resource names are expected to be in 'normal' utf-8 (not encoded), 'real' spaces still work in the resource name
Well, that's a problem. Renanse can you state where the names should be encoded and where not? I guess they should not be encoded within the files, right?
Hmm… Right, I think it is just a matter of defining a policy for use by RLT. Even if that policy is to use non-url encoded, we can still encode in .jme files if we want (although, off the top of my head I don't know why we need to.)
I propose that Strings given to a ResourceLocator will be assumed to not be URL encoded as currently coded. The RL will then URL encode it to create the URL it returns (also as currently coded.)
The code changes we'll need are just in model loaders I believe, which will need to wrap texture location string in decode statements.
Sanity check?
renanse said:
The code changes we'll need are just in model loaders I believe, which will need to wrap texture location string in decode statements.
yes, that's what I think, too (if files should contain the encoded strings, otherwise we'd need to change the writers)
Sanity check?
Do you mean inside the code? If yes, that won't be possible in all cases, as the same string might be encoded as well as decoded... if no: *check* :)
Why modify all the loaders when its much easier to adapt the resource locator… Isn't it the sole purpose of the resource locator: to resolve the location of textures (and other resources) from strings?.. :?
because the resource locators may be used by any piece of code (not just loaders)
Even better: the code using resource locator will be able to handle both encoded and unecoded strings! 
well, you can make the locator treat the string first as plain and if that fails, then as ecncoded, and catch any exceptions. You could remove some redundancy by doing something like this:
String oldName = resourceName;
resourceName = URLDecoder.decode(resourceName);
if (oldName.equals(resourceName)) {
return;
} else {
//search again for now decoded resourceName.
}
That should catch most of the cases...
o_O
just throwing some ideas XD
it's computer science, there is no such thing as not possible, the only questions is how long it's gonna take
That sounds like my encode(decode()) suggestion above… (mostly a throwaway remark) In the strong light of day, I'd prefer a strong contract of always one way or the other. This way you can much more easily predict behavior. I'm open if there is strong reasons not to go that way.
Well, I think the reason this even came up in the first place was that Java was not handling the nonsense when it came to pulling resources from a Jar… Perhaps that was the result of an encoded string in a model file though. I'd feel better with real world (in-engine) tests to prove out the solution here.
I don't know what was going on with the engine… but as far as URLs are concerned it's pretty much black and white, they go only one way or the other. I'm gonna make a test to peek in a jar file and see what happens to URLs then.
irrisor said:
I think this is a bug in the url handler for file:// - it does not decode +'s.
This bug is fixed in JDK1.6 btw.
It was only one location to change in TextureKey. It's in cvs.
While double checking it is correct now, I noticed that SimpleResourceLocator.trimResourceName does quite strange things: it omits the middle of the path, like this:
start: C:TempSomeDirOtherDirfile.png
becomes: C:TempSomeDirfile.png
becomes: C:Tempfile.png
becomes: C:file.png
becomes: file.png
Except for the last line this does not make much sense, does it?
If you've set up a RL texture directory: c:myTextures And you then load a model… The model may say, I want to load texture "/some/path/on/artists/machine/myTexture.png" The intended functionality is to use the path information in combination with the parent directory setup in the RL and trim upwards until the texture is found.
In your example case, it doesn't make a lot of sense because it is not a relative path. In that case, it ends up resolving to the filename.
Yes, good point. 