Hi, first of all, best wishes for 2026.

Actually, I want to come back to my simple question why changing your personal login password doesn't work.

No dont skip it. Its not a virus. He worked for it, and its not a virus, so calm down.

Hello Praline, hope you're well.

I've covered this before; my practical look-back limit is three cycles.

You can see "My definitions for Playable systems" thread at:

• rouletteideas.com/index.php?topic=269.0

* Cycle 1: the immediate cycle, this is where you act.
* Cycle 2: a barometer for continuation of clumping between cycles, weighted sub‑cycles, and inter-cycle trend/flow direction.
* Cycle 3: for untying patterns and providing overall rhythm/flow, plus secondary/supporting indicators.

(In my personal framework)

If you want more detail, you can see "Diminishing weight for 37-number cycles and their key usage":

• rouletteideas.com/index.php?topic=143.0

As TwoUp puts it there:

Quote from: TwoUpOnce you have a ranking then decide how many and which numbers you want to bet based on their relative strengths, hit count etc.

Yes, the choice is somewhat arbitrary, but I try to keep it logical. Use long-term expectations (return to the mean, global effect) only as high-level indicators, and base decisions on the short-term scenario in front of you. That means adopting a perpetual short-term betting mindset, within whatever framework you prefer.

Cheers & big hug, 🤗
Vic

Hi VLS — and anyone else following,

I'm using number cycles as the natural (uneven) session limiter, and I'm also testing a combined limiter (numbers + derived numbers). The combined definition gives shorter sessions.

My trouble is making the jump from "observed distributions" to a combinatorial principles that actually operate inside the short window.

In other words, I need a clean way to define a small set of states/invariants inside a session (seen/unseen, bin occupancy, collision/closure), and then map those states to a deterministic action — so any "edge" is expressed as the balance between win % and loss size under a fixed stop-rule (+1 / −T), not as hope or curve-fitting.

I think this is the right direction to pursue — moving from descriptive stats to a small, explicit state model with fixed rules — but I'm still struggling to make that shift in a clean, disciplined way.

Thanks for reading.

Quote from: praline on Jan 12, 08:27 PM 2026This is just my current working vision: build an engine that operates within these short sessions, not a "million-spin graph." And of course, if it hits profit, you stop.

Good point.

For an individual player, long‑term winning is essentially a sequence of successful short‑term wins (which differs from the casino's aggregated, multi‑player view).

So, if you focus on reliably winning short‑session "chunks" and do that consistently, the positive long‑term result will follow.

Dual quad cycles (A start, B +1 spin).
When A & B reach identical internal state they "sync".

Versions:
MERGE (freeze B),
SKIP (B skips next spin),
DELAY (B restarts next spin, no overlap).

Note: cycle-length % proportions (L1–L4 within Same/Diff) stay essentially the same across modes; what changes is joint timing (NONE/A_ONLY/B_ONLY/BOTH and SS/SD/DS/DD).

Bellow some stats in attachment...

Sorry for snapping — language was unnecessary.

Still though...

roulette forum ≠ 'click random file' forum

If it's legit, please post at least clear testing screenshots.

Until then, the safest move for everyone is to skip it.

WHY SO MUCH HATE!!!

CALM UP, MAN

COOLLLLLLLL

Mc... an .AVI that needs to be renamed to .html is not a simulator, that's a magic trick 😅
Guys: please don't download/run this on your main machine. If you don't have full source posted publicly (GitHub/Pastebin) for review, treat it as untrusted and move on.
Mc, if it's legit, paste the full code here or GO FU"K YOURSELF!

Hello everyone, hope you're all well. I wanted to share a thought and see if anyone has input.

I think my main challenge right now is how to fit a big "game" into a small session.

From what I'm seeing, a session defined by numbers + a derived stream tends to end faster than a session defined by numbers only, so I'm treating that shorter combined-session as my "base" window. The idea (and I might be wrong) is: inside that short window, I'm trying to compress a few deterministic / non-random sub-games so they have enough chances to resolve before the session ends — basically before the ref blows the whistle.

This is just my current working vision: build an engine that operates within these short sessions, not a "million-spin graph." And of course, if it hits profit, you stop.

Still exploring and sanity-checking the direction — if anyone's played with short session limiters or shifted streams, I'm all ears.

Mickavelli — I tried your 2-shifted-cycle idea and quickly realised I'd complicated it more than helped. In practice I do see the two behaviours you described: sometimes the streams stay de-synced (A closes but B keeps cycling), and sometimes they sync and both close on the same boundary spin. But once I started tracking it, it's not just "same vs different" — it turns into a small set of overlap options (A closes/B doesn't, B closes/A doesn't, both close) and that's where my accounting got messy. So I switched to logging the joint outcome on each closure instead of trying to price it from the single-table stats. Also worth admitting: I've been using "more complicated = more likely to win" as a mental yardstick, even though I've never actually seen a real winning system — so I'm trying to force myself back to clean definitions and simple tracking.

Thanks for the input and ideas, Mickavelli.