Rs2Prayer: invokePrayer function

[FunkyMonkeyCloud]

There has been discussion on the Discord about the issues that pop up with the Rs2Prayer invokePrayer function. Specifically, the mouse cursor moves on screen and can cause misclicks. This has major ramifications for PvM plugins & the AIO Fighter / PrayerHelper combination.

I'm trying to problem solve the mouse cursor issues caused by the Rs2Prayer invokePrayer method.

@notleumas came up with a solution to move the cursor back to original position after a 30ms delay. His solution, as posted on discord:

private static void invokePrayer(Rs2PrayerEnum prayer, boolean withMouse) {
        // Save current client cursor position
        net.runelite.api.Point savedCursorPosition = Microbot.getClient().getMouseCanvasPosition();

        NewMenuEntry menuEntry = new NewMenuEntry(
            -1,
            prayer.getIndex(),
            MenuAction.CC_OP.getId(),
            1,
            -1,
            "Activate"
        );

        Rectangle prayerBounds = withMouse ? getPrayerBounds(prayer) : Rs2UiHelper.getDefaultRectangle();

        Microbot.doInvoke(menuEntry, prayerBounds);

        // Schedule cursor restoration after a brief delay to ensure click events complete
        if (savedCursorPosition != null) {
            final net.runelite.api.Point finalSavedPosition = savedCursorPosition;
            scheduledExecutorService.schedule(() -> {
                java.awt.event.MouseEvent moveEvent = new java.awt.event.MouseEvent(
                    Microbot.getClient().getCanvas(),
                    java.awt.event.MouseEvent.MOUSE_MOVED,
                    System.currentTimeMillis(),
                    0,
                    finalSavedPosition.getX(),
                    finalSavedPosition.getY(),
                    0,
                    false
                );
                moveEvent.setSource("Microbot");
                Microbot.getClient().getCanvas().dispatchEvent(moveEvent);
            }, 30, TimeUnit.MILLISECONDS);
        }
    }

@bolado.dev suggested an alternate solution, which is to disable inputs for ~50ms to enable the prayer toggle to complete before other actions were processed.

Is there a consensus on which direction to move forward? I personally think the disabling of inputs for 30-50ms is an appropriate solution. This could be safeguarded by a 30-50ms sleep in the togglePrayer function. This solution may cause implications for plugins that rely on precise timings (e.g. PvM).

[FunkyMonkeyCloud]

From @Mocrosoft via discord:

Two years ago, we used direct “invoke” calls without any mouse interaction. However, many users reported increased bans using this method. To reduce ban risk, we switched to menu entry manipulation, which simulates real mouse clicks on game menu options from anywhere on the screen.

This system relies on two events: onMenuEntryAdded and onMenuOptionClicked.

onMenuEntryAdded selects and executes the desired menu action based on a variable called targetMenu.

Once the action is clicked, targetMenu is reset in onMenuOptionClicked.

This works fine for normal scripts, but it becomes unreliable in fast-paced scenarios where multiple actions must be performed in a single tick (high-end PvM or intensive skilling). In these cases, the targetMenu variable can be reset before onMenuEntryAdded is triggered. This leads to “dead clicks” where no action is performed because the system attempts to click a cleared target.

This behavior doesn't affect slower scripts but creates issues for high-performance scripts that require precise timing. We could design a more robust system to handle multiple actions per tick while still using mouse-based input to keep ban rates low, but such a system has not yet been implemented.

I also decided not to implement packets/reflection just to avoid the upkeep of an updater. The bot was always designed as an extension of runelite, so if runelite works microbot should work. To keep things simple