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.
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
Stubs: DmGetXbeInfo, DmIsDebuggerPresent, DmRegisterCommandProcessor, DmRegisterCommandProcessorEx
This helps progress some debug builds of games, DmGetXboxName error codes are based on what some games seem to expect from it.
Will probably be a good idea to move most of this to xbdm_info.cc soon.
Couldn't find a way to get bitfields & byte-swapping to play well together, so this was the best I could come up with... at least the proper version numbers will show in the log file now :)
This should be safe to do hopefully, most errors happen before any part of the XEX is modified, and the errors that can happen after modification should be very rare/impossible thanks to the earlier checks.
It might be good to write up some way to revert any changes though...
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!)
emoose