<div dir="ltr">Looking at PHYSFS_openRead() in physfs.c, I've found this little snippet:<div><br></div><div><div>do</div><div> {</div><div> char *arcfname = fname;</div><div> if (verifyPath(i, &arcfname, 0))</div>
<div> {</div><div> opaque = i->funcs->openRead(i->opaque, arcfname, &fileExists);</div><div> if (opaque)</div><div> break;</div><div> } /* if */</div>
<div> i = i->next;</div><div> } while ((i != NULL) && (!fileExists));</div></div><div><br></div><div>Now, from what I can see, this loop goes through all the paths, and the first one that satisfies the function and returns some data (from the openRead function) and causes 'opaque' to not be NULL, and thus breaks out of the loop.</div>
<div><br></div><div>So, if I replaced "if (opaque) break;" with "if (opaque) someVector.emplace_back(opaque, i);", then did some cleanup to ensure that I have a vector of FileHandle's instead of one, and return that, this should be exactly what I'm looking for, yes?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 3:03 PM, Indy Sams <span dir="ltr"><<a href="mailto:indy@driftsolutions.com" target="_blank">indy@driftsolutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Haydn,<br>
<br>
You should just make your PHYSFS_openReadMulti function, if you copy/paste the existing PHYSFS_openRead function it will take you about 5-10 minutes to make. You'll just have to use a compiled in copy instead of the system copy of PhysFS if your program is Linux compatible.<br>
<br>
Best regards,<br>
Indy Sams<br>
mailto:<a href="mailto:indy@driftsolutions.com">indy@driftsolutions.com</a><br>
<br>
Monday, August 25, 2014, 4:28:32 PM, you wrote:<br>
<br>
HH> PHYSFS_mount wont let me mount the same 'archiveFileName' twice,<br>
HH> even if the 'mountPoint' is different.<br>
<br>
<br>
HH> On Mon, Aug 25, 2014 at 2:21 PM, Edward Rudd <urkle@outoforder.cc> wrote:<br>
HH><br>
HH> On Aug 25, 2014, at 4:04 PM, Haydn Harach <<a href="mailto:hharach@gmail.com">hharach@gmail.com</a>> wrote:<br>
<br>
HH> How can I load the archives in separate directories? Within each<br>
HH> archive I have a "textures/" folder and a "maps/" folder. I want<br>
HH> to keep the "maps/" folders separate so I can load a specific map<br>
HH> from a specific archive, but I want everything in "textures/" to<br>
HH> overlap and be overwritten as is the default behavior.<br>
<br>
<br>
<br>
HH> You would use PHYSFS_mount and specify a subfolder for the second argument (mountPoint).. example<br>
<br>
<br>
HH> PHYSFS_mount( archiveFileName, "/mods/mod1", 0);<br>
<br>
<br>
<br>
<br>
<br>
HH> On Sat, Aug 23, 2014 at 7:37 PM, Haydn Harach <<a href="mailto:hharach@gmail.com">hharach@gmail.com</a>> wrote:<br>
HH><br>
HH><br>
HH> Ideally, what I want is a `PHYSFS_openReadMulti()` function,<br>
HH> which returns an array of `PHYSFS_file*` pointers. I don't mind<br>
HH> writing this function myself, as long as the underlying system is<br>
HH> capable of it. It is open source, after all.<br>
HH><br>
<br>
<br>
<br>
HH> On Sat, Aug 23, 2014 at 5:07 AM, Sik the hedgehog<br>
HH> <<a href="mailto:sik.the.hedgehog@gmail.com">sik.the.hedgehog@gmail.com</a>> wrote:<br>
HH><br>
HH> Then load the archives in separate directories and handle the<br>
HH> overriding manually (using a wrapper function for opening files would<br>
HH> be helpful here).<br>
HH><br>
HH> 2014-08-23 6:37 GMT-03:00, Haydn Harach <<a href="mailto:hharach@gmail.com">hharach@gmail.com</a>>:<br>
HH><br>
<div><div class="h5">>> Can't - I wont know exactly which files to load until run time (.map files<br>
>> can refer to other .map files, and that information wont be known until the<br>
>> player is in the .map).<br>
<br>
<br>
>> On Sat, Aug 23, 2014 at 3:10 AM, Sik the hedgehog <<br>
>> <a href="mailto:sik.the.hedgehog@gmail.com">sik.the.hedgehog@gmail.com</a>> wrote:<br>
<br>
>>> Then just take the second option (load .map files when you just mount<br>
>>> the archive, leave the .png files for after you've mounted<br>
>>> everything).<br>
<br>
>>> 2014-08-23 5:33 GMT-03:00, Haydn Harach <<a href="mailto:hharach@gmail.com">hharach@gmail.com</a>>:<br>
>>> > Problem is, I want .png files to be overwritten, but not .map files.<br>
>>> When<br>
>>> > the mod is loaded initially, it's just a big .zip archive, there could<br>
>>> > be<br>
>>> > .png or .map files within it's sub-directories.<br>
>>> ><br>
>>> ><br>
>>> > On Sat, Aug 23, 2014 at 2:13 AM, Sik the hedgehog <<br>
>>> > <a href="mailto:sik.the.hedgehog@gmail.com">sik.the.hedgehog@gmail.com</a>> wrote:<br>
>>> ><br>
>>> >> Two options:<br>
>>> >><br>
>>> >> - Mount them in separate directories and just deal with the fact (I<br>
>>> >> ended up doing this to prevent mods in my game from overwriting<br>
>>> >> configuration and savegame files).<br>
>>> >><br>
>>> >> - If the data is going to permanently stay in memory (i.e. you won't<br>
>>> >> need to read the files after initially mounted), then load the files<br>
>>> >> the moment you mount them (before mounting the subsequent archives).<br>
>>> >> The obvious upshot is that if you want you can unmount them after<br>
>>> >> loading (since the data is in RAM already).<br>
>>> >> _______________________________________________<br>
>>> >> physfs mailing list<br>
>>> >> <a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
>>> >> <a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
>>> >><br>
>>> ><br>
>>> _______________________________________________<br>
>>> physfs mailing list<br>
>>> <a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
>>> <a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
<br>
<br>
</div></div>HH> _______________________________________________<br>
HH> physfs mailing list<br>
HH> <a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
HH> <a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
HH><br>
<br>
HH><br>
<br>
HH> _______________________________________________<br>
HH> physfs mailing list<br>
HH> <a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
HH> <a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
HH><br>
<br>
<br>
HH> _______________________________________________<br>
HH> physfs mailing list<br>
HH> <a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
HH> <a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
HH><br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
physfs mailing list<br>
<a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
</div></div></blockquote></div><br></div>