This fixes Halo CEA putting itself into a packaged/demo mode, where it doesn't perform some DVD checks & skips cache mounting, and probably other things too.
Now CEA should actually mount & write some stuff into the cache dir while the intro cinematic plays
(first writes a pak_stream.s3dpak file, then after a few seconds into the intro video it writes fileList.ps, which seems to have some strange values inside..)
I also added an exception to the code for arcade titles, since they'll probably need to use XamContentGetLicenseMask even when ran outside of a package.
These get stored in different header IDs, 0-31 is inside 0x30000, 32-63 is in 0x30100, and 64+ is probably in 0x30200, etc.
Not sure if any games actually try checking these extended privileges, but hopefully this code should help if any do.
Sega Rally Revo has a weird check for the 0xB privilege, if it's set the game bails out for some reason, a bunch of code doesn't get executed and the game hangs.
Fortunately we can kludge a way around this: the cache code we're trying to influence with the 0xB privilege always seems to check for the 0x17 privilege just beforehand.
The bailout code doesn't, instead it checks for 0xB first and then 0x17 - so we can just add a check to only return true for 0xB once we've already seen 0x17.
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.
This will make logs more readable and little lighter
Todo: Find out what that register means. It doesn't even have description.
My best guess is that it is used for sync?
Replace a movzx after setae in both ComputeMemoryAddressOffset and ComputeMemoryAddress with a xor_ of eax prior to the cmp. This reduces the length in bytes of both sequences by 1, and should be a moderate ICache usage reduction thanks to the frequency of these sequences.
I'm not exactly sure about amount of parameters,
so I used them from XamContentCreate and it matches quite nicely.
Now Fifa Street returns correct file creation (and it does the file),
but on next run it is corrupted :/
Seems the double-keypress issue was because of XINPUT_KEYSTROKE_REPEAT: Xenia would add that to keyup events, but seems REPEAT is only meant for keydown (well SR1 treats it as a keydown event at least)
CoD4 requires the unicode member to write text into the dev console, Win32's ToUnicode function seems to work fine for this.
Xam functions have been updated to support keyboard devices too, which *should* let CoD4 detect the keyboard and let you use it to open console etc..
Seems the XEX still needs a 1 byte patch for it to work tho :( no idea why, does keyboard work on actual X360 without any patching?
CoD4 calls this with a huge 0x4000 buffer, and then if the buffer_size returned is any smaller it asserts & stops running...
Need to check if this is actually how it should work, but this should help get some CoD4 running
I think this should be safe to do, seems games will only make use of either cache:, or cache0: & cache1:, not both kinds, so shouldn't be any risk of conflict.
cache: might only be used in older SDK cache code, at least so far I've only seen it used in the older Halo 3 Beta build.
This'll load in and convert the SPA data from the spa.bin inside DLC (marketplace / 00000002) content, into the profile GPDs.
(note that changes from the new SPA won't show in the log-file achievement list until game is restarted!)
Also fixed some minor log bugs to do with endianness...
The existing SPA code should make sure only additions from the SPA are loaded in, eg. achievements that were added - achievements that might be missing shouldn't make any difference.
e.g. it should be able to perform a load like:
base game (20 achievements) -> DLC2 (50 achievements) -> DLC1 (30 achievements)
and the final GPD will contain the 50 achievements, from the SPA which contained the most.
Only additions from new SPAs will be loaded, any achievement changes (like a description text change or something) won't have any effect.
Not sure if we should try adding things to support that or not...
I'd guess that the X360 would probably support it, but if there isn't anything that takes advantage of it, is it worth us supporting?
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)
It will allow to run dashboard with signin_state = 2
Should we create different xam file for XamParty functions?
ToDo: Finish struct that store user info
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.
Storing the content type inside the device ID from DeviceSelectorUI shouldn't be needed now.
AFAIK it was only used so that we could extract it later inside XamContentGetDeviceData, but that wasn't actually how GetDeviceData was meant to work.
emoose