Luck of the Dwarves

I

What am I looking at? A public ledger of ring proc lines captured from chat via Alt1 OCR.

▼

This page is a read-only view of proc events submitted by an Alt1 web app. Each entry usually includes:

• Timestamp (when the server stored it)
• Item + amount parsed from the proc message
• RSN (optional, user-supplied)
• Signature (a sha256 “seal” used to dedupe and identify the event)
• Evidence (optional PNG snippet of the chat line)

Tip: click any row to open the evidence modal and inspect details.

II

Is this official or verified by Jagex? No. Community-built, observation-only, evidence-first.

▼

This project is not affiliated with Jagex. It does not read memory, does not automate gameplay, and does not change your account. It reads pixels and performs OCR on the chatbox, then logs what it sees.

III

How do events get into the ledger? Alt1 detects a proc line, captures evidence (if possible), then POSTs to the server API.

▼

The Alt1 client:

• Finds your chatbox region using Alt1 chatbox detection
• Reads new chat segments on a short interval
• Matches “Luck of the Dwarves” or “Hazelmere’s signet ring” proc lines
• Extracts item name + amount
• Captures a PNG snippet as evidence (if pixel capture is available)
• Posts JSON to the write endpoint (protected by a shared key on the server)

IV

What does it NOT do? It does not read game memory, detect bosses automatically, or influence drops.

▼

It is strictly observational:

• No memory reading
• No gameplay changes
• No “proc forcing” or drop prediction
• Boss fields (name/mode/kc) are optional metadata if a client sends them

V

What do the fields on a row mean? Timestamp, item, amount, RSN, boss metadata, signature, and evidence.

▼

In normal mode you see “pills”:

• RSN: optional player name supplied by the client
• Boss: optional metadata (name/mode/KC) if supplied
• Evidence: whether a PNG snippet is linked
• Seal: short form of signature_sha256 (the stable identifier)

In slim mode, the same info is compacted into a single dense row with a small signature chip on the right.

VI

What is the “Seal” (signature) and why do I care? It’s the dedupe key and the identity of a single event.

▼

The signature is a sha256 hash derived from the proc content (and related parsed fields). It is used to:

• Prevent double-logging if OCR re-reads a line
• Provide a stable ID for integrity workflows
• Reference a specific entry without relying on database IDs

Tip: open a row, click Copy signature, paste it in bug reports or discussions.

VII

Why do some entries look similar or “duplicated”? OCR can see the same line more than once; signatures stop true duplicates.

▼

OCR scanning is a loop. The same chat segment can appear across frames, and multiple clients can observe similar outcomes. The ledger uses signature-based dedupe so exact duplicates are accepted as “already logged” instead of creating extra rows.

VIII

What counts as “evidence” here? A PNG snippet captured from chatbox pixels and stored server-side.

▼

Evidence is usually a cropped image of the matched chat segment. If cropping fails, the client can fall back to capturing the whole chatbox area. No evidence on a row typically means capture was unavailable or skipped.

IX

Why does an event sometimes have no evidence image? Pixel permission, capture failure, or client-side restrictions.

▼

Common causes:

• Alt1 pixel permission not enabled for the app
• Chatbox could not be captured reliably (UI scaling changes, overlays, unusual chat theme)
• Client chose not to upload evidence for that line
• Server rejected or could not write the file

If you are running the Alt1 app and see frequent no-evidence logs, re-add the app in Alt1 and confirm permissions.

X

I clicked evidence and got a broken image. Why? Usually path or hosting issues: file moved, permissions, or a deploy mismatch.

▼

Most likely:

• Evidence file exists in DB but is missing on disk
• Uploads base path is misconfigured on the frontend
• Server storage permissions changed
• CDN or caching layer is serving stale references

The row still retains the signature, item, and timestamp even if the image is unavailable.

XI

How does the page update in real-time? It polls for entries newer than the latest timestamp it has seen and rolls them in.

▼

The feed checks the API every 2.5 seconds. It requests events newer than the last seen timestamp (with a small overlap buffer), dedupes them by signature, then prepends them and trims old ones past your limit.

XII

What does “Live: Paused” do? New events are still fetched, but they queue until you click Show.

▼

When live is paused:

• The client still polls the API
• New signatures go into a queue
• A banner appears with how many are waiting
• Click Show to apply them to the feed or Discard to drop the queued batch

Useful when you are reading older rows and do not want motion in the list.

XIII

What is Slim mode? A dense feed layout: no thumbnails, no pills, just the essentials.

▼

Slim mode is designed for fast scanning:

• Removes evidence thumbnails from the feed row
• Replaces pills with a compact metadata line
• Moves the signature into a small chip on the right

Clicking a row still opens the full evidence modal.

XIV

How do the filters work? They filter what is already loaded in your current feed window.

▼

The RSN, Item, and Evidence controls filter the currently loaded set of events (up to your selected Limit). For example, if your Limit is 50, the filters apply to those 50 loaded rows. Tip: raise Limit to view a wider recent window, then filter.

XV

Do the charts update automatically? Yes. They refresh in the background (separate from the feed polling).

▼

The dashboard refresh loop updates:

• KPIs (Totals, Unique counts)
• Hourly Proc Rhythm chart
• Top Items chart

This happens without reloading the event list, so your scroll position stays calm.

XVI

What does “evidence-first” actually mean? Rows are more than claims: when possible, they include verifiable screenshots.

▼

“Evidence-first” means the system tries to attach a screenshot snippet of the exact chat line that triggered the log. It is not perfect, but it makes the ledger more auditable than a purely text-only list.

XVII

What is a Merkle root and why would this ledger use one? A daily fingerprint of many events, useful for append-only integrity stories.

▼

A Merkle root is a single hash that represents a whole set of hashes (the “leaves”). If you publish a daily root, later you can prove that a particular signature was part of that day’s ledger set without publishing everything. In plain terms: it’s a “daily wax seal” for the day’s batch.

XVIII

Are exports or snapshots cryptographically signed? Not by this page directly. The system is designed to support signing workflows.

▼

The tooling approach is:

• Generate a signing keypair server-side (keep private key secret)
• Export daily data (CSV/JSON) and sign it
• Publish the public key so anyone can verify the signature

This frontend does not perform signing; it is the display layer.

XIX

Can I see LOTD vs HSR breakdown on this page? Only if the server stores ring attribution in event metadata.

▼

The client can infer “LOTD” vs “HSR” based on the proc text, but the server must persist that fact (for example in a JSON column like meta). If the server does not store it, a chart cannot reliably compute it later.

XX

Is RSN required? No. Clients can submit anonymously.

▼

RSN is optional. If a client includes it, it appears in the public feed and can be filtered. If omitted, the entry can still be logged with item, amount, timestamp, signature, and evidence.

XXI

What data is stored? Item, amount, timestamps, optional RSN/boss metadata, signature, optional evidence image.

▼

Typical stored fields include:

• Timestamp of insertion
• Item name and amount
• Raw OCR text of the proc line
• Optional RSN
• Optional boss metadata (name/mode/kc)
• Event signature (sha256)
• Optional evidence image hash and path

This project aims to keep the footprint minimal while remaining auditable.

XXII

The lamp says “API unreachable”. What now? Usually server downtime or a network/caching issue.

▼

Try:

• Click Refresh
• Hard refresh the page (Ctrl+F5)
• Check if the site is under maintenance

If you are the operator: confirm PHP is running, the API base path is correct, and the DB is reachable.

XXIII

Can I link someone to a specific FAQ answer? Yes. Each entry has a stable hash link.

▼

Each FAQ item has an id like #faq-signature. Copy your browser URL after opening an item to share a deep link.