Fixes #3160 - New onClientCommand event

[MohabCodeX]

Summary of Changes

Adds the onClientCommand event to MTA client-side logic, enabling Lua resources to intercept, inspect, and cancel client commands prior to local handler execution or server transmission. (Fixes #3160)

Motivation & Semantics

• Client vs. Server Semantics: Server-side commands can already be intercepted via onConsole and addCommandHandler logic. Previously, client-side commands executed locally or transmitted over the network without giving client resources an early interception hook.
• Goal: onClientCommand provides client-side parity, allowing resource event handlers to invoke cancelEvent() to block execution locally and prevent sending cancelled commands across the network to the server.

Testing & Verification

Client Lua:

Testing Script

addEventHandler("onClientCommand", root, function(command, ...)
    if command == "restricted" then
        cancelEvent() 
        outputChatBox("This command is disabled!", 255, 100, 100)
    end
end)

addEventHandler("onClientCommand", root, function(command, ...)
    local args = {...}
    local executedByFunction = args[#args]
    table.remove(args, #args) 
    
    local blockedCommands = {"run", "exec", "execute", "lua", "script"}
    for _, blocked in ipairs(blockedCommands) do
        if command == blocked then
            cancelEvent()
            triggerServerEvent("onPlayerUsedExecutor", localPlayer, command)
            return
        end
    end
    
    if not executedByFunction then
        local currentTime = getTickCount()
        if currentTime - (lastCommandTime or 0) < 100 then
            triggerServerEvent("onPlayerUsedExecutor", localPlayer, "rapid_execution")
        end
        lastCommandTime = currentTime
    end
end)

</details>

[Copilot]

Pull request overview

This PR introduces a new client-side onClientCommand event intended to let scripts observe and potentially cancel command execution, and adjusts command handling on both client and server to better report/propagate “unknown command” cases.

Changes:

• Adds the onClientCommand built-in client event and invokes it during client command execution flow.
• Refactors client registered-command execution to return a CommandExecutionResult instead of a boolean.
• Updates server console command handling to track whether a script handler processed a command and to report unknown commands to players.

Please ensure the final commit message clearly captures the motivation/goal of the change (incl. intended semantics for client vs server commands), and how you tested it (manual steps and/or automated coverage).

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
Server/mods/deathmatch/logic/CConsole.cpp	Tracks whether script commands were handled; adds unknown-command feedback and returns handled state.
Client/mods/deathmatch/logic/lua/CLuaFunctionDefs.Commands.cpp	Updates executeCommandHandler to use the new CommandExecutionResult return type.
Client/mods/deathmatch/logic/CRegisteredCommands.h	Introduces CommandExecutionResult and updates ProcessCommand signature accordingly.
Client/mods/deathmatch/logic/CRegisteredCommands.cpp	Implements the new CommandExecutionResult return type for client command processing.
Client/mods/deathmatch/logic/CClientGame.cpp	Registers the new onClientCommand built-in event.
Client/mods/deathmatch/ClientCommands.cpp	Invokes onClientCommand and changes client command routing behavior based on local Lua handler presence.

Suppressed comments (1)

Client/mods/deathmatch/ClientCommands.cpp:77

• onClientCommand currently receives executedByFunction as the 2nd parameter (pushed before the args). The PR description’s usage example expects executedByFunction to be the last vararg (after all args), so scripts will misinterpret the values as soon as any arguments are present.

        CLuaArguments arguments;
        arguments.PushString(szCommandBufferPointer);
        arguments.PushBoolean(false); // executedByFunction
        
        if (szArguments && *szArguments)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (4)

Client/mods/deathmatch/ClientCommands.cpp:86

• The early return true when a registered Lua command executes means onClientConsole no longer fires for commands handled client-side. The linked issue explicitly calls out onClientConsole as showing all executed commands, so this looks like a backwards-incompatible behavioral change. If the goal is only to stop sending the command to the server, keep firing onClientConsole and only skip the network send when handled locally.

        // If command was handled by Lua, don't send to server
        if (commandResult.wasExecuted)
        {
            return true;

Client/mods/deathmatch/logic/CClientGame.cpp:2752

• The event signature string for onClientCommand ("command, executedByFunction, ...") does not match the usage shown in the PR description (function(command, ...) with executedByFunction being the last vararg). Update the declared argument list to reflect the actual order/shape that scripts should expect.

    m_Events.AddEvent("onClientCommand", "command, executedByFunction, ...", NULL, false);

Client/mods/deathmatch/ClientCommands.cpp:77

• onClientCommand is documented in the PR description as function(command, ...) with executedByFunction as the last vararg and command arguments passed as individual varargs. The current implementation passes (command, executedByFunction, "<args string>"), so scripts using the documented pattern will misinterpret the arguments. Consider pushing each argument token as a separate Lua argument and appending executedByFunction last; also use the boolean return of CallEvent rather than reading WasEventCancelled() out-of-band.

This issue also appears on line 82 of the same file.

            CLuaArguments arguments;
            arguments.PushString(szCommandBufferPointer);
            arguments.PushBoolean(false);  // executedByFunction
            arguments.PushString(szArguments ? szArguments : "");

            localPlayer->CallEvent("onClientCommand", arguments, false);

            // If command was intercepted and cancelled by event, don't execute or send to server
            if (g_pClientGame->GetEvents()->WasEventCancelled())
            {

Client/mods/deathmatch/logic/CRegisteredCommands.cpp:159

• ProcessCommand now accepts executedByFunction and returns CommandExecutionResult.wasCancelled, but executedByFunction is unused and wasCancelled is never set. This makes executeCommandHandler's !result.wasCancelled check ineffective and prevents scripts from cancelling function-driven client commands. Consider triggering onClientCommand here when executedByFunction == true, setting wasCancelled and returning early when the event is cancelled.

CommandExecutionResult CRegisteredCommands::ProcessCommand(const char* szKey, const char* szArguments, bool executedByFunction)
{
    assert(szKey);

    CommandExecutionResult result;

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

Suppressed comments (4)

Client/mods/deathmatch/ClientCommands.cpp:144

• This hunk changes core-command handling by silently treating unknown core commands as handled when bAllowScriptedBind is true. That behavior change isn’t mentioned in the PR description (which focuses on adding onClientCommand) and could hide legitimate “unknown command” feedback outside of keybind scenarios.

        // Call our comand-handlers for core-executed commands too, if allowed
        if (bAllowScriptedBind)
        {
            CommandExecutionResult coreCommandResult = g_pClientGame->GetRegisteredCommands()->ProcessCommand(szCommand, szArguments, false);

            // If core command failed, don't show unknown message (these are usually keybinds)
            if (!coreCommandResult.wasExecuted)
            {
                // Silently ignore failed keybind commands to prevent spam
                return true;
            }
        }

Client/mods/deathmatch/ClientCommands.cpp:78

• onClientCommand is currently triggered (and cancellation is honored) for all commands typed by the user, which also prevents server-side commands from being sent to the server when the event is cancelled. Per #3160, cancellation should only stop client-side (Lua-registered) commands, while server-side commands should continue to work as before.

This issue also appears on line 133 of the same file.

        // Trigger onClientCommand event first to allow cancellation of any client command
        if (localPlayer != nullptr)
        {
            CLuaArguments arguments;
            arguments.PushString(szCommandBufferPointer);
            arguments.PushBoolean(false);  // executedByFunction
            arguments.PushString(szArguments ? szArguments : "");

            localPlayer->CallEvent("onClientCommand", arguments, false);

            // If command was intercepted and cancelled by event, don't execute or send to server
            if (g_pClientGame->GetEvents()->WasEventCancelled())
            {
                return true;
            }
        }

Client/mods/deathmatch/logic/lua/CLuaFunctionDefs.Commands.cpp:96

• executeCommandHandler checks !result.wasCancelled, but CommandExecutionResult::wasCancelled is never set in CRegisteredCommands::ProcessCommand (and executedByFunction is currently unused). As-is, cancellation via the new onClientCommand event can’t affect executeCommandHandler, and the API suggests behavior that isn’t implemented.

            CommandExecutionResult result = m_pRegisteredCommands->ProcessCommand(strKey, strArgs, true);
            if (result.wasExecuted && !result.wasCancelled)
            {

Client/mods/deathmatch/logic/CClientGame.cpp:2752

• onClientCommand is registered with argument signature "command, executedByFunction, ...", but the implementation currently passes a single arguments string (not varargs). This mismatch makes the event contract/documentation ambiguous.

    m_Events.AddEvent("onClientCommand", "command, executedByFunction, ...", NULL, false);

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.