Rs3Bingo Plugin — Rs3Bingo

How it works (pipeline)

Overview

1

Chat monitoring

The plugin reads the RS3 chatbox using Alt1 OCR and watches for configured drop / chest / 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 (e.g., chest loot row) before submitting.

4

Deduplication

It prevents repeated submits of the same event (client-side) and the server also rejects duplicates (server-side).

5

Submission + audit

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

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

Chat monitoring & triggers

Detection

The plugin’s “always-on” loop checks the chatbox at a steady interval. It looks for known patterns like:

• “You open the chest…” • “You receive: …” • Boss-specific reward / currency messages (e.g., streak loot, Nilas, energies)

When a trigger matches, Rs3Bingo temporarily increases scrutiny: it captures the surrounding chat lines, records a timestamp, and begins verification checks (where applicable).

Deduplication (anti-spam)

Client + Server

Duplicate submits can happen if: the chat line remains visible for multiple scans, the chest stays open, or the player scrolls chat. Rs3Bingo avoids this with a layered dedupe strategy:

Event fingerprint: hash of (player + bingo + trigger type + item/amount + context).
Short cooldown: recently submitted fingerprints are ignored for a window (prevents repeats).
State-aware: chest/window locks stop the same UI state from resubmitting endlessly.
Server-side rejection: API rejects duplicate fingerprints as a final safety net.

This is why “streak” style loot can work without spamming: Rs3Bingo submits only when the detected value changes in a meaningful way, and the server keeps you honest if a client glitches.

Verification

Accuracy

Depending on the activity, verification can be:

Icon match: compare cropped UI slots to your item icon set.
Chest detection: locate the correct chest window so other chests aren’t misidentified.
Context checks: validate the drop is tied to a known boss/encounter trigger.

If verification fails, the plugin does not submit — it will log a “near miss” for tuning thresholds and icon packs.

Installation

Alt1

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. The feed will show status and recent verified submissions.

Recommended in-game setup

Stability

Keep the chatbox visible and un-obscured.
Use a consistent UI scale where possible (makes chest/slot detection more reliable).
Avoid chat filters that remove system lines used as triggers.
If you change interface scaling, re-run any plugin “setup” steps so locks can recalibrate.

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 (chat lines + timestamps), then performs verification checks (like chest detection or icon matching) before posting to the API.

Why didn’t it submit my drop?

Usually verification failed or dedupe prevented a repeat

Help

Most common causes:

The trigger line didn’t match (chat filters, different language, hidden system lines).
The chest/window wasn’t detected reliably (UI moved, different scale, overlapping panels).
Icon match confidence was too low (icon pack mismatch, compression, scaling).
Deduplication blocked a repeat (same state detected again without meaningful change).

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

Fingerprint of identity + trigger + item/value + context

Dedupe

Rs3Bingo builds an event fingerprint (think “unique receipt”) from: player identity, selected bingo/team, trigger type, detected item/value, and the 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 + verification. On the server, duplicates are rejected and submissions can be audited by timestamp + player identity + board assignment. (If you want stronger protection later: signed requests, per-user tokens, and board-scoped permissions.)

Updates / changelog

Latest

Keep a short rolling log here. Example:

• 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, we can wire it to an /api/updates endpoint and render the list dynamically.