How it works

Overview

This page keeps the full documentation, but groups related topics into fewer, larger sections so the guide is easier to scan without losing detail.

Detection pipeline

1

Chat monitoring

The plugin reads the RS3 chatbox using Alt1 OCR and watches for configured drop, chest, or loot triggers.

2

Trigger detection

When a trigger phrase appears, the plugin enters a short verification window to confirm what happened and where.

3

Local verification

Where supported, it verifies the drop by matching item icons or UI elements before submitting.

4

Deduplication

It blocks repeated submits of the same event on the client and the server rejects duplicates again as a final safety net.

5

Submission + audit

A verified payload is posted to your Rs3Bingo API, logged, and displayed on the board feed with attribution.

Chat monitoring & triggers

The always-on scan loop checks the chatbox at a steady interval and looks for known patterns such as:

• “You open the chest…” • “You receive: …” • Boss-specific reward / currency messages • Streak or chest payout lines

When a trigger matches, Rs3Bingo captures surrounding chat lines, records a timestamp, and starts verification checks.

Verification methods

Icon match: compare cropped UI slots to the plugin’s item icon set.
Chest detection: confirm the correct chest or loot window is open.
Context checks: validate the drop against the expected boss or encounter trigger.
Near miss logging: if verification fails, the plugin does not submit and can record the event for tuning.

Deduplication safeguards

Duplicate submits can happen if the same chat line stays visible across multiple scans, a chest remains open, or the player scrolls chat. Rs3Bingo reduces that with a layered strategy:

Event fingerprint: hash of player + bingo + trigger type + item/amount + context.
Short cooldown: recently submitted fingerprints are ignored for a window.

State-aware locks: repeated chest or UI states do not resubmit endlessly.
Server-side rejection: the API rejects duplicate fingerprints as a final backstop.

Why this matters: OCR alone can be noisy. Rs3Bingo only submits when a trigger is confirmed and, when possible, backed by an on-screen verification step.

Installation, precheck, and setup

Setup

Installation

1

Install Alt1 Toolkit

Make sure Alt1 is installed and you can open RS3 inside Alt1.

2

Open the Rs3Bingo plugin

Load the plugin page inside Alt1 or via your hosted plugin URL.

3

Set IGN + Bingo/Team

Choose your identity and board assignment so submissions map correctly.

4

Enable monitoring

Start monitoring after precheck. The feed will show status and recent verified submissions.

Precheck process

Before starting monitoring, run the precheck to confirm Alt1 capture, chat OCR, UI recognition, and verification are all working correctly. This catches bad layouts early and prevents missed submissions, false triggers, and repeated setup confusion.

1

Confirm Alt1 capture

RS3 must be running inside Alt1 with screen capture working normally. If Alt1 cannot read the game window, nothing else will pass.

2

Check chat visibility

Keep the chatbox visible, un-obscured, and large enough for OCR. Avoid panels overlapping the chat area.

3

Validate OCR lines

Ensure system messages used for triggers are visible and not filtered out. If the plugin cannot read the lines it expects, detection will fail.

4

Run a trigger test

Perform a known action such as opening a chest, claiming a reward, or producing a test trigger line to confirm detection fires.

5

Calibrate UI locks

If the plugin prompts for chest detection, loot rows, or fixed windows, let it lock on to those elements using your current layout.

6

Check verification preview

Confirm the detected item, boss context, or chest state matches what is actually on-screen before you rely on auto-submit.

7

Review precheck result

Only begin monitoring when OCR, trigger recognition, and verification checks all look stable for your layout.

When to rerun precheck

First installation or first launch on a machine
After changing interface scale or moving UI panels
After switching display resolution or DPI
After OCR errors, false triggers, or missed submissions

What precheck is trying to prevent

Unreadable chat text
Wrong chest or loot window detection
Low-confidence icon matches
Submitting duplicate or incorrect events

Tip: If monitoring works poorly after a UI change, rerun precheck before changing thresholds. Most reliability issues start with layout drift.

Recommended in-game setup

Keep the chatbox visible and un-obscured.
Use a consistent UI scale where possible so chest and slot detection remain reliable.
Avoid chat filters that remove system lines used as triggers.
If you change interface scaling, rerun setup or precheck so locks can recalibrate.
Keep chest or reward windows in predictable locations if that activity depends on UI matching.

User guide

FAQ

What does “monitoring” actually do?

Chat OCR loop + trigger checks + verification window

Guide

Monitoring reads the chatbox on an interval and searches for configured trigger phrases. When a trigger fires, Rs3Bingo captures surrounding context, including chat lines and timestamps, then performs verification checks such as chest detection or icon matching before posting to the API.

What is the precheck process for?

Confirms OCR, UI locks, and verification before live use

Precheck

Precheck is the plugin’s readiness pass. It confirms Alt1 can capture the RS3 client, the chatbox is readable, trigger lines are visible, any UI lock points are calibrated, and verification output looks correct before monitoring starts. It is the fastest way to catch setup problems before a real drop is missed.

Why didn’t it submit my drop?

Usually verification failed or dedupe prevented a repeat

Help

Most common causes:

The trigger line did not match because system lines were hidden, filtered, or unreadable.
The chest or loot window was not detected reliably because the UI moved, scaled, or overlapped.
Icon match confidence was too low because of scaling, compression, or icon pack mismatch.
Deduplication blocked a repeat because the same state was detected again without meaningful change.
Precheck was skipped after a layout change, leaving OCR or UI locks out of date.

How does dedupe decide what is “the same event”?

Fingerprint of identity + trigger + item/value + context

Dedupe

Rs3Bingo builds an event fingerprint from player identity, selected bingo or team, trigger type, detected item or value, and surrounding chat context. The plugin keeps a rolling cache of recent fingerprints and ignores repeats for a short window. The API also rejects duplicates if a client submits the same fingerprint again.

Is this safe / can someone fake submissions?

Verified payloads + server checks + audit trail

Security

Rs3Bingo is designed to submit only after trigger and verification. On the server, duplicates are rejected and submissions can be audited by timestamp, player identity, and board assignment. If you want stronger protection later, signed requests, per-user tokens, and board-scoped permissions can be added.

When should I rerun precheck?

After UI scale changes, layout moves, resolution changes, or OCR issues

Setup

Rerun precheck any time the plugin’s reading conditions change. That includes moving panels, resizing the client, changing chat size, altering DPI or scaling, or noticing missed detections. Treat precheck as a quick recalibration step, not a one-time install-only task.

Updates / changelog

Latest

Keep a short rolling log here. Example:

• 2026-03-07 — Expanded plugin page with dedicated precheck documentation, cleaner section structure, and SEO improvements • 2026-03-04 — Plugin page refreshed + chat monitoring/dedupe documentation • 2026-02-28 — Barrows icon matching improvements + threshold tuning • 2026-02-26 — UI theme polish + feed behaviour tweaks

If you want this to auto-populate, wire it to an /api/updates endpoint and render the list dynamically.

Rs3Bingo

Rs3Bingo Alt1 Plugin Guide