FlaroCity WatchTower is a Second Life monitoring and protection system for land owners, store owners, club owners, rental managers, community managers, and event hosts. It connects an in-world WatchTower Terminal to the FlaroCity web dashboard so an owner can see whether a location is online, who has recently been seen, how the region is performing, whether machines are healthy, what alerts need attention, and what optional modules are active.
This guidebook is written as the main system manual. It replaces the earlier many-small-pages wiki layout with fewer, longer chapters that can be used directly as public documentation and owner training material.
What WatchTower is meant to solve
Second Life land tools are often spread across multiple objects, dashboards, note cards, Discord messages, and manual owner checks. WatchTower brings those workflows into one branded system. A single protected location can report live land data, avatar presence, region health, lag signals, terminal status, payment/subscription state, alert rules, and optional security or staff workflows.
WatchTower is not meant to be a secret surveillance tool or a magic land-power bypass. It is a land-owner operations dashboard. It should clearly show what was seen by the in-world terminal, when it was last seen, what action was attempted, and whether Second Life permissions may affect the result.
Main parts of the system
| Part | Where it lives | What it does |
|---|---|---|
| WatchTower Terminal | Second Life object | The in-world machine that registers with FlaroCity and sends safe, small updates. |
| LSL worker scripts | Inside the terminal | Split scripts for token reading, registration, HTTP queueing, heartbeat, land data, scanner batches, health, chat relay, and security actions. |
| FlaroCity API | FlaroCity.net | Receives terminal events, validates tokens, stores dashboard data, and returns dashboard/security commands. |
| Web dashboard | FlaroCity.net | Shows locations, machine state, people online, alerts, support, billing, add-ons, and admin tools. |
| Demo dashboard | demo.flarocity.net | Lets customers preview the product without needing a live Second Life install. |
| Payment Station | Second Life object / dashboard | Records Second Life payments for plans, add-ons, renewals, and manual review. |
| Add-on modules | Site + LSL + dashboard | Discord Alerts, Adult Access Gate, Staff Role Manager, Advanced Security Actions, Chat Relay, Extended History, Custom Branding, and Extra Location Packs. |
Recommended guidebook navigation
New customers should read **Owner Quick Start & Terminal Setup** first. That chapter explains what to rez, how to turn the terminal on, how tokens work, and what the first successful setup looks like.
Owners who already have a working terminal should read **Dashboard & Daily Use** and **Monitoring: Land, People, Map, Lag & Machines**. Those chapters explain how to understand the live dashboard.
Owners using paid features should read **Plans, Billing, Payment Station & Add-ons**. That chapter explains location limits, plan levels, included history, and add-on ownership.
Moderators, managers, and security teams should read **Alerts, Rules, Security Actions & Staff Roles** and **Privacy, Permissions & Safety** before using any security feature.
System promise
WatchTower should always make the following clear:
- Whether the terminal is online or offline.
- Which land, parcel, region, or protected location the terminal belongs to.
- When the latest data was received.
- Whether the owner has the subscription or add-on needed for a feature.
- Whether an action succeeded, failed, is pending, or was only attempted because Second Life permissions decide the final outcome.
Important limits in plain language
WatchTower runs inside Second Life scripting limits. That means scripts have limited memory, HTTP requests can throttle, region restarts can reset scripts, and land actions depend on parcel/group/estate powers. The system is designed around safe small updates instead of huge all-at-once payloads.
Security actions such as warn, eject, ban, and unban should be documented as permission-dependent. The dashboard can request an action and the Security Worker can attempt it, but Second Life decides whether that object has the power to complete the action on that parcel or region.
Chat Relay should be treated as a visible owner-controlled feature. The safe version is public local chat channel 0 only. It should not be described as private IM logging, hidden spying, or a replacement for Second Life moderation tools.