UploadCollectedData
These pages are not yet fully reviewed. The LUIDA team is continuing to review and improve them. If you find anything wrong on these pages, or have questions that aren't resolved by reading them, please ask or report to the LUIDA team.
UploadCollectedData()StableData Logging- Fires
- On State Start · During State · On State Exit · Always-on events
Description
Flushes LUIDA's queued upload records to the Web Console. Displayed in the State-listening Items editor as Upload saved data from collector. The CCK equivalent is the Upload saved data phase on LuidaDataCollectionGimmick.
Parameters
No parameters.
Side effects
- Sends the signal
exp_uploadCustomDatato the item's own scope ($.sendSignalCompat("this", "exp_uploadCustomData")). - The
LUIDA-DataCollectoritem (runningCustomDataUploader.js) listens for this signal and walks$.state.customData[], batching records and dispatchingcallExternal({ type: "uploadCustomData", ... })calls to the Web Console (POST /api/cluster). - Batching: records are split into batches of at most 100 records and approximately 100 KB of UTF-8-encoded JSON, whichever cap hits first. Each batch is one
callExternalcall. Don't bypass the action — bypassing skips the batching logic and risks payload-size errors. - The same effect is produced by enabling the Upload saved data phase on a
LuidaDataCollectionGimmick. The legacyLuidaUploadCollectedDataGimmickcomponent is deprecated but still works.
Why the gimmick uses a Signal, not a Bool
The merged gimmick patches its upload statement via PatchStatementAtSignal (a CCK Signal, type 0) — not via a constant Bool. CCK encodes a Bool's timestamp deterministically (true → epoch + 1 ms), so a Bool-driven trigger only fires once per Cluster instance — every subsequent activation looks like a stale value. Signals re-emit a fresh timestamp on every trigger, so upload works reliably across the full session. If you're reflecting on the gimmick or writing your own CCK trigger to flush uploads, follow the Signal pattern.
Example
In Tutorial 3 (Stroop), the TimeRecorder × Outro cell flushes everything recorded across all 16 trials at the end of the experiment:
// On State Start
UploadCollectedData();This pattern — Process and save per trial, Upload once at the end — minimizes network traffic and is the recommended default for short-to-medium experiments. For long experiments where you want partial saves, you can also call UploadCollectedData() periodically (e.g. every 10 trials).
In Tutorial 1 (Priming), the bridge checkpoints fire the trigger-driven equivalent (Luida Update Collected Data Gimmick) inline — record + upload in one step on each checkpoint collision.
Related
SendDataToCollector(label, value)— write a key/value into the scratchpad.ProcessAndSaveCollectedData()— snapshot the scratchpad into a queued record.- Configure data collector — the visual builder for the per-scene calculator script whose output ends up in these uploaded batches.
- Concepts → Data collection — explains batching internals, when to upload, and how records reach the Web Console.
- Tutorial 2 → TimeRecorder × Outro — single end-of-experiment flush of all trial data.