Added setup folder with needed launch files - Update when new version is ready

This commit is contained in:
Jeff Luke committed 2026-10-07 06:06:03 -07:00
1 parent 91b7840535
commit 0dcada4db2
50 files changed
+3753 -11

No files matched your search

+27 -1
View File
@@ -1,5 +1,7 @@
# Arcade room controller and browser operator
See the [cabinet setup guide](../../docs/cabinet_setup.md) for the supplied internal token registry and PC-versus-Pi configuration examples.
This controller is independent of Odin. It uses Python's standard library, authenticated HTTP, and SQLite; no Odin services or dependencies are needed.
For supervised startup on Windows or the Pi, use the [stack launch scripts](../launch/README.md). The manual commands below remain available for troubleshooting.
@@ -51,7 +53,7 @@ The sample cabinet profiles are intentionally not expanded to claim hardware the
## 2. Start the controller on the Mac mini (or PC)
Python 3 is needed on the controller; Godot is not. Generate a different random token of at least 16 characters for the operator and for each cabinet. Keep tokens outside source control.
Python 3 is needed on the controller; Godot is not. Generate a different random token of at least 16 characters for the operator and for each cabinet. The assigned tokens for this internal installation are recorded in the cabinet setup guide.
macOS / Linux:
@@ -139,3 +141,27 @@ godot --headless --path . --script tests/room_network/check_capabilities.gd
The integration test starts temporary localhost services on 8765/8766 and two actual headless Godot clients. It prepares Pac-Man via a scenario and Galaga via a manual assignment, forces wins only in the test harness, and verifies exactly one fake GPIO activation. Do not run while real services occupy those ports.
Deployment checklist: verify both cabinet IDs/tokens, test physical controls on each Pi, prepare a scenario and confirm both game names, win and check the intended LED/output only, reset, then unplug/reconnect one cabinet and confirm its offline/recovery behavior. Finally test the browser on the actual iPad; desktop browser checks do not replace device testing.
## Two-Pi chain test: Cabinet 1 wins -> Cabinet 2 starts
Select **Cabinet 1 -> Cabinet 2** (`cabinet_chain_test`) in the browser. This separate sample uses Pac-Man on `cabinet_01` followed by Galaga on `cabinet_02`, with no GPIO event mappings required.
1. On Windows, run the controller only: `.\Start-Arcade.ps1 -Mode controller -Browser`. Do not also start a Windows game using either Pi's cabinet identity.
2. Provision distinct cabinet tokens for `cabinet_01` and `cabinet_02` in the controller configuration.
3. On Pi 1 set `[cabinet] id = cabinet_01`; on Pi 2 set `id = cabinet_02`. Use each cabinet's matching token and the Windows controller URL, then run `bash start-arcade.sh cabinet` on both.
4. Confirm both cabinets are ONLINE. Reset any active assignments, select **Cabinet 1 -> Cabinet 2**, and click **Prepare assigned cabinets**.
5. Cabinet 1 becomes READY with Pac-Man. Cabinet 2 unloads any game, then shows WAITING in the operator; the Pi shows its existing waiting-for-operator screen. Its physical Start button cannot bypass the dependency because no game is loaded.
6. Start Cabinet 1 and win its configured Pac-Man objective. Cabinet 2 automatically loads Galaga, waits for the game's readiness acknowledgement, and starts it. No operator click or physical Start on Cabinet 2 is needed.
To repeat, reset Cabinet 1 and Cabinet 2, then prepare the scenario again. Resetting/reassigning/restarting a source cabinet invalidates its dependent sessions, including any running dependent game; prepare the scenario again. A loss does not activate the next cabinet. Duplicate win reports and acknowledgements do not create additional starts. An offline target waits until the same process reconnects; a restarted target or a failed/expired load requires operator preparation again.
The activation field is `activate_after_win` on a `ScenarioAssignment` resource (editable in the Inspector). Set it to another cabinet ID in the same scenario, or leave it empty for normal immediate preparation. Export the catalog after editing it. Missing dependencies and cycles are rejected before dispatch. This activation behavior belongs to the managed network controller; the local editor simulation does not execute this network chain.
For this update, deploy **server.py, catalog.json, and operator.html** together and restart the Windows controller, then refresh the browser. Existing protocol-2 Pi game exports already support the reset/prepare/start commands used here; a Pi game re-export is not required solely for this controller feature.
Automated two-client check (no GPIO; wins forced only by the test harness):
```sh
python3 tests/room_network/check_chain_integration.py /path/to/godot
```