Amióta létezik a packfile, azóta az engine minden content betöltési requestet képes abba irányítani (egy külön build configgal). Ha megtalálta a pack-ban, akkor onnan szedi be, ha nem találta meg, akkor megkeresi a megadott search directoryban és hozzáadja.
A probléma a következő: egy adott pathon elérhető effekt fájl beinkludál egy headert. Majd egy másik folderben levő effekt szintén, de más relatív hivatkozással:
#include "../alma.h"
#include "../../alma.h"
Eddig ez kétszer került volna be a packba, ami kicsit pazarlás. Az egyik feladat a packfile specifikációját lerögzíteni, a másik pedig az inkludok kigyűjtése és megfelelő elhelyezése.
A packfile-t a következőképpen módosítottam (valójában csak a formális paraméterek neve változott meg).
bool Add(const qstring& filepath, const qstring& packpath);
Tehát az első paraméter a fájl amit hozzá akarsz adni, a második pedig a célpath a packban. Ha a célpath már létezik, nem írja felül, de ha más helyre rakod, akkor még lehet duplikálva (de ez így jó).
A másik feladat a content managert érinti. A SearchDirectory member megfelel a pack file gyökerének, tehát ha egy betöltési kérelem jön, akkor ehhez relatívan keresi a fájlt, és az ettől való relatív elérési út lesz a pack-beli path. Ha a search directory-n kívülre történik hivatkozás, az hiba (de csak warningot dob).
A #include-okat először is ki kell gyűjteni. Ezt tudni kell akkor is, ha fájlból töltöd be, de akkor is ha memóriából. Az előfordító ezt vidáman meg tudja csinálni, egy fájlra. Tudhatná többre is, de akkor folyamatosan callback-eznie kéne, hogy lekérje az éppen aktuális fájlt a packból. A rekurzió ezért inkább a content managerben van.
Az inkludolt fájl pack-beli elérési útját úgy lehet kiszámolni, hogy kombinálod a szülő path-ját és az include relatív path-ját.
qEngineHelper::GetPath(str, parentfile);
qEngineHelper::ResolvePath(str, str + rel_include_path);
A parentfile itt már eleve relatív (a search directoryhoz). A pack természetesen tömörít is (ahogy eddig).