Relative include of .ini files

Comments

• sausage

  January 2015 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.
• iarwain

  January 2015 edited January 2015

  Mmh, I'm probably missing something obvious, but why not simply adding your "subdir" to the resource storage list?
• Trigve

  January 2015 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.
• iarwain

  January 2015 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@
  
• Trigve

  January 2015 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
• iarwain

  January 2015 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.
• Trigve

  January 2015 edited January 2015

  Ahh, yes I totally missed the orx-dev group Ok so I just create the ticket, for now.