Opening a six-week light trail season without building 500 slots by hand

What does bindro actually create when I generate slots?

You give it a first date, a last date, the entry times you want to run each night and how long an arrival window lasts. It creates one session for every combination of date and time, and for each of those sessions it creates one inventory pool per ticket type, all at the capacity you specified.

That last detail is the one that catches people out. Capacity is per session per ticket type, so if you have a standard entry and a peak entry, a slot generated at a capacity of 120 has 120 standard AND 120 peak available — 240 entries against a window you meant to hold 120. Either generate with one ticket type and add the others deliberately, or set the pools you do not want to zero afterwards.

Slot generation refuses to run at all until at least one ticket type exists, on purpose: sessions nobody can buy anything for are a half-built state that looks finished from the console.

Why does it stop at two hundred slots?

Two hundred is the limit per generation, and a light trail season reaches it easily. Forty operating nights with twelve arrival times is 480 sessions — more than double the limit — so the generation is refused with a message naming the number it would have created.

This is not a limit on your season; it is a limit per batch. Generate November, then the first half of December, then the rest. Because each batch carries its own capacity, splitting the season is also how you give a Saturday more entries than a Tuesday without editing anything afterwards.

• Count first: operating nights × entry times per night. Over 200 means more than one batch.
• Split the batches along a line that means something — weekends at one capacity, weeknights at another, the fortnight before Christmas at a third.
• Generate the busiest pattern first, so if you have miscounted you find out on the nights that matter.
• Check the event page afterwards: every generated night appears with its slots, and a night that is missing is a batch you did not run.

How do I make one night different from the rest?

Per-slot, per-ticket-type capacity is editable one pool at a time, and setting a pool to zero is how you close a ticket type on a night without deleting anything. That is the mechanism behind peak pricing, quiet-night promotions and a Christmas Eve that runs shorter hours than the rest of the week.

It is genuinely one edit per pool, so decide the pattern before you build rather than after. Trails that try to price every night individually spend an evening in the console; trails that settle on two or three ticket types and a weekend-shaped pattern spend ten minutes.

Lowering a capacity below what has already sold is refused rather than silently oversold — the invariant that stops a slot selling more entries than it holds is the same one that stops you shrinking a slot underneath the people already in it.

What should I check before the first night goes on sale?

Walk the booking flow yourself on a phone, in the dark, outdoors if you can. The arrival-slot picker refreshes availability every fifteen seconds and the last entry in a slot is locked in the transaction that takes the money, so two people racing for it cannot both succeed — but only your own eyes will tell you whether the times you generated are the times you meant.

Then buy two entries as a test, because that is the booking shape that behaves differently. Any booking of more than one entry creates a group with a place per entry, and since a trail asks nothing about each visitor at checkout, those places start unnamed — and an unnamed place is refused at the gate. The booker gets an email with a link to name them. Read that email before your visitors do.