This fixes some games (eg. Halo: CEA) not mounting cache.
It seems some games use different SectorsPerClusters values, which then changes the value it expects from NtQueryVolumeInformationFile.
Since we'd always respond with a static value this would make the game think that mounting failed, and it'd bail out of the cache-mounting code.
Now we capture the SectorsPerCluster value when the game writes it to the cache-partition header, and update the NullDevice's sectors_per_allocation_unit with it.
Reverted to older BlockToOffsetSTFS code (with some improvements, now named STFSDataBlockToBackingBlock)
Split the To*Offset functions into ToBackingBlock & To*Offset funcs, for later use when we need the actual block numbers instead of the offsets.
Store the num blocks per hash table & block step count in the device instance, instead of calculating it each time.
Add read_only_package() & root_table_secondary() getters to the STFS descriptor struct (note: will be replaced with better stuff once stfs-headers is eventually merged)
This should hopefully allow Xenia to be more compatible with larger / more made-use-of profiles.
Each hash table actually consists of two hash tables for redundancy, which table is used is decided by the hash table level above it.
Previously there was some code to try swapping which table to use if a flag isn't set, but the code ended up being commented out & unused...
After looking at some other X360 mod tools sources I've managed to come up with this solution, which visits each hash-level it can to retrieve the correct table number to use.
Really this is probably a little inefficient, the code I based this on would actually cache each table in memory to make these visits a lot quicker, maybe should look into doing the same here.
For packages with read_only_package() == true, this maybe isn't even necessary too - but it's probably worth keeping it as-is just in case though.
65ca664fdb
This should give better compatibility with CON packages - ie. profiles taken from actual consoles should hopefully extract properly without errors, now there's shouldn't be any need for extracting them with Velocity/Horizon first.
Profiles can now be placed as either an extracted folder with GPDs, or an STFS package, inside the Documents\Xenia\content\FFFE07D1\00010000\ directory
eg. Documents\Xenia\content\FFFE07D1\00010000\E0000E07FA53D7F1
(this roughly matches the same location as X360 stores it)
If loading an STFS package the package will first get extracted to <path>.dir/, and then the profile is loaded/saved into that directory.
(originally was going to mount the package and read everything in-memory, but then realized how hard adding new files/modifying/etc would be.. VFS doesn't allow mixing two devices into the same mount_path afaik)
Code for extraction is taken from xenia-vfs-dump (as StfsContainerDevice::ExtractToFolder)
A [XAM]profile_xuid config option is added too, which should let you pick which profile to load from the FFFE07D1\00010000\ folder if you have multiple there.
(at least I hope it should - something like "profile_xuid = 0xE0000E07FA53D7F1" will work I hope... cpptoml might have issues with hex digits though, not sure, will investigate later...)
If profile_xuid isn't set (left at -1), Xenia will just load whatever the first file/folder inside there is.
Happy new year! Here's my first commit of the 2020s :)
With these fixes, Halo 3 Epsilon will now write cached map data & other things (autosaves/datamine...) to the cache0/cache1 partitions, (as long as mount_cache cvar is set)
(Halo 3 retail will also write some things to cache with this, but oddly doesn't cache map stuff... which is strange because Epsilon was built only a day or two after the retail build, so I'm not sure why it'd work differently...
Maybe retail needs a TU applied for it to work or something like that)
Other games should hopefully work with cache now too (AFAIK the problem was in SDK library code, that a lot of games probably share)
No idea if this will actually improve anything though, but at least things will work closer to what games expect :)
The way this works is by tricking the cache-partition code (staticly linked into the game exe) into thinking that the Partition0/Cache0/Cache1 devices are valid.
To do that I made another kind of VFS device, the NullDevice, which just takes in a list of paths to handle.
Whenever an IO request is made to one of these paths, the NullDevice can simply pretend to the game that everything was successful, which satisfies the requirements needed for caching.
It also makes use of another trick: setting TitleInsecureCacheDrive XEX permission, which seems to skip a huge chunk of cache-init code (STFC filesystem device registration & stuff like that)
I'm not sure if this would work with every single revision of the STFC/cache code though...
At least in Halo 3 the retail code will handle the TitleInsecureCacheDrive case for us fine, but maybe older/more recent versions don't include functionality for it, need to look into it some more.
(I did try an impl. without needing this permission months ago, got pretty far with it but got caught on one tiny issue that I couldn't figure out... too bad I didn't find out about this permission earlier!)
- Fix up handling of positional options in cvar handling so that executables
other than app can handle them properly.
- Fix command-line arguments for xenia-vfs-dump.
Games like Forza use NtQueryInformationFile to get the size of the file, to make sure that there's enough room inside it to write data.
Previously, updating the file size (via SetInfoFile(EndOfFile) or WriteFile) wouldn't update the vfs::Entry size field, which NtQueryInfo uses to return the size of the file.
This resulted in the game thinking that the file was smaller than it actually is, and trying to correct that by using SetInfoFile(EndOfFile), which then truncated the file and deleted important data that was written to it.
- Convert http to https, provide archive link when possible.
- Made CPU-JIT.png more readable on dark themes;
Added a white background so there isn't black text on a black
background.
emoose