If this flag is set there shouldn't be any need to read from the hash tables, we can just read from each subsequent block number.
We'll only trust this flag if the package is read-only (LIVE/PIRS) though, in CON packages we'll always read from hash tables.
This'll try salvaging any corrupt packages loaded in: normally we find the block numbers belonging to a file by reading them from the hash table.
Seems there's some packages out there (eg. Mass Effect 2 demo) that have corrupt hash tables though, so using the block numbers from there just results in a crash.
By verifying the hash of each hash table we can detect if this is the case, and if so we can try just using current_block_number + 1 instead of use any invalid block number.
(we also let the user know about the corrupt table in the log file)
In LIVE/PIRS packages this should hopefully let us get the correct data, since files are usually stored inside consecutive blocks in those package types.
It's doubtful that it'd help much with CON ones though, since those are pretty much a living filesystem.
The older & more used a CON package is, the more likely blocks will be fragmented throughout the file...
Reading from the hash table is the only way to properly read data from these, using current_block + 1 likely won't help much (we'd be going wxPirs-mode, in a way :P)
CON packages do have something that might help with this though: redundant hash blocks, where each hash table is actually made up of two blocks.
Maybe in future we can find a way to automatically use the secondary block whenever the primary one is invalid.
Should let Halo 3 savegames work now (Resume Solo Game...)
This changes XamShowDeviceSelectorUI code to pretty much the same code as xenia-master, with some param checks added from XAM.
Looks like it was 0xB notification which made Halo 3 abort (looks like thats for when storage devices are added/removed)
I guess Halo doesn't like to see that notify just after it was told the device it could make use of?
I reverted the function to master since I don't really think the threading stuff is needed any more.
AFAIK the threads just turned out to be a band-aid fix for the issue in https://github.com/xenia-project/xenia/pull/1417, where games could only ever see a single notification for a given ID.
(Since we'd send the first notify in one thread, then wait a little while before sending in another thread, that'd gave it enough time to see both notifys - but now with the fix from that PR this band-aid isn't needed)
If there's actually any regressions from removing the threading code we can easily put it back in (I'd be really interested in any games that might require this kind of thing too)
The way these functions are handled (and really everything that uses XOVERLAPPED) isn't really correct tho, since they'll cause blocking in the caller thread while it does the work which the actual XAM impls don't do AFAIK.
There probably should be a seperate thread that handles all that, completing the overlapped etc, but I really don't think the way I did it with this band-aid fix was the best way for 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)
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.
This would break strings like memory://%.*ws, because the %ws would set FF_IsWide, but FF_IsWide is actually treated as an "is opposite encoding" flag.
Since the function is already wide, that flag would make it think it's opposite encoding and it'd try reading the param as ASCII instead of Unicode...
Seems to kinda work, xshell uses XamProfileCreate and says that it's successful at least.
Dash uses the ShowUI function, but doesn't seem to login to the created profile correctly for some reason... restarting with the toml configured for the new profile does seem to work though.
This caused dash not to load profile anymore, since dash passes user_index == kNone...
The new method should be closer to how things are actually meant to work.
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.
Strange, seems ReadProfileSettings returns this error as the result code instead of the xoverlapped error code - it could be possible other Xam functions do the same too.
This fixes Crackdown loading (thanks Gliniak for the tip about buffer size), hope it doesn't break any other games though.
Would only allow access to dash GPD previously...
I'm not sure if we need to setup the XPROFILE_TITLE_SPECIFIC settings in advance or not though, really it should be on the games to do this themselves, but not sure whats actually needed...
This should probably fix games that would save progress to profile (Halo 3 progression, etc.), haven't actually noticed any changes myself yet though.
Now the XUID doesn't need to be set at all for Xenia to try logging into an available profile (as long as signin_state != 0, previously this needed XUID to be set to '1')
So from a default install, you should be able to just drop an X360 profile into the right profiles dir, and when you run Xenia it'll login to it automatically for you, no config changes needed!
This applies to all 4 user slots, just set their signin states, drop 4 profiles in and it should log them all into each one seperately, then you can edit the config with specific profile XUIDs for each user.
Xenia should now only generate a default XeniaUser profile when no profiles are available for a user.
This adds support for multiple profiles to Xenia, profiles can be configured with the [Profiles] user_*_xuid / user_*_state config settings.
If state is non-zero (1 = offline, 2 = LIVE), the profile will be counted as logged-on - either with a generated XeniaUser gamertag, or if the XUID is set to 1 the first available profile will be loaded.
The XUID can also be set to the offline-XUID (E000...) of an existing profile, to sign in the user as that profile.
(Profiles should be stored in the Xenia content/FFFE07D1/00010000/ folder, either as an STFS package or an extracted folder)
All the XamUser* functions have been updated to support multiple user_index's provided to them too.
(there's still issues with weird indexes like 0xFF, 0x7FF9... being given though, still dunno what's with that, the KernelState::user_profile() code will treat 0xFF as 0)
I'm not really sure if this is the most ideal way to do things though, but it does appear to work fine, at least Halo 3 does detect the profiles with state > 0 fine.
TODO: look into changing up xam_content to make use of user_index & profiles.
It shouldn't be too difficult now to emulate the same content paths X360 uses (seperating content by XUID etc)
Would probably be a good idea, since it'd probably be needed for us to support multiple profiles properly, so that they don't all share savegames etc...
This removes the user_index == 0 requirement from the InputSystem code, and updates WinKeyInputDriver to use the first non-connected user index if it can.
Eg. if you had 2 XInput controllers plugged in, those two will take up user index 0 and 1, and keyboard will take user index 2.
If all four indexes are taken up already, the WinKey driver will be disabled.
(This is done by passing already-setup drivers to each drivers Setup function: since WinKey is the last to be setup, this'll let it query the XInput driver and find which user_index it should handle)
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.
Tried setting a uint64 setting to -1 (FFFF FFFF FFFF FFFF), which made it throw a out of range exception when loading the toml...
Internally it uses int64 to parse numbers, so I guess it doesn't work well with converting to uint64?
Changing everything from uint64->int64 seems to solve it though, now -1 works fine.
emoose