Is it a Laxe client, or a Legend of the Ring client? AFAIK Laxe Lore is defunct, and it's code has been recycled into LotR-OL, who's goal is to distance it's self as much as possible from the PT heritage of Laxe.
--- EDIT ---
Oh! Yea, .pkg files, should be easy to work out a
You must be registered to see links
script to handle them.
Typically most MMOs are using some form of "packaging" (like archives) now, and of course developers like Westwood Studios (.pak files from as early as Dune II), ID (Quake .mdk / Doom .wad etc), Blizzard (.mpq) and Bethesda (.bsa) have always been around.
Most people think this is to "hide" data from users, and for Blizzard that was one reason... however, Blizzard have come to embrace MPQ modders, especially with Diablo II and Warcraft III, and Bethesda have always recommended Elder Scrolls modders to extract the .bsa archives, and now recommend mod makers pack up their mods data into them too.
The
real reason is that light decompression, and avoiding Windows file system unindexed searching for file names usually produces more optimal loading times while playing than relying on the Windows file system cache and reading uncompressed data down the IDE (or SATA or what-ever) line during play.
Remember... thinking low-level, as any video game programmer should, accessing the hard disk isn't just slower than accessing RAM, it also creates interrupt requests, and takes up DMA handles. This
will stop any hardware access by the graphics card to memory (because the IDE / SATA / Firewire / SCSI controller has to have sole access at that time) and will also force a slow "context change", because the drivers controlling the external storage (hard disk, CD, even a solid state drive or USB thumb-drive) are Ring 0 privileged code run as part of the kernel.
Context switches are bahd! (slow) Context switches to access slow devices are really bahd! So you keep them to a minimum.
If your game can keep the entire archive set in memory, like a compressed RAM disk that bypasses the OS entirely after the initial load, you are laughing. But even if you can only generate an in-memory database of real files, and offsets within them at which actual file data is located, you can keep the handles open for all the archives (avoiding the need to FindFirstFile(), FindNextFile() repeatedly until a match is found or a "not found" error is returned... and that is slow on most OS / file systems) and won't have to read the index of the archive again during game action.
Simple "Deflate" (zip), LZH, or even RLE decompression is relatively fast, compared to loading largely redundant (repeating, or predictably changing) data directly from disk. And if you can keep global "dictionary(s)" in memory as well, the read and decompress time of methods like Deflate and LZH / LZO becomes very very fast indeed by comparison to reading uncompressed.
In fact, slow media loading times was one of the original arguments for compressing executables, especially when they where likely to be read from floppy discs, CDs or across a network. (but also because ATA hard disks where so much slower than even 33mhz EDO RAM
)
This is where PKLite, (from the same people who invented PK-Zip which used to "own" the .zip file format via patent) ComPac (for DOS .COM files only) and PEtite (one of the first to handle 32-bit Windows executables) came in. And most of DR-DOS (from Digital Research) utilities, from version 5 onwards where packed with PKLite.
![bobbman - Laxe Lore [aka modified Priston Tale engine] - RaGEZONE Forums](https://forum.ragezone.com/images/404_image.png "bobbman - Laxe Lore [aka modified Priston Tale engine] - RaGEZONE Forums")
