I'm not sure how I want to handle this yet, but for now, using a vector<pair<...>> is the easiest way currently to retain insertion order. Using a hash table IS probably a better idea, and I'm looking to maybe importing Boost multimaps to allow that, but for now, /shrug.
This starts the beginning of probably one of the bigger refactor jobs, and one I've been hinting at and FIXME jabbing for a while now.
Basically, tasks now are a lot closer coupled to their arguments. This is a good thing since it means that changing or adding features only requires modifying the task, not needlessly modifying main over and over.
CreateTask is the only one that works currently for this commit and has been converted to the new ITask model.
This really could be classed a "fix", since adding support for it when reading broke writing. Now we do the right thing.
This makes sector-alignment a no-op when writing other archive versions. I might make it an error to specify -s with a non-JSF package version.
As it turns out, the unix time is NOT junk in them. The short I identified is *before* it. Oops
The hexpat is also fixed up so it can analyze v3, v4, and v5 successfully.
As it turns out the thing I marked as "header size" is more likely just a discarded revision.
Anyways, to detail this: pak version 5 adds fields to the header for sector alignment. The reader now handles this and reads the sectoralignment TOC entry, which now allows STREAMS (and any other packages with this set?) to extract properly.
Woohoo.
Also fix some warnings and potential issues that building the entire EuropaTools codebase under those flags showed.
Later on once we drop the libpixel and stbiw dependencies, we can probably turn on -Werror for release builds.
This allows pak writer file data to cleanly come from one of two possible sources:
- A file on the filesystem (in which the PakWriter will open the file, tee it into the package file efficently, and then close it)
- A data buffer (which functions like before)
PakReader however will always output data buffers.
This bug was introduced during refactoring (to allow pmdl export support); it causes the writer to not write any file data.
Additionally the writer now sorts by creation time. I'm not sure if greater or less are the correct order.
................. fuck
This really needs to be cleaned up before I'm willing to call it "good" but ultimately the API changes here needed to be done anyhow
Ditto. Also has a cute little progress indicator (more detailed
progress will probably have to be done later..)
Removes pakcreate, as it's now replaced by eupak for good.
I have been preparing for this for a while. Instead of having a bunch
of strewn out utilities, let's just have one solid multitool
which is nice to use.
This commit also removes europa_pack_extractor, as it's now unnesscary
and replaced with a better utility, that does more.
Creation wasn't implemented yet, but I really need to sleep. It can be done later, and pakcreate can be used as a temporary stopgap.
Instead of using set_target_properties on all tool binaries,
instead we can use target_compile_features([xxx] PUBLIC cxx_std_20).
This properly alienates projects which depend on libeuropa, allowing the src/tools CMakeLists to be trimmed down quite a bit.
Also fixes a build break I accidentally introduced.
While working with scrc I made the pak files output sorted by size. This doesn't
seem to have helped with performance but I guess it might be nice to maybe
do the conversion in hand.. or just make the writer take a vector of pair to use.
Also improves paktest.
Pakcreate is a new utility for creating completely new archives from a directory.
Usage:
pakcreate [input path] [output .PAK/pmdl filename] [--jedi]
Options:
--jedi : Make Jedi Starfighter archive
PakReader won't read everything in ReadData(), it now only reads the header and TOC.
Files now need to be read in separately.
Adds progress bar to europa_pack_extractor.
Moved code around.
Don't have a tool for building "fresh" packages yet, but the "paktest" tests regurgitating a pak into a new pak file.
Usage is:
./paktest [pak file]
it will write to "new.pak" always, which meh. It's just a test utility.