Env->LoadGUI() and relative texture paths on iPhone

[Arcoroc]

I have an application running fine on windows and MacOSX that i am trying to port over to iphone/ipad, in which I am using the loadGUI("guilayout.xml") function to load GUI layouts, which works perfectly fine.

The layout I use create some buttons which reference textures, using relative paths. Upon calling loadGUI() and tracing the code, i see that loading of the textures happen during deserialization of the gui element attributes., internally to irrlicht.

The paths work fine and the textures are loaded on iPhone simulator since MacOSX can resolve final file paths from a working directory + subpath, however they are not resolved on device - since the device and its particular resource management cannot handle paths relative to a "working directory", that reference subfolder files such as this: "./gui/textures/buttonbackground.png".

I wonder what would be a good way to make it resolve paths on device during deserialization steps?
I could always preparse the guilayout.xml attribute path string values at runtime, and pass absolute paths to irrlicht, but i wonder if there is a more elegant way to handle it.

Thanks!

[BlindSide]

You can try to use FileSystem->addFolderFileArchive() to add a particular folder as a fake archive to the Irrlicht file system. This may solve your file path issues.

Or if that fails and using a ZIP file is possible, try that.

[Arcoroc]

For some reason, addFolderFileArchive() returns success, but does not allow me to access the files (not found) on iPad.

I could not get something useful out of the zip method, but indeed there was a very good shot there.

Meanwhile, i ended up removing some of my relative to absolute path translation logic, and... It started working. I did make use of setWorkingDirectory() on runtime launch, but i was under the impression that the peculiar resource access scheme fro iPad bundles (using subfolders) was not working as expected.

I was wrong, since it appears perfectly fine by now. I wonder if my problem wasn't simply that i was referencing filenames without care for the casing (unix being case sensitive, of course).

Thanks for the help!