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.
GetTitleGpd should work fine for what we're using it for here... it could be a good idea to keep an instance of the current SpaFile of the running title and have a GetTitleSpa that returns that though, since I think some stuff like XamReadString might eventually need access to SPA data, not really sure yet though.
Disclaimer: On old dash it causes memleak (slight),
newer dashboards allocates them only once which is solution for that.
Ps. If anyone have easy solution please implement it. Cheers
emoose