Marker ids: next, and Re-ID
You never have to pick an id. A new marker takes the next one free, a typed id always wins, and an id once given never moves on its own.
The rule
- Next: a new marker gets the first free block after the highest id in use in its dictionary family (4X4_50 and 4X4_1000 are one family: the first 50 are the same markers). A grid or a board gets one block, as many ids as it prints.
- Typed ids win. Type one and it is kept, even when another marker has it; the Studio says: “#5 overlaps t1: both keep their ids, change one”
- Given ids stay. Each marker's first id is kept in the file's ledger, so deleting or adding a marker never renumbers the others. Past the end of a dictionary, numbering wraps to the lowest free block and says so: after #49 in DICT_4X4_50 the next marker gets #0, with “past DICT_4X4_50's last id 49: it wraps to the lowest free id #0”
- Re-ID (Edit › Re-ID all markers) numbers the driven markers again in board order from a start you pick, each grid or board one block. It is stateless: run it twice and nothing moves.
In numbers
Three new markers get #0, #1 and #2; a 2 × 2 grid after them #3–6. Type 10 on the second and the next new marker gets #11, while the others keep theirs (#0, #2, #3–6).
The Sticker sheet example (File › Examples), whose ids are scattered, Re-ID'd from 0, in reading order:
| Marker | Before | After Re-ID |
|---|---|---|
| single | #42 | #0 |
| single | #25 | #1 |
| grid | #33–36 | #2–5 |
| single | #41 | #6 |
| single | #37 | #7 |
| charuco | #2–11 | #8–17 |
| single | #17 | #18 |
| grid | #43–46 | #19–22 |
| single | #40 | #23 |
| single | #1 | #24 |
| single | #29 | #25 |
| single | #30 | #26 |
Why
“We don't want to have to worry about ensuring unique IDs.”
Zach, 2026-10-18
“As I copy paste new single markers, how are the new IDs calculated? It seems like it would be simplest if they simply increment”
Zach, 2026-10-20
In the code: core/autoid.py (Next id, rule 3, and Re-ID) through web_ids.assign_ids; the contract's IdRequest.