Relative paths

[SirNate0]

I've added relative path support to the ResourceCache. Main changes are nodes now storing their base paths, the mechanism for accessing the base paths, and the addition of a basePath parameter to GetResource functions.
Note that this breaks the existing API -- I added the base path parameter after the filename, before the bool sendEventOnFailure. This could be done the other way around, but I feel that it is more logical this way, and encourages users to actually pass a basePath parameter.
Also, there are a few things left to do -- JSON loading does not get a base path (see the added #warning notes), and how it is handled with scripts also needs to be decided -- is it relative to the script instances's path or to the node that hold's the instance? (See the added //TODO: comments).
Also, the actual resolving of the relative paths onto the base path may not be as efficient as it could be -- I've not tested it, but I reason that it is not done often enough that it would be a priority for optimizing now, unless someone else finds otherwise.

[Lumak]

Why is this necessary for nodes to store their own path? Is path set by EP_RESOURCE_PATHS broken for you?

edit: I'm voting this down, as I'm not in favor of code bloat via nodes maintaining their own path when paths set by EP_RESOURCE_PATHS is more efficient. Provide any info that may be pertinent to your argument.

[eugeneko]

Huh, I definetely dislike the part with Set/GetBasePath for serializables. As I understood, it is done to make prefabs work with relative paths. Any chance to reach this in another way? Let's think....

[cadaver]

Regardless of what happens with this, don't think would want to take this into 1.7, just for the potential risk.

[SirNate0]

@Lumak this is to address a different issue from the resource paths -- it is meant to allow you to reference resources from say a scene "bin/Data/Maps/Area1/scene.xml" that are located in the resource directory "Data" (or any other resource directory) that you would normally reference "Maps/Area1/SomeTexture.png" as "./SomeTexture.png" instead. Yes, you could just add "Maps/Area1" as another resource path and then just look for "SomeTexture.png", but if you have multiple areas used at once I would not consider it a tenable solution, as you could only access conflicting resource names from the most recently added area (i.e. you also have Maps/Area2/SomeTexture.png, and the two scenes/prefabs use different textures for that).
@eugeneko I am open to suggestions. One would be to actually store the base path in the Serializable, but I felt the benefits of the cleaner appearance of that were outweighed by the fact that doing so seems to offer no added functionality, but would add a String to every single Component (and other children of Serializable) that, for at least the cases I could think of, would end up being identical to the Node associated with it. If you or anyone else can think of a better solution I am all for it.
@cadaver Sounds reasonable, especially since testing it with the resources actually used by Urho is difficult to do in a way that would reflect actual use cases because they tend to be set up where the shortest path would be the 'absolute' one starting from the resource directories, since they are grouped by type of resource (and I don't advocate we change this, as I don't think any of the samples would benefit from a different grouping like the map area use case). I can say that in my own project I've encountered no problems with it, but only resources I've created in the past month and manually edited (the exporters still use the absolute paths, and I have no interest in 'fixing' these when they are not broken unless I am already editing them by hand, in which case the relative paths are more convenient).

[Lumak]

I see. That might be useful to some, but I still prefer the current method.

[t-artikov]

@SirNate0, @eugeneko
Any new ideas on this issue? I would be glad to have relative paths support in Urho3D.

[eugeneko]

@t-artikov I'm working on new Editor since last month. I'm going to check this feature when I switch back to the Urho core.

[github-actions]

Marking this stale since there has been no activity for 30 days.
It will be closed if there is no activity for another 15 days.