It looks like you're new here. If you want to get involved, click one of these buttons!
then "some_other_ini.ini" would be loaded from the current dir ("subdir"). If no file is found, try to other locations defined in resources.
[email protected][email protected]
But now that it's complete, I'm pretty happy with it.
The config system doesn't know anything about how resource are stored nor where they come from. For example, they could be coming from file system, packed archives, network or memory, and those could have custom location strings, not just paths with /-separators.
Let's take the simple case of file system. If you're using the same name for two files, you could have something like this:
If you were to add resource storages like this:
Then you wouldn't be able to access both files. Locating "file.ini" would always return the one from the first storage ("A/B").
However if you were to add them like this:
Now the two resources have different names:
As you can see, the end of the path is actually now part of the resource identifier (name) and that allows us to differentiate them.
Now let's say you have a third file:
And that you want to include it from A/B/file.ini. You can't do it with You need to use:
Also the config module wouldn't know how to look for "local" folder. It doesn't have this information, it only knows it's currently handling a resource named "B/file.ini". We could write custom code to would assume that path are using /-separators and extract the "current dir" from it, and add it as a temporary storage (adding it before loading the include and then removing it).
But even that would be flawed. Imagine you also have this file: And you want to include it from "C/D/file.ini".
Now, even if extract the "current dir" (C/D), and add it to the temp storage with the highest priority, it'd still load "A/B/include.ini".
How come? Well, the request would be looking for the resource named "include.ini", however the resource system already know that resource (it's been loading previously when included from "A/B/include.ini"), so it'll retrieve it from its cache and will never look inside any storage. Next step would be to flush the cache before doing such a request, but that's getting quite ugly there. Not even mentioning that it's likely to break the watch/hotload system, as this one relies on the uniquely named resources.
In addition to this, if you use any custom storage type, the location string might not contain the file name or a "path", and this wouldn't work at all.
For example, the custom resource type to support ZIP files I posted on the orx-dev group uses indexes in the location string, no names.
Ie. locating "B/file.ini", might return this location string "zip://archive.zip:38".
I'm afraid your safer bet for now would be to define your storage carefully as well as your resource "names".
For example, if you have:
You might want to use those storages:
And have those resource names:
And in "objects.ini" & "buildings.ini", using those includes:
I thought that it wouldn't be so easy to implement it because of custom storage. I've already structured my .ini files better (as by the suggestion in the mail communication) so it isn't such a big problem
Maybe I just could create ticket just to know that such a feature request exist and it could be there just for some brain-storming and archive purpose (and maybe in some distant future it could be implemented in some clean way;) )
I believe such a discussion is best hosted on the orx-dev group where the whole discussion can be tracked and where people interested in the dev aspect will be notified.