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.
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
Gliniak