Everything it does

How it fits together

Four layers, and you only need the first two to be up and running:

Setup is roughly five minutes: rez the server, answer its dialogs, open the one-time link it IMs you, set a password and your tip split, then touch a jar to pair it.

Tips, splits and the money trail

• Instant in-world splits. A visitor pays the jar; the staff member and the house each receive their share at that moment. Nothing is held.
• Tip tiers you configure per venue, or a custom amount, with per-job overrides — a DJ and a dancer can carry different buttons and different splits.
• Thank-yous your way — message text, delivery style (local say or IM), hover text and jar naming, all templated with the staffer's name and the amount.
• Live session totals in the jar's hover text, and an IM summary at logout: how long you were on, and what you took home.
• Full tip history on the web — every session with its total, click through to each individual tip: who, how much, when. Filter by job or staff name; the totals line always reflects the whole filter, not just the loaded page.
• Queued when offline. If the web is down when a tip lands, the jar holds it and delivers it when the connection returns. Nothing is lost.
• A real payout ledger. Every L$ transfer the jars make is recorded with its actual Second Life transaction ID, so a disputed payout is a lookup rather than an argument.
• Explicit failure states. Payouts read Paid, Failed (with the reason — the money stayed with the jar owner, settle manually) or Unconfirmed. No silent losses.
• A reconciler. A Missing payout filter lists any tip or donation where someone was owed a share but no payout was ever recorded.
• Group-only tipping, if you want the jar to accept only from people wearing your group tag.

Fundraisers and donation jars

A separate, optional jar type that collects for a cause rather than a person:

• Create a fundraiser on the web — name, the recipient the donations pay out to, a goal, a duration, and the information donors see.
• Rez a Donation Jar, pair it, and a manager touches it to choose which fundraiser it runs — the same gesture a DJ uses to pick a job.
• Donations split between the fundraiser's recipient and your house cut, progress tracks live on the web, and donors get an Info menu with a website link, an about text and an optional freebie item.
• Every payout is tracked. A mistyped recipient key stops the drive and is recorded, rather than quietly going nowhere.

The booth — staff, streams and the room

• Touch-to-login with a picker of the jobs that person actually holds at this venue. The jar renames itself to them and shows their profile picture.
• Up next. Touch a busy jar to queue; the current staffer is told someone's waiting, and the handoff happens automatically at logout.
• Auto-logout for anyone who leaves the region, with a warning IM and a grace period so a crash-and-relog doesn't cost the booth.
• Manager takeover — kick the current session and take the booth without the owner needing to be online.
• Streams follow the session. A DJ logs in and the parcel plays their stream; they log out and it reverts to your default — unless someone is queued, in which case it holds and hands straight over.
• An empty stream never silences a venue. A staffer with no stream URL simply changes nothing on login.
• Mid-set recovery — Fix Stream re-asserts the DJ's stream, and trusted roles get a My Stream / Venue Stream toggle for when a stream dies mid-set.
• Deeded and group land is handled by the StreamSwapper: spawn it from the server, deed it to the land group, and it applies stream changes on the server's behalf. One venue can run several across several parcels.
• Genuine offline operation. The server caches your venue config, so during a web outage jars keep working and staff can still log in against the cache. A red OFFLINE note in the hover text says so honestly.
• Manager approval fallback — if the server can't verify someone during an outage, the jar offers Ask a Manager, who approves them at the server there and then.
• Profile-picture plugin — drop a script into a linked prim and it shows the working staffer's picture.
• One login, every venue. Staff who work at several XTech venues use one account and switch with a picker; each venue keeps its own job settings for them.

The web dashboard

Every page adapts to your role — owners see all of it, managers see what their access grants, staff see their own. In full:

• Dashboard — tips per day, top earners this week, recent sessions, and personal numbers for staff.
• Venue Info — a live snapshot: who's on right now, what's next, a map tile, the team, current staff notices, and whether the in-world server is actually reporting.
• Manage Venue — name and description, streams, jar behaviour and tip tiers, the split, the attached bot, auto-greet, in-world boards, Discord, notifications, public listing, exports.
• Manage Access — who can manage this venue and what they can do, with roles, per-feature switches, and guardrails that stop you locking yourself out.
• Manage Jobs — the job types your venue offers, each defining whether login swaps the stream, its tip tiers and its rank.
• Manage Staff — who holds which job. Removing someone here is what takes them out of the jar's login picker.
• Events — the calendar and the engine behind every automated notice. Detailed below.
• Announcements — the routing table mapping an announcement group to the SL groups that should hear about it.
• Templates — reusable notice text with placeholders for the event name, time and staff. Write once, stop retyping.
• Staff Board — an internal noticeboard for your team, which also appears on the in-world staff board and the venue info page.
• View Tips — the money page, with My Tips for staff.
• Visitor Stats — aggregate footfall.
• Fundraisers — the web half of donation jars.
• Media Library — the venue's pictures and sounds.
• Bots — register, drive and deploy your notice bots.
• Audit — inactive staff, the activity trail, and the payout ledger.
• My Profile — every user's own page: account, password, Discord link, personal stream and per-job settings.
• Displays and Quizzes / Quiz MC — appear when the venue holds the matching add-on.

A ? in the top bar of every page jumps straight to that page's section in the documentation.

Events, and everything that fires off them

An event is entered once and becomes the source for the notices, the reminders, the boards, the Discord calendar and the public feed.

• Scheduled in SLT, with a start and end time, the event's type and style (a music genre, a class subject — the axis is named to suit the type), and the staff working it.
• One-off or recurring — daily, weekly, monthly or yearly with an interval, so "every other Friday" is one entry rather than a wall of duplicates. Types that are never recurring simply don't offer the control.
• Multi-day runs — a fair or a hunt spans dates and is presented as a range everywhere, never as a countdown.
• Public or private. Untick Public event and it stays off the public board, the public calendar and the directory — while still showing on staff surfaces, marked with a lock.
• Reminders at offsets you choose (minutes, hours or days, before or after the start), each one of four kinds: a group notice, a group chat line, a staff IM, or a staff check.
• Group notices fan out automatically to every SL group mapped to the event's announcement group.
• Group chat as a fallback — for event groups where a bot may chat but not post notices, which is most of them.
• Sent exactly once, on time, even across bot restarts.
• Staff reminders without a bot. Venues with no bot still get staff IMs, delivered through their own in-world server.
• Staff checks — the reminder that asks rather than tells. See below.
• Event posters — an optional flyer per event from the media library or a pasted texture UUID, used on the Discord card and the public listing; without one, the DJ's own poster is used.
• Notice text from templates, so a season of events reads consistently without anyone retyping it.

Reaching your team when it matters

The hardest part of running a venue isn't the money — it's a DJ who can't make Friday and a manager who finds out on Friday. Three features exist purely for that:

• Cover calls. When a slot opens, everyone who holds that job is asked. Whoever takes it first gets it — one press of a Discord button, or a one-click link in an SL instant message, no login required. They then inherit the usual reminders as if the night had always been theirs.
• Staff checks. A reminder placed days ahead that puts I'll be there / I can't make it to whoever is assigned. Saying no opens a cover call immediately — which is the whole point, because the gap is now visible on Tuesday instead of Friday. Answers show against the date on the events page.
• The daily rundown. One summary of tonight to your managers at an hour you pick: who's on, who's confirmed, unfilled slots, and any cover call still open with its deadline. Nothing is sent on a quiet night, so it never becomes the message everyone ignores.

The notice bot

An optional Second Life account that you create and run, in one small Docker container, on a VPS, a home server or a PC that stays on. It dials out to Second Life and to our controller, so there are no ports to open. Everything it does is driven from your dashboard — you never log in as it.

• Scheduled group notices with an inventory attachment, sent on time and exactly once.
• Group chat messages, manually or as a scheduled reminder.
• Staff reminder IMs — "you're on in 30 minutes".
• Auto-greet arrivals at your venue, by IM or a personal hello.
• Group invites — offered to newcomers, or sent to a list you paste or scan from the crowd around the bot.
• An FAQ desk. Residents IM the bot and the first entry whose keyword matches replies — typo-tolerant, with a "did you mean…?" on a near miss.
• Answers that do something — hand over an item (a drink, a demo, a landmark), carry a one-click teleport to a spot in your build, or hand out a named contact person's profile when nothing matches.
• Public event lookup — anyone can IM it "events" for what's coming up; staff can ask "next" for their own next shift.
• Live model. It wears your actual saved SL Outfits and poses on a stand — swap looks from the web, or auto-rotate poses and outfits through the day.
• Sit it anywhere — a scan lists nearby furniture, one click sits it, and furniture pose menus appear on your dashboard to drive.
• It puts itself back. After a relog, a region restart or a Send Home, it returns to its stand by itself.
• Web-managed inventory — drop items on it in-world, then sort, file and attach them from the dashboard.
• Paced IMs by design — Second Life suspends accounts that burst instant messages, so outbound sending is throttled deliberately.
• Deployment on a plate — the dashboard hands you a registry login, a ready docker-compose.yml and a prefilled .env. Updating is docker compose pull && up -d.

Discord

Entirely optional, and everything works as before without it. Connect your server in three clicks and the bot appears under your venue's name, not ours.

• Your events in Discord's own calendar, with the poster as the picture, so members can press Interested and be reminded. Change a time and Discord follows; cancel and it's cancelled there too.
• Cover calls as direct messages with a Claim this cover button.
• Staff checks with I'll be there / I can't make it buttons.
• The daily rundown to your staff channel, or direct to each manager.
• Resident questions relayed. When someone asks your in-world bot something the FAQ can't answer, the bot offers to pass it on; if they agree, it lands in your staff channel with a Reply button. The answer arrives as an SL instant message from your bot, signed with the staffer's name.
• Slash commands — /next, /schedule, /ask and /help. Staff who have linked their account get their own shifts and the real calendar; everyone else gets the public answer. Replies are private to whoever asked.

The public side — being findable

Second Life publishes no grid-wide events API, so venues are mostly invisible outside their own group. Turning on List us publicly puts your venue on events.xtech.dev and everything that hangs off it:

• A live directory of who's playing right now and what's coming up, browsable by event type and style, with each type on its own indexable page.
• A page per venue and a link per night — paste either anywhere and it renders as a card with the poster and the details. Event links survive renaming: the id and date decide the night, the words are decorative.
• Calendar subscriptions (ICS) for the whole directory, one type, one venue or one performer. Recurring nights are expanded to real dates, IDs are stable so edits arrive as edits, and times are published in UTC so every calendar app shows them correctly.
• A live card for your own website — a plain iframe, so it works on Wix, Squarespace and hosted WordPress, which all strip scripts. It takes your accent colour automatically and follows the visitor's light/dark setting.
• A badge image for forum signatures and Marketplace listings, where iframes and JavaScript are banned — 320×56, a red dot when you're live, refreshed about once a minute.
• Performer cards. DJs, hosts and live artists get their own card, badge and calendar feed that follows them across every XTech venue they work at — one snippet on their profile that never needs touching. Covers are handled both ways: a night handed over drops off, a night claimed appears.
• A free JSON API. No key, no signup, no quota paperwork — GET, CORS open, cached about 30 seconds. Live acts, upcoming events, the live taxonomy, and filters by type and style.
• In-world status boards. A media (MOAP) face at the venue showing the week's schedule and who's on now — a public board, and a staff board that adds bookings and the staff noticeboard. Each doubles as a calendar feed.
• A 12/24-hour and SLT/local toggle on every public time, because "9pm SLT" means nothing to a visitor in Berlin.

Visitor statistics

• Visits and unique visitors per day, busiest hours in SLT, new versus returning, how long people stay, and what share of arrivals are in your group.
• No bot required. Your venue server does the counting on its own parcel, so the numbers always tie to that parcel. A bot only adds the group share.
• Exclude staff and bots (on by default), so a DJ hanging around all night doesn't read as footfall.
• Aggregates only. Never a per-person list — the public feed reports a crowd count and nothing else, and reports an honest dash rather than a guess when a venue's server has gone quiet.

Media library

The venue's catalogue of pictures and sounds — the pool that display boards, event posters and quiz media rounds draw from. It works with Second Life texture UUIDs, so the cheapest way in is content that already exists on the grid:

• Curated public packs — flags, bird calls, anthems and friends — browsable alongside your own items, with attribution and licence riding along.
• Harvest from your bot, free. Share a folder of textures to your bot in-world and import it here. It reads the UUIDs; nothing is re-uploaded, so it costs nothing.
• Upload from your computer — the bot encodes and uploads to SL for you. This one costs the usual L$ upload fee, which is why it's a grantable permission rather than something everyone has.
• Items are private to the venue unless you make them public.

Add-ons

Each is its own object you rez and pair to your venue server, and a one-time licence per venue — no subscription. Once a venue holds one, its dashboard pages appear.

Quiz — live pub-quiz nights

• A Quiz Board at the venue and answer HUDs for the players. Touch the board to join; joining and rejoining works mid-quiz, so a crash-and-relog catches straight up.
• Multiple-choice and free-text questions, solo or team scoring, points per question, and answers changeable until the MC closes the question.
• Picture and audio rounds. Pictures show on the HUD (with a zoom view) and on the board; audio clips play privately to each player, so nothing blasts over the venue stream.
• Build from a question bank — a wizard over thousands of ready-made trivia questions from the community-maintained OpenTDB and OpenTriviaQA banks: pick categories and difficulties per round, or quick-fill a whole quiz and trim it.
• Media rounds auto-build a "name this" picture or audio round from a media library pack.
• An MC console built for a working DJ — one big button for whatever comes next, inline judging of free-text answers, reveal answer, audio replay, a live leaderboard and a "live on board ✓" check. Or run the whole night from the floor by touching the board.
• Answer-key access per quiz, so the people playing can't see the answers and still author for other nights.
• A recap afterwards — every question and every answer, read-only.
• It earns its space between quizzes — pair the board to an OmniDisplay Store and it joins the poster rotation as just another screen, handing itself back when a quiz starts.

OmniDisplay poster boards

OmniDisplay itself is a standalone in-world product that needs no web at all: a Store prim holds the textures and drives any number of paired Screens, with instant, black, fade, cross-dissolve and reveal transitions, several Stores side by side, and a live mode that always shows the newest texture dropped in. The Web Control add-on puts it on your dashboard:

• Show now — put any texture up immediately for a set number of minutes, then the board resumes its rotation by itself. Ideal for tonight's flyer or the working DJ's poster.
• Sequence — build the exact playlist from the board's own textures and the media library, or reset to auto and let it rotate whatever is physically inside.
• Because it works with texture UUIDs, driving a board from the web never costs upload fees — and staff can still walk up and drop textures in the old way.

Access, records and privacy

• Roles that bundle sensible permissions, so you rarely think harder than "manager" versus "staff", with guardrails against locking yourself out or demoting the owner.
• Per-person feature switches — grant a trusted host the display boards or the quizzes without making them a manager. Grants stop working the moment someone leaves the staff.
• An activity trail of the privileged and destructive actions: who deleted a venue, changed the split or the stream, granted access, added or removed staff, registered a bot, logged in. It stores IDs only — never message text — and entries age out after 12 months.
• Inactive staff surfaced for safe pruning, with the same careful cascade as Manage Staff: history kept, future access removed.
• Export your records as spreadsheets or one JSON file: tips and donations, payout legs, shifts, staff and jobs, events, daily visitor counts. As often as you like, deleting nothing.
• We hold no email addresses. Password recovery sends a 15-minute login link as a Second Life instant message — which only whoever controls the avatar can read, and that is exactly what a password proves.
• Data about non-staff is deliberately out of your export — who visited, who your bot greeted, what residents IM'd it. Those are kept only briefly and are available on request, which is the point rather than an omission.
• Automatic retention. Short-lived records prune themselves on a schedule; relayed resident questions are deleted 24 hours later.
• A published privacy policy and terms, with no placeholders in them: Privacy · Terms.

Two editions

If you want a solid tip jar you set up once and forget, there is a version with no web at all — configured entirely from notecards inside the server prim, which you can edit any time.

The jars are the same jars, so upgrading later means setting the venue up on the web, swapping the server, and touching each jar once to re-pair it. Nothing is lost. Lite in detail →

What you need to run it

The honest limits

Things worth knowing before you choose, rather than after:

• The server must stay rezzed. It is the only object that talks to the web; jars, swappers and donation jars go quiet without it. It must never be deeded to a group.
• One server per venue, and one Discord server per venue. Several clubs means several of each.
• The bot needs a machine that stays on. There is no hosted option today — that is a deliberate trade for you owning the account, but it is a real requirement.
• Second Life throttles instant messages, and there is a daily per-account message allowance we cannot raise. A large roster takes several rounds to reach in-world, which is precisely why the Discord path exists.
• Shared media on a prim is readable by anyone who can stand near it. That is what the public board is for; place the staff board where the public can't wander, or use its link from a browser instead.
• No directory can claim full grid coverage. Linden Lab publishes no events feed, so ours lists XTech venues that opted in, and says so.
• Lite keeps no history. The running total lives on the object and there is no per-tip record. If you want history, you want the full edition.

On the roadmap

Designed and queued, but not live — listed so the line between the two is obvious:

• Raffles and giveaways — one click picks a winner from the people at your venue and delivers the prize.
• Subscriber lists — customers get your news by IM without burning a group slot, the answer to "I can't join, my groups are full".
• VIP and loyalty — automatic rewards for big tippers and repeat visitors.
• Vendor integration — a customer buys from your vendor system and the bot thanks them, offers the group and sends a gift.

If one of these is the feature you need first, say so — it moves up the queue.

© XTech. All rights reserved. · Privacy · Terms of Use