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.
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!)
threaded UI notifications from emoose Issue 1296
added fixups for hdd detection in more games (wheelman for example)
changed filter that stops notification spam
New cvar clock_source_raw allows to use the cpu cycle counter itself as an alternative time source, if system timing resolution is to low and causes problems.
- Removed tick and time values from ThreadSavedState.
- Removed affiliated get/set code from Save and Restore.
- Removed dangerous SetGuestTickCount method.
This fixes cases introduced by 52e836d0f81e752ba368717e68773b591adfa9cf
where thread handles get closed before the thread finishes.
Handle was assumed to be alive there, which was not true as
threads self-referenced only their objects, not their handles.
Affected games: Payday 2 Demo
Although this seems counter-intuitive, operating on handle
reference counters in
- ObLookupThreadByThreadId
- ObReferenceObjectByHandle
- ObDereferenceObject
allows to cleanly clean up handles for resources created elsewhere
and destructed by ObDereferenceObject (for example, threads with 0x80
creation flag). Operating on pointer reference counters alone
would leave a stray handle in the slots list.
Closing the thread handle should delete the thread object
if it's finished. When this handle was retained, closing the handle
left a lingering handle reference and thus this XThread would leak
By default imgui saves an INI file named 'imgui.ini' to the current directory,
which is undesired behavior. Until we can properly specify a full path to
a good location, disable saving of the INI file.
- Font atlas is now owned by context.
- Switch from deprecated io.RenderDrawListsFn callback to dedicated call in window.cc.
- Replaced deprecated ImGuiCol_ModalWindowDarkening with ImGuiCol_ModalWindowDimBg.
- Replaced deprecated SetScrollHere() with SetScrollHereY().
- Replaced deprecated GetContentRegionAvailWidth() with GetContentRegionAvail().x.
- Replaced deprecated ShowTestWindow() with ShowDemoWindow().
- Replaced deprecated ImGuiCol_ChildWindowBg with ImGuiCol_ChildBg.
- Replaced deprecated SetNextTreeNodeOpen() with SetNextItemOpen().
Changes NtAllocateVirtualMemory so that it ignores specified page size when a
base address is specified. Requires verification if this is desired behavior.
Now properly takes a global lock when populating guest_trampoline_map_
as opposed to taking and immediately releasing it
Also removes a redundant find() from guest_trampoline_map_
so map is not searched twice if the function has already been generated.
- [Kernel] Rename game_language cvar to user_language.
- [Kernel] Recategorize user_language to XConfig.
- [Kernel] Add user_country cvar, used instead of hardcoded value in XConfig.
- [XAM] Use user_country cvar for xeXamGetLocaleEx instead of
xeExGetXConfigSetting.
[Kernel] Make XexUnloadImage fully release the image
Previously XexUnloadImage did not cleanup the image fully,
and if XexLoadImage was to be called again on the same module,
it was not initialized fully, leading to a crash when using it.
[Kernel] (Partially) fix module refcounting
.xex module handles were retained twice in several places,
possibly causing them to leak.
More placed may have to be fixed too.
[Kernel] Fix SHA1 and SHA256 state endianness
Fixes malfunctioning SHA256 hash,
corrupting its state between Update and Finish calls.
crypt-fixes (#1461)
Previously XexUnloadImage did not cleanup the image fully,
and if XexLoadImage was to be called again on the same module,
it was not initialized fully, leading to a crash when using it.
emoose