Target Platform:
Cross-Platform
Targeted Release Version:
Stream-Pi Version 1.1.0
Is this a Bug-Fix, Feature Request, or, Other?:
Feature Request
What Platforms (Operating Systems) Were Used?:
(Host) Server - Not Applicable
(Guest) Client - Not Applicable
Describe the Issue:
The core function of this action would be for the user to set the position of their cursor immediately upon activation of action via their Stream-Pi interface. The target position would be defined by it's X-Coordinate & Y-Coordinate on your screen, with no limitation on exactly where the cursor can be located so as to allow us to support desktop setups with more than one display, and, with unusual aspect ratios. This includes the ability to set a negative X-Coordinate or Y-Coordinate, with conceivably ANY value being a possibility.
Because Stream-Pi is at it's core a advanced macro-pad interface some considerations would have to be made in regards to ensuring that use of this particular action would not trigger Anti-Cheat mechanisms within games even if you are not targeting the game when using this particular action.
Many current Anti-Cheat methods rely on kernel-level monitoring and modification of your system to ensure that you are not using cheats, unfortunately because of this flawed method of implementing Anti-Cheat into game Stream-Pi is left exposed, with the potential for some games to class it's usage as cheating even when that is proven to be undeniably false.
This action would have the option like any other action to be combined together to set off a string of event's, doing so would allow you to activate a part of the interface on the screen regardless of what you're doing or where your cursor is currently located. A method to "go back" to the cursors original starting location would be needed to allow for such a feature to be implemented in a organic & dynamic manner.
What Solution('s) do you suggest in regards to this Issue?:
This new action would rely on multiple elements to ensure it's smooth integration and operation at all time's.
The primary focus would be to do the following;
1.) Ensure that the target location is always correct prior to activation of the action.
2.) To log the precise current location of the cursor prior to the activation of the action.
3.) To ensure that the target location is not where the cursor already is.
4.) Prevent the action from being detected by Anti-Cheat mechanisms via the use of randomisation methods.
5.) To ensure immediate activation of the action with no delay and for the action to be undertaken in less than 500ms for the total action process time-span.
One of the most critical elements in regards to this action is prevent detection by or activation of Anti-Cheat mechanisms due to their overzealous implementations. To do this I suggest that a element of controlled randomisation is added to every part of the movement of the cursor during the actions "in-use" period, and that would be achieved by doing the following;
1.) Upon initial activation of the action the cursors CURRENT LOCATION would be logged and saved to a temporary file that would be created either in Disk Cache or in RAM (whichever option is quicker and less time consuming).
2.) After that process of the action has completed the next part would start which would be moving the cursor to the pre-defined location on your screen, during the process of movement their would be two additional parameters that would be applied, each with a controllable level of "Randomness" to their respective behaviour.
The first parameter would be cursor acceleration & deceleration, the second parameter would be "Cursor Curve", which is the amount of arc/curve that the cursor exhibits as it moves to the target location, each parameter would have a value between 0-10 which would control how "Random" the action is, and, how much it varies before reaching the same target destination every time.
3.) The final destination of the cursor at it's target location would NEVER be the same upon every activation of the action. The target destination would also have an element of randomisation as to exactly where it lands around the pre-defined position, this would vary with a "Randomisation" value of 1-10 like the other parameters and it would need to be adjusted so that it can still activate the button on the screen beneath the cursor if that is something that you wish to do with the action. The key part here is to ensure that the cursor never lands in the same location twice in a row, and, it always has an element of "jitters" to it as it centres on the target destination.
4.) If you have enabled the toggle to "Return the cursor to it's starting destination", then the same behaviours mentioned in sections 2 & 3 above would also be replicated here with the same randomisation to their behaviour, this is all done to ensure that no Anti-Cheat mechanism is triggered by Stream-Pi when the action is used.
Who was the Issue initially reported by?:
TOGLK - Stream-Pi Lead Tester & Auditor
Do you have concerns about the details of this GitHub Issue?
If you do then please comment below, Or, Contact me directly via GitHub/Discord/Element.io
Contact Details:
Discord - TOGLK
Element.io (Matrix) - TOGLK
GitHub - TOGLK
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent