New 'onClientControl' Event to Detect Player Controls

[wassmas]

Is your feature request related to a problem? Please describe.

I'm always frustrated when I need to detect specific player actions like walking, firing, or jumping in MTA . While we can detect key presses using onClientKey, there's no built-in event that triggers when a player performs a control action, such as walking or firing. This makes it difficult to create advanced gameplay mechanics where controls need to be monitored or canceled dynamically, such as in custom game modes or specialized scripts.

Describe the solution you'd like

I would like to propose the addition of a new event called onClientControl. This event would trigger whenever a player performs a control action, such as moving, jumping, firing, or entering a vehicle. It would provide parameters to identify the control being used and whether the action is being pressed or released. Additionally, the event should be cancelable using cancelEvent, allowing developers to prevent certain actions dynamically based on gameplay logic.

Describe alternatives you've considered

I've considered using onClientKey to detect when specific keys are pressed, but this approach doesn't cover all control actions, especially those mapped to non-keyboard inputs (e.g., game controllers or default MTA controls). Another alternative is to use onClientRender to manually monitor player states, but this is inefficient and more complex to implement. Neither of these alternatives provides the flexibility or simplicity that a dedicated onClientControl event would offer.

Additional context

The onClientControl event could be similar in structure to onClientKey, but it would specifically target control actions rather than raw key presses. This would significantly enhance scripting capabilities by allowing developers to monitor and modify gameplay behaviors more intuitively. If implemented, it could open up new possibilities for creating immersive and responsive game modes.

Security Policy

• [X] I have read and understood the Security Policy and this issue is not about a cheat or security vulnerability.

[TracerDS]

what about getPedTask?

[MegadreamsBE]

what about getPedTask?

On that note, onClientPedTaskChange could be a nice event. However, there's a lot of work left to be done with the task system to get to an event like this. In all fairness though, it won't necessarily capture all available controls as not all of them cause a change in the underlying task.

[wassmas]

what about getPedTask?

getPedTask is indeed a useful function for determining the current task a player is performing. However, it has limitations when compared to a dedicated onClientControl event:

1. Task Detection Granularity: getPedTask is more suited for checking broad tasks like "walking" or "driving" but doesn't offer real-time detection of specific control inputs (e.g., when a player starts moving forward or starts firing). A dedicated onClientControl event would allow for immediate and fine-grained detection of any control action.

2. Real-time Response: getPedTask requires manual checking, which usually happens in a loop or with onClientRender, leading to less efficient or delayed responses to player actions. An event-based system like onClientControl would trigger immediately when a control is used, allowing for more responsive and efficient gameplay mechanics.

3. Cancelable Actions: With getPedTask, there's no straightforward way to cancel an action once detected. An onClientControl event could provide the ability to use cancelEvent, allowing for immediate prevention of specific player actions, which is crucial for custom gameplay rules or restrictions.

While getPedTask has its use cases, it doesn't fully address the need for real-time, cancelable, and fine-grained control detection that an onClientControl event would offer.

[TracerDS]

what about getPedTask?

getPedTask is indeed a useful function for determining the current task a player is performing. However, it has limitations when compared to a dedicated onClientControl event:

1. Task Detection Granularity: getPedTask is more suited for checking broad tasks like "walking" or "driving" but doesn't offer real-time detection of specific control inputs (e.g., when a player starts moving forward or starts firing). A dedicated onClientControl event would allow for immediate and fine-grained detection of any control action.
2. Real-time Response: getPedTask requires manual checking, which usually happens in a loop or with onClientRender, leading to less efficient or delayed responses to player actions. An event-based system like onClientControl would trigger immediately when a control is used, allowing for more responsive and efficient gameplay mechanics.
3. Cancelable Actions: With getPedTask, there's no straightforward way to cancel an action once detected. An onClientControl event could provide the ability to use cancelEvent, allowing for immediate prevention of specific player actions, which is crucial for custom gameplay rules or restrictions.

While getPedTask has its use cases, it doesn't fully address the need for real-time, cancelable, and fine-grained control detection that an onClientControl event would offer.

looks like gpt generated

That would very quickly spam events. onClientRender + getPedTask sounds overwhelming at first but it really isnt.

[wassmas]

~looks like gpt generated~

That would very quickly spam events. onClientRender + getPedTask sounds overwhelming at first but it really isnt.

I see your point, but the goal of onClientControl is to streamline detection without the constant checks needed by onClientRender + getPedTask. It could reduce overhead by triggering only when necessary, avoiding unnecessary processing.

And yes, I used GPT to help with my English—just trying to communicate better!

[wimpy5461]

This event useful