Relative include of .ini files

Hi,
I really miss the relative including of the .ini files. That is (using hypotetical syntax) when I'm in some dir named "subdir" in some .ini file and would use:
!@some_other_ini.ini@
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.

It would really simplify some .ini generation which are coupled together.

Any opinions pro/against?

Thank You

Comments

  • edited January 2015
    Not sure, I have built up my resource path lists over time to cater for the various locations needed by different platforms. The ini's could be located in various places.

    But now that it's complete, I'm pretty happy with it.
  • edited January 2015
    Mmh, I'm probably missing something obvious, but why not simply adding your "subdir" to the resource storage list?
  • edited January 2015
    In my project, I'm using for each type of the soldier animation (for instance) solo directory. In this directory I have several .ini and couple of them are included in some main .ini in this directory. When I'm including them I should use the full path or add each of the directory as a resource (but this could be problematic, because some .ini files have the same names so there could be conflict?). Also sometimes I need to rename directory or move some of the .ini files to other dirs. And then I need to find all the references to the dir and rename it as well. If I would using the relative include, then all of this would be done automatically.
  • edited January 2015
    I see your point. However that wouldn't work in every case, especially if you're using either custom storage type or, with regular file system storage, if you're using the same file name in different places.

    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:
    /A/B/file.ini
    /C/D/file.ini
    

    If you were to add resource storages like this:
    [Resource]
    Config = A/B # C/D
    

    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:
    [Resource]
    Config = A # C
    

    Now the two resources have different names:
    B/file.ini
    D/file.ini
    

    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:
    A/B/include.ini
    

    And that you want to include it from A/B/file.ini. You can't do it with
    @include.ini@
    
    You need to use:
    @B/include.ini@
    

    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:
    C/D/include.ini
    
    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:
    /data/object/objects.ini
    /data/object/player/file.ini
    /data/object/enemy/file.ini
    /data/building/buildings.ini
    /data/building/house/file.ini
    /data/building/tower/file.ini
    

    You might want to use those storages:
    [Resource]
    Config= data/object # data/building
    

    And have those resource names:
    objects.ini
    player/file.ini
    enemy/file.ini
    buildings.ini
    house/file.ini
    tower/file.ini
    

    And in "objects.ini" & "buildings.ini", using those includes:
    @player/file.ini@
    @enemy/file.ini@
    @house/file.ini@
    @tower/file.ini@
    
  • edited January 2015
    Thank for the reply,
    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;) )

    Thank You
  • edited January 2015
    Sure for the ticket, but I don't know if it's the best place for keeping thinking about things, usually it's where the tasks end up being stored and not many people are going to look at them. ;)
    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.
  • edited January 2015
    Ahh, yes I totally missed the orx-dev group :) Ok so I just create the ticket, for now.
Sign In or Register to comment.