playcover / playtools

Tools for keymapping, dynamic resolution, and more

‎

PlayCover

Run iOS apps and games on Apple Silicon Macs with mouse, keyboard and controller support.

Documentation · Discord · Website

About The Project

Welcome to PlayCover! This software is all about allowing you to run iOS apps and games on Apple Silicon devices running macOS 12.0 or newer.

PlayCover works by putting applications through a wrapper which imitates an iPad. This allows the apps to run natively and perform very well.

PlayCover also allows you to map custom touch controls to keyboard, which is not possible in alternative sideloading methods such as Sideloadly.

These controls include all the essentials, from WASD, camera movement, left and right clicks, and individual keymapping, similar to a popular Android emulator’s keymapping system called Bluestacks.

This software was originally designed to run Genshin Impact on your Apple Silicon device, but it can now run a wide range of applications. Unfortunately, not all games are supported, and some may have bugs.

Localisations handled in Weblate.

⬆️ Back to top️

Getting Started

Follow the instructions below to get Genshin Impact, and many other games, up and running in no time.

Prerequisites

At the moment, PlayCover can only run on Apple Silicon Macs. Devices with the following chips are supported:

• M1
• M1 Pro
• M1 Max
• M1 Ultra
• M2
• M2 Pro
• M2 Max
• M2 Ultra
• M3
• M3 Pro
• M3 Max

If you have an Intel Mac, you can explore alternatives like Bootcamp or emulators.

Download

You can download stable releases here, or build from source by following the instructions in the Documentation.

Documentation

To learn how to setup and use PlayCover, visit the documentation here.

Homebrew Cask

We host a Homebrew tap with the PlayCover cask. To install from it run:

brew install --cask PlayCover/playcover/playcover-community

To uninstall:

1. Remove PlayCover using brew uninstall --cask playcover-community;
2. Untap PlayCover/playcover with brew untap PlayCover/playcover.

⬆️ Back to top️

License

Distributed under the GPLv3 License. See LICENSE for more information.

Contact

Lucas Lee - [email protected]

Depal - [email protected]

Libraries Used

These open source libraries were used to create this project.

• inject

• PTFakeTouch

• DownloadManager

• DataCache

• SwiftUI CachedAsyncImage

• Thanks to @iVoider for creating such a great project!

⬆️ Back to top️

playtools's Issues

[Bug]: anomalous Mouse Button behavior

Describe the bug

See for yourself

When choosing the circle mouse button, it works as expected. You can create an 'empty' mouse circle to control the camera movements. When you select the circle mouse button and press a key, you can bind it to a key to create a button that lets you drag the camera around when the button is held.

On the other hand, when you create a rounded square mouse button, you can also use it to control the camera movement, but if you try to bind this button to any key, it will somehow create a WASD directional button

I'm pretty sure this is a bug and not a feature. And that the rounded square mouse button is supposed to behave the same or similar as the circle one.

Steps to reproduce

1. Open Keymap Editor
2. Create a rounded square mouse button
3. Select this button
4. Press any key and it will turn the button into a directional pad

Expected behaviour

Same behavior as the circle mouse button i think?

Crash log

no crash

What version of PlayCover are you using?

Nightly/beta

What version of macOS are you using?

Ventura (macOS 13)

Issue Language

• Yes my issue is written in English

[Bug]: Unable to adjust app window size Honkai Impact 3rd PlayCover 2.0.2

Describe the bug

After setting the resolution and window size of the app in Playcover, the app windows size isn't same as the setting when open it.

For example :
in playcover resolution settings : 1080p 16:9 and the real application window size isn't a 16:9. (see as the image)

honkai version: v6.3
ipa link : https://decrypt.day/app/id1233055283

Steps to reproduce

Right click "preference" in playcover of the Honkai Impact App.
Jump to the graphic setting tag, select the resolution as 1080 and size 16:9.
quit the playcover an reopen it, open the Honkai impact 3rd app.

Expected behaviour

It should be the same size as genshin's window show.

see as image :

Crash log

No response

What version of PlayCover are you using?

2.0.2

What version of macOS are you using?

Ventura (macOS 13)

Issue Language

• Yes my issue is written in English

[Feature]: multi-dimensional keymapping

Is your feature request related to a problem?

Example game: Genshin Impact

Current problems/limitations: the existing keymap is strictly static and 2-dimensional, as in you can interact with it in x- and y- dimensions such as by placing buttons relative to the x- and y- axis of the window. Now this is great and a straightforward solution to emulating touch input from an actual touchscreen device, however, this also significantly constrains ease of use due to the buttons being static on a single layer of the keymap and being fixed a single x,y coordinate.

Impacts to the gameplay experience: Games have dynamic interface elements, often in different menus. The inherent limitation with a 2D static keymap is you will have to constantly toggle the cursor to properly select menu items that may be significantly different from each other depending on the context.

Existing workarounds/attempted fixes:
A way I've tried to solve the aforementioned issues is adding additional buttons in the keymap to account for the more consistent menu elements, but the limitations of this is that the user will have to memorize all the extra keys and which UI element it corresponds to. Alternatively, I've tried mapping the same key input to multiple different locations, but this comes with its own problems such as when you press the key it disables camera control, possibly due to the game recognizing this action as an attempt to zoom in or out.

Describe the solution you'd like

Proposed solution: add a 3rd z-dimension to the keymapping editor and keymapping interaction to allow for the existence of multi-layer keymaps where specific keys can trigger contextual buttons on a separate layer that do not conflict with any other buttons of the same key value on other layers. Additionally, allow for the addition of multiple contextual layer exit trigger keys, which when any valid keys are pressed will return to the 'base' keymapping layer. The different layers can also be cycled through via specific keyboard shortcuts without having to press specific trigger keys. One layer created on top of the base layer can also nest its own layers to cover more diverse in-game menus, pop-ups, etc. On top of having certain keys that can exit the contextual layer, maybe it can also be based on a set number of mouse clicks that will return to the base layer and enable keymapping/hide cursor.

Scenario A: Domain menu
F can be mapped as a trigger key to activate another keymap layer (or another key to avoid potential issues). When the player presses this to see the domain menu, X and esc will now be mapped to the button on the top right corner, i will mapped to the domain details button below it, LMB can be mapped to the co-op matching button at the bottom right, and RMB can be mapped to the start button. These keys can be mapped as trigger keys that exit the contextual keymap layer or serve as triggers for more layers. Additionally, numbers 1 to 4 can be mapped as non-trigger keys so the player can select different domain levels. This solves the need to use the cursor each time as well as the need to implement numerous additional buttons on a single keymap layer to account for all this, coding the keys to match their UI element names will also be more intuitive to use.

Let's say for example the user presses LMB to use matchmaking, this key can trigger another layer on top of the previous one, where the user can now press layer exit keys: LMB or esc to cancel or RMB to confirm. These keys can be individually set to exit to the base layer or another layer. If the user cancels, it should return to the prev layer, if confirms, should return to the base layer as they will enter a co-op instance and normal exploration/combat controls will now be on screen.

Scenario B: quest menu
Here on a separate layer from the base, N can be mapped to the navigate button (which could also be the pointer navigation key on the base layer), and S can be for the story quests button. And of course X and/or esc to exit and return to base layer.

Scenario C: instrument gadgets
Another key such as i can be mapped on the base keymap layer in addition to G or Z (this is to prevent issues/make distinction between using regular gadgets vs. instrument gadgets that bring up a whole new screen with note buttons). In this layer, the PC equivalent controls can be better emulated by binding Q to U to the top row of instrument buttons, A to J to the middle, and Z to M to the bottom. To restore base layer controls, the user in this case can press esc as the trigger key.

Anything else?

I've not yet thought about how this might actually look to the user. Perhaps another feature such as visible keymap hints should exist in conjunction with a multi-layered keymapping system to make things less obscure.

For layer exit keys that return to the previous or base layer, maybe it can also be triggered by a set amount of mouse clicks that will automatically lock keymapping

Maybe it could work and look something like this:

Some potential problems and limitations with this solution is that multiple different keys may have to be mapped to the main engage interaction "F key" area. Since the same key position is also used to pick up drops (though this can be changed to a different location to pick up all drops), and interact with certain things like open treasure chest, talk to NPCs. Another thing is that the keymap layer may go out of sync for unpredictable in-game scenarios that disrupt the typical sequential nature of interactions, one example is in Genshin co-op you could be using the musical instrument layer, but a teammate triggers nearby combat (or use Albedo's pedestal) which cancels you out of the instrument screen. In this case the layer will be out of sync because it cannot restore itself to the base layer. Some ways around this would be to press keyboard shortcuts (maybe cmd + 1 to 9) to quickly switch between layers, and have the keymap hint UI active with the layer exit keys better differentiated in terms of visuals so in case something like this happens the user can manually press the exit key to restore normal combat/movement keymaps. I think having on-screen keymap hints would be vital to this feature and probably should be implemented prior or in-tandem to this.

Issue Language

• Yes my issue is written in English

After Sonia 14.1, PlayTools needs another way to change frame.

In PlayTools/Controls/PTFakeTouch/NSObject+Swizzle.m

[objc_getClass("FBSSceneSettings") swizzleInstanceMethod:@selector(frame) withMethod:@selector(hook_frameDefault)];
[objc_getClass("FBSSceneSettings") swizzleInstanceMethod:@selector(frame) withMethod:@selector(hook_frame)];

These methods make app crash.
I guess there is something changed in FrontBoardServices structure.
If I comment out these methods, PlayTools works but cannot change frame obviously.

/* Generated by RuntimeBrowser in Sonoma 14.1 betas
   Image: /System/Library/PrivateFrameworks/FrontBoardServices.framework/Versions/A/FrontBoardServices
 */

@interface FBSSceneSettings : FBSSettings <FBSSceneSettings, NSCopying, NSMutableCopying> {
    NSSet * _ignoreOcclusionReasons;
}

@property (nonatomic, readwrite) BOOL activityMode;
@property (getter=isBackgrounded, nonatomic, readonly) BOOL backgrounded;
@property (getter=isClientFuture, nonatomic, readwrite) BOOL clientFuture;
@property (nonatomic, readonly, copy) FBSDisplayConfiguration *displayConfiguration;
@property (nonatomic, readonly, copy) FBSDisplayIdentity *displayIdentity;
@property (getter=isForeground, nonatomic, readonly) BOOL foreground;
@property (nonatomic, readonly) struct CGRect { struct CGPoint { double x_1_1_1; double x_1_1_2; } x1; struct CGSize { double x_2_1_1; double x_2_1_2; } x2; } frame;
@property (nonatomic, readonly) long long interfaceOrientation;
@property (nonatomic, readonly) long long interruptionPolicy;
@property (nonatomic, readwrite) BOOL jetsamMode;
@property (nonatomic, readonly) double level;
@property (getter=isOccluded, nonatomic, readwrite) BOOL occluded;
@property (nonatomic, readwrite) BOOL prefersProcessTaskSuspensionWhileSceneForeground;

+ (Class)_baseClass;
+ (Class)_diffClass;
+ (Class)_mutableClass;
+ (id)_settingsExtensionsForSceneExtension:(Class)arg1;
+ (id)settings;
+ (Class)subclassExtension;

- (void).cxx_destruct;
- (void)_appendToDescriptionBuilder:(id)arg1;
- (BOOL)_hasAdditionalDescription;
- (BOOL)_isEmptyForCoding:(BOOL)arg1;
- (BOOL)_isEqualToSettings:(id)arg1;
- (struct CGRect { struct CGPoint { double x_1_1_1; double x_1_1_2; } x1; struct CGSize { double x_2_1_1; double x_2_1_2; } x2; })bounds;
- (id)displayIdentity;
- (id)ignoreOcclusionReasons;
- (id)initWithSettings:(id)arg1;
- (BOOL)isBackgrounded;
- (BOOL)isIgnoringOcclusions;
- (id)transientLocalSettings;

@end

@interface FBSSceneSettingsCore : FBSCoreSettingsExtension <FBSSceneSettings>

@property (nonatomic, readwrite) BOOL activityMode;
@property (getter=isClientFuture, nonatomic, readwrite) BOOL clientFuture;
@property (nonatomic, readwrite, copy) FBSDisplayConfiguration *displayConfiguration;
@property (getter=isForeground, nonatomic, readwrite) BOOL foreground;
@property (nonatomic, readwrite) struct CGRect { struct CGPoint { double x_1_1_1; double x_1_1_2; } x1; struct CGSize { double x_2_1_1; double x_2_1_2; } x2; } frame;
@property (nonatomic, readwrite) long long interfaceOrientation;
@property (nonatomic, readwrite) long long interruptionPolicy;
@property (nonatomic, readwrite) BOOL jetsamMode;
@property (nonatomic, readwrite) double level;
@property (getter=isOccluded, nonatomic, readwrite) BOOL occluded;
@property (nonatomic, readwrite) BOOL prefersProcessTaskSuspensionWhileSceneForeground;

+ (id)descriptionOfValue:(id)arg1 forSetting:(id)arg2;
+ (id)protocol;

- (BOOL)activityMode;
- (id)displayConfiguration;
- (struct CGRect { struct CGPoint { double x_1_1_1; double x_1_1_2; } x1; struct CGSize { double x_2_1_1; double x_2_1_2; } x2; })frame;
- (void)frame:(struct CGRect { struct CGPoint { double x_1_1_1; double x_1_1_2; } x1; struct CGSize { double x_2_1_1; double x_2_1_2; } x2; })arg1;
- (long long)interfaceOrientation;
- (long long)interruptionPolicy;
- (BOOL)isClientFuture;
- (BOOL)isForeground;
- (BOOL)isOccluded;
- (BOOL)jetsamMode;
- (double)level;
- (BOOL)prefersProcessTaskSuspensionWhileSceneForeground;
- (void)setActivityMode:(BOOL)arg1;
- (void)setClientFuture:(BOOL)arg1;
- (void)setDisplayConfiguration:(id)arg1;
- (void)setForeground:(BOOL)arg1;
- (void)setInterfaceOrientation:(long long)arg1;
- (void)setInterruptionPolicy:(long long)arg1;
- (void)setJetsamMode:(BOOL)arg1;
- (void)setLevel:(double)arg1;
- (void)setOccluded:(BOOL)arg1;
- (void)setPrefersProcessTaskSuspensionWhileSceneForeground:(BOOL)arg1;

@end

[Bug]: 'rounded square' mouse input anomaly

Describe the bug

exactly as the title says, here are some of the strange, abnormal behaviour i observed when playing around with this rounded square mouse area input in genshin impact, see below for some of the scenarios i tested

software versions:

• playcover: 2.0.4 (233)
• macOS 13.2

hardware configuration:

• M1 macbook air, 8GM RAM, 7 core GPU
• built-in trackpad mouse input

playcover/genshin settings:

• m1 iPad identifier
• auto resolution (1440x900)
• in-game settings set to all highest with 60fps cap
• low power mode is not enabled

single rounded square mouse input

observation: works as you'd expect from the circle mouse input at first glance, but as you start to play the game, things start to get weird. if you teleport to a waypoint or use a 5 star character's elemental burst, the input becomes unresponsive afterwards. A way to restore input and be able to pan the camera again is to open/close keymap editor (cmd + k) or release/lock keymapping (via option key). Restarting the game has the same effect, until it breaks again after u use a teleporter or burst

two rounded square mouse input

observation: even more broken than having just one, you get the same issue as the previous and more! If you try to walk your character with this setup and pan the camera while walking, the WASD keys will get stuck, or sometimes will randomly zoom the camera in and out as you press the dpad keys while moving the mouse cursor.

also, if you try to revert this wacky keymap configuration, like by deleting both of them and restoring the single circle mouse input, the bug will still somehow linger around with the exact symptoms as if they didnt get deleted at all, only after a restart will it start working normally again with the single circle mouse input

one circle mouse input + one rounded square mouse input

observation: if you try to pan the camera, there's a massive input lag and it doesnt even pan properly, try sliding your finger around on the trackpad, its kinda funny. If you delete the rounded square input, camera will no longer pan at all anymore and will only zoom in and out. Can be only fixed with a restart after deleting it and leaving a single circle mouse input behind, simply removing the rounded square does not properly fix it

two circle mouse input

observation: could not find any faults in having 2 of these in the keymap, at least for now

not sure if this is an issue on other games too, maybe i'll test later in honkai impact

Steps to reproduce

its in the bug description

Expected behaviour

probably not this kind of behavior

Crash log

no crash

What version of PlayCover are you using?

2.0.3

What version of macOS are you using?

Ventura (macOS 13)

Issue Language

• Yes my issue is written in English

[enhancement] Support mapping buttons from usb/bluetooth controllers

https://github.com/dirkwhoffmann/vAmiga/blob/7de0d51f0fa1860c367b352004a9fbe1f100cd00/GUI/Peripherals/GamePad.swift#L308

After updating to macOS Sonoma key mapping commands like command k and option dont work

The key mapping itself works but you can't toggle it on and off
(when you enter the game once you save the keymapping)

keymapping unusual behaviour

when I press opt, the key mapping can't work properly. I then try cmd+K to edit key mapping but can't close the editing page with cmd+K. then I try to close key mapping editing with the top bar and after that I can't find my mouse and can only click the mouse button.

v2.0.2 may introduced some bug which causes game FPS reduced drastically

Origin issue PlayCover/PlayCover#573
Comparing PlayCover's build log of Build nightly release #168 to Build nightly release #167, PlayTools "v2.0.2" is checked out and linked in the newer versions of PlayCover (while PlayTools "v2.0.1" in the older).
I downloaded the newest PlayCover:develop source code, modified Cartfile to require exactly version 2.0.1 of PlayTools, then compiled PlayCover.app locally. The PlayCover.app worked as well as "nightly release #167".
If the newest PlayCover:develop source code was compiled directly and it required version 2.0.2 of PlayTools, the PlayCover.app worked the same as "nightly release #167", resulting FPS reduced.
@IsaacMarovitz , would you please take a look at that problem? Thanks a lot.

[Feature]: Improvements on import/export keymapping

Is your feature request related to a problem?

Some games like Infinite Blade series or Noah's Heart only works via Sideloadly, and with PlayTools injected it is a life-saving tool to control the game without the controller.

But the keymap will be deleted after closing the app and the players like me must take about 5 to 15 mins to setup keymapping before we can control the game.

Describe the solution you'd like

So I think that how can we make Playtools can import/export keymapping directly on the menu bar for Sideloadly games. That will be a great improvement

Anything else?

(just the keymap improvement request)

Issue Language

• Yes my issue is written in English

[Feature] Fake Touch at cursor Location when a specific Keyboard Key is pressed

Is your feature request related to a problem?

Yes, On some games like RL Sideswipe when we try to mouse click on some buttons or UI elements in the game interface. It makes the UI crash.
Issue already described here PlayCover/PlayCover#401 by @amirsaam

However it does not crash when we do a Touch tap. We can do that using Apple's "Touch Alternative settings" but it's very annoying, since you don't know where you tap, you have to guess and try many times. and if you fail at guessing it can click on some other element...

To overcome this I created a Keymap just to navigate in the menu and interface of RL sideswipe.

Describe the solution you'd like

Fake Touch on Mouse Location when we tap a specific key for instance 'n'.

When the user press 'n' we trigger a FakeTouch on the current location of the cursor.
We would have a settings for enabling this.

This would make the keymap I created Useless and with the addition of Playchain and #88 the support of RL sideswipe would be absolutely complete!

Anything else?

I actually already implemented a quick and Dirty version of this on top of @XuYicong work on #88 and it works well, I use it.

The code looks like this:

    func fakeTouchOnCursorLocation(pressed: Bool) {
        guard let cursorLocation = PlayMice.shared.cursorPos() else {
            return
        }
        debugPrint(cursorLocation)
        
        PlayInput.touchQueue.async(qos: .userInteractive) {
            Toucher.touchcam(point: cursorLocation, phase: pressed ? .began : .ended, tid: &self.cacheTidForFakeTouchOnCursor)
        }
    }

lastMove@a6275b5

I don't know if it would be useful for other games though.

Issue Language

Yes my issue is written in English

[Feature]: Support for modifier key combinations

Is your feature request related to a problem?

You can only do so much with the standard single key values that can be mappped to a single point on screen.

Describe the solution you'd like

Support for modifier key combinations such as ctrl ⌃ + <key>, this would allow an extra dimension of functionality to be added and account for certain in-game UI elements that would otherwise have to be mapped to an inconvenient key value or not mapped at all.

For example, everyone's fav game: Genshin Impact

There is currently no convenient way to activate the button that switches to a character AND uses their element burst. You can try releasing the cursor to do it but this is unrealistic given how you need to react fast to changing conditions in combat. Or you can try to map it to another key but there's no convenient option within reach.

With my proposed solution, this problem can be solved since users will be able to map something like ctrl + 1, 2, or 3 to a button that presses on the off field char's elemental burst to switch them in. Another benefit is you could map some other common UI elements to ctrl, such as ctrl + E for the events page, ctrl + B for BP, and so on-without having to deal with those pesky F keys that nobody wants to press on a Mac.

Anything else?

Could look something like this (combined with on-screen keymap hint UI concept - #74)

Issue Language

• Yes my issue is written in English

[Bug]: MacOS Beta 13.2 offset window display in some Mac Catalyst apps

Describe the bug

Only half of the software window can be displayed

Steps to reproduce

Open Genshin Impact and it will display

Expected behaviour

Fix it and make it normal

Crash log

No response

What version of PlayCover are you using?

Nightly/beta

What version of macOS are you using?

Ventura (macOS 13)

Issue Language

• Yes my issue is written in English

[Feature]: moving keymapping elements using arrow keys

Is your feature request related to a problem?

yes, minor issue

its hard for the user to place WASD keymap input over in-game joystick with good precision, often you're off by a few pixels and the joystick ends up looking janky when you press on it

Describe the solution you'd like

• change the keyboard shortcut for upsize/downsize selected keymap element from cmd + up arrow and cmd + down arrow -> cmd + + and cmd + -
• implement move selected element controls, movable in small increments (1px?) by cmd + directional arrow keys

Anything else?

nothing for now

Issue Language

• Yes my issue is written in English

t

t

[Feature]: support for redundant keymaps

Is your feature request related to a problem?

idk

Describe the solution you'd like

able to map the same key to multiple positions without the keymap behaving oddly

iirc on newer versions (2.0.0+) there's some kinda issue and on older (1.1.1) it just doesn't work

Anything else?

not at the moment

Issue Language

• Yes my issue is written in English

[Enhancement/Bug] Don't crash if a BT controller is active and the current app uses keymapping

Currently whenever a supported bluetooth controller is connected (tested with a DS5) and the active application has Keymapping enabled it will crash in specialized static PlayController.handleEvent(_:_:) if any button or the touchpad are used.

Disabling Keymapping will fix this crash and allow the application to interact with or ignore the controller, however this isn't really documented anywhere and it would be nice if PlayTools would handle this case better and for example display an error about active keymapping + controller instead of crashing the app.

Tested with: PlayCover 3.0.0 (406), M2 MacBookAir, macOS 13.5 (22G74)

Steps to reproduce:

• right click any app in PlayCover
• open the settings and enable 'Keymapping'
• connect a supported bluetooth controller to your mac (I tested with a DS5)
• start the app
• once started press a few buttons on the controller / use the touchpad

Here's an excerpt of the interesting parts of crashing Honkay StarRail that way but it works in any application:

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               hkrpg [51244]
Path:                  /Users/USER/Library/Containers/io.playcover.PlayCover/Honkai: Star Rail.app/hkrpg
Identifier:            com.HoYoverse.hkrpgoversea
Version:               1.2.0 (3)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2023-07-26 19:25:19.3210 +0200
OS Version:            macOS 13.5 (22G74)
Report Version:        12

Time Awake Since Boot: 28000 seconds
Time Since Wake:       3359 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000090
Exception Codes:       0x0000000000000001, 0x0000000000000090

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [51244]

VM Region Info: 0x90 is not in any region.  Bytes before following region: 105553518919536
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      MALLOC_NANO (reserved)   600018000000-600020000000 [128.0M] rw-/rwx SM=NUL  ...(unallocated)

Kernel Triage:
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage
VM - (arg = 0x0) pmap_enter retried due to resource shortage


Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   UnityFramework                	       0x11a2976c4 0x1112e4000 + 150681284
1   UnityFramework                	       0x11a6769cc 0x1112e4000 + 154741196
2   UnityFramework                	       0x11a67311c 0x1112e4000 + 154726684
3   UnityFramework                	       0x11a673058 Unityplcrash_signal_handler + 24
4   libsystem_platform.dylib      	       0x197066a24 _sigtramp + 56
5   ???                           	0xffff800100eac1f0 ???
6   PlayTools                     	       0x100eac39c specialized static PlayController.handleEvent(_:_:) + 424
7   PlayTools                     	       0x100eaa220 thunk for @escaping @callee_guaranteed (@guaranteed GCExtendedGamepad, @guaranteed GCControllerElement) -> () + 80
8   libdispatch.dylib             	       0x196e86874 _dispatch_call_block_and_release + 32
9   libdispatch.dylib             	       0x196e88400 _dispatch_client_callout + 20
10  libdispatch.dylib             	       0x196e96bf8 _dispatch_main_queue_drain + 928
11  libdispatch.dylib             	       0x196e96848 _dispatch_main_queue_callback_4CF + 44
12  CoreFoundation                	       0x197157c54 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
13  CoreFoundation                	       0x1971153d4 __CFRunLoopRun + 1992
14  CoreFoundation                	       0x1971144b8 CFRunLoopRunSpecific + 612
15  HIToolbox                     	       0x1a0966df0 RunCurrentEventLoopInMode + 292
16  HIToolbox                     	       0x1a0966c2c ReceiveNextEventCommon + 648
17  HIToolbox                     	       0x1a0966984 _BlockUntilNextEventMatchingListInModeWithFilter + 76
18  AppKit                        	       0x19a33b97c _DPSNextEvent + 636
19  AppKit                        	       0x19a33ab18 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
20  AppKit                        	       0x19a32ef7c -[NSApplication run] + 464
21  AppKit                        	       0x19a3063cc NSApplicationMain + 880
22  AppKit                        	       0x19a55eb78 _NSApplicationMainWithInfoDictionary + 24
23  UIKitMacHelper                	       0x1ae78b960 UINSApplicationMain + 988
24  UIKitCore                     	       0x1c28c28e8 UIApplicationMain + 148
25  UnityFramework                	       0x1112fa8dc 0x1112e4000 + 92380
26  hkrpg                         	       0x1007c27b4 0x1007bc000 + 26548
27  dyld                          	       0x196cdff28 start + 2236

Thread 1:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 6:: com.apple.uikit.eventfetch-thread
0   libsystem_kernel.dylib        	       0x196ff7f54 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x19700a280 mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x197000bb8 mach_msg_overwrite + 604
3   libsystem_kernel.dylib        	       0x196ff82d0 mach_msg + 24
4   CoreFoundation                	       0x1971167e4 __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x1971150c4 __CFRunLoopRun + 1208
6   CoreFoundation                	       0x1971144b8 CFRunLoopRunSpecific + 612
7   Foundation                    	       0x19808dfbc -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8   Foundation                    	       0x198102384 -[NSRunLoop(NSRunLoop) runUntilDate:] + 100
9   UIKitCore                     	       0x1c28c3e04 -[UIEventFetcher threadMain] + 104
10  Foundation                    	       0x19808753c __NSThread__start__ + 716
11  libsystem_pthread.dylib       	       0x197037fa8 _pthread_start + 148
12  libsystem_pthread.dylib       	       0x197032da0 thread_start + 8

Thread 7:
0   libsystem_pthread.dylib       	       0x197032d8c start_wqthread + 0

Thread 8:: NIO-ELT-0-#0
0   libsystem_kernel.dylib        	       0x196ffe0a0 kevent + 8
1   PlayTools                     	       0x100ffda6c specialized static KQueue.kevent(kq:changelist:nchanges:eventlist:nevents:timeout:) + 56
2   PlayTools                     	       0x100fe827c specialized Selector.whenReady0(strategy:onLoopBegin:_:) + 412
3   PlayTools                     	       0x100fe4cb0 SelectableEventLoop.run() + 380
4   PlayTools                     	       0x100fc8fb8 closure #1 in static MultiThreadedEventLoopGroup.setupThreadAndEventLoop(name:parentGroup:selectorFactory:initializer:) + 328
5   PlayTools                     	       0x100fcc830 partial apply for closure #1 in static MultiThreadedEventLoopGroup.setupThreadAndEventLoop(name:parentGroup:selectorFactory:initializer:) + 36
6   PlayTools                     	       0x100fcea20 thunk for @escaping @callee_guaranteed (@guaranteed NIOThread) -> () + 24
7   PlayTools                     	       0x100fff478 closure #1 in static ThreadOpsPosix.run(handle:args:detachThread:) + 272
8   libsystem_pthread.dylib       	       0x197037fa8 _pthread_start + 148
9   libsystem_pthread.dylib       	       0x197032da0 thread_start + 8

Crash In staging-3.0.0 in playcover.toucher Queue

Hello,

I noticed a regression. There is a crash in the func touchcam(point: CGPoint, phase: UITouch.Phase, tid: inout Int?)

It happens to me, systematically after playing for a minute. it's an out of range error.
I ran it using gdb here are the logs:

Swift/ContiguousArrayBuffer.swift:613: Fatal error: Index out of range
2023-03-07 05:16:59.368651+0100 RL2DClient[56230:1628919] Swift/ContiguousArrayBuffer.swift:613: Fatal error: Index out of range
Process 56230 stopped
* thread #59, queue = 'playcover.toucher', stop reason = Fatal error: Index out of range
    frame #0: 0x00000001aee6cae8 libswiftCore.dylib`_swift_runtime_on_report
libswiftCore.dylib`:
->  0x1aee6cae8 <+0>: ret    

libswiftCore.dylib`:
    0x1aee6caec <+0>: b      0x1aee6cae8               ; _swift_runtime_on_report

libswiftCore.dylib`:
    0x1aee6caf0 <+0>: adrp   x8, 307987
    0x1aee6caf4 <+4>: ldrb   w0, [x8, #0x6fc]
Target 0: (RL2DClient) stopped.
Process 56230 launched: '/Users/jasonakakpo/Library/Containers/io.playcover.PlayCover/RL Sideswipe.app/RL2DClient' (arm64)
(lldb) exit

Looks to me that it related to this:

            let resultingId = PTFakeMetaTouch.fakeTouchId(pointId, at: point, with: phase, in: keyWindow, on: keyView)
            if resultingId < 0 {
                idMap[pointId] = nil
            } else {
                idMap[resultingId] = bigId
            }

PTFakeMetaTouch may returns an index > 64 which is the fixed size of the idMap array.
I guess this situation should not happen (we should not need more than 64 different IDs), but maybe we can fix it by using a [Int:Int] dictionary instead of the [Int?] array for idMap.

[Feature]: cursor release toggle mapped to any key

Is your feature request related to a problem?

No

Describe the solution you'd like

You know how you can press option to release the cursor whenever you want? Well what if there was a way to map certain keys to also do this cursor release behavior? The user benefit is that it would save you a press of the option key when you are interacting with certain in-game menus where you will end up pressing option after anyways. While this seems insignificant and trivial, one less key you need to press will add up over time and reduces redundant interactions.

Examples (Genshin):

• pressing J to open the quest menu, you're going to press option after opening this anyways to select a quest or choose navigation
• pressing M to open the world map, you're going to press option after to choose a teleporter or add a marker
• pressing C to open the character menu, you're going to press option after anyways to click on a character or weapon, artifacts, etc.
• pressing any of the keys mapped to the following menus: Events, BP, wishes, adventurer's handbook, bag/inventory
• you get the idea

Anything else?

How this might work in terms of UI/logic:

• imagine it as a new circle with a new icon added to the radial 'add keymap' menu in keymap editor, instead of 4 circles/options to choose from there's now 5
• like the other options, choosing it will allow you to map any key (except option, cmd, LMB, RMB, etc.)
• if the cursor is not currently released and any of the mapped cursor toggle keys are pressed, the cursor will be released
• press option to lock the cursor again as you normally would

Issue Language

• Yes my issue is written in English

[Feature]: On-screen keymapping hint UI

Is your feature request related to a problem?

I've seen many users asking in the discord why their keymapping is not working, surprisingly, they had no idea that pressing option is the key that toggles keymapping on/off. Furthermore, there are also issues related to various aspect ratios different users may have, such as 16:10 keymap on a 16:9 window. What if there was a way to solve all of this? To make the interactions more explicit? More obvious? You can't expect everyone to read the docs because the vast majority of people want an experience that 'just works' out of the box without having to read a hefty manual.

Describe the solution you'd like

I propose a visible layer UI layer that provide hints to assigned keymaps on-screen. Of course, not all keys might need the hint so perhaps in the editor there can be a checkbox where the user can choose to show or hide. And maybe even in the keymap editor the user can customize by dragging the hint 'buttons' to be relative to the actual touch position in up, down, left, and right offset positions, there are many cases where the hint would need to be offset from the actual touch location, mostly to make things look nice and prevent the hint from obscuring UI elements.

For example: when keymapping is not enabled/cursor released, there could be a hint on screen to tell the user that keymapping is currently disabled. Maybe it could show this hint once for first time users, or show every time the keymap is disabled (but might get annoying for users who are already familiar with the option key)

This is how I imagine this might look like

Keymapping hints for individual buttons can be toggled with a certain shortcut maybe cmd + H or something. They would show up below the keymap touch location, similar to how things are on the official PC version of Genshin Impact (though this feature can benefit many other games as well)

With this feature, the keymapping editor could look like this, when adding a new key a hint tag is automatically generated, and the user can click on the tag to drag it around the touch point circumference. Can also toggle to show or hide the hint by default.

Anything else?

This feature could work in tandem with multi-dimensional keymapping to further improve the PlayCover UX #72

Issue Language

• Yes my issue is written in English