Platform & avatar mode settings

When creating an experiment, the World & Platform card has two settings that shape how your study runs: allowedPlatforms and participantAvatarMode. They control, respectively, which device types can join the experiment and what participants look like once they're inside.

You can edit both fields any time from the experiment detail page after creation. They take effect immediately for new sessions; sessions in progress are unaffected.

Screenshot pending — the World & Platform card on the experiment detail page, with the platform checkboxes (4/5 checked) and the Participant Avatar dropdown set to HIDE.

allowedPlatforms — which devices can join

A multi-select with five options:

By default all five are checked. The setting is enforced at the eligibility check (callExternal type=checkJoinEligibility): when a participant tries to enter, the Web Console reads their envInfo.platform from the join request, and rejects them with eligible: false if it isn't in the allowed list. They're then teleported back to a gate world — never reaching your experiment scene.

The setting also appears on the Recruitment World bulletin board: experiments tagged VR-only show a "VR required" badge so participants on other platforms don't try to join in the first place.

When to restrict platforms

A few practical rules of thumb:

• VR-only studies (presence research, body-ownership manipulations, bone-tracking experiments): check only VR. Other platforms will be rejected at the door rather than partway through.
• Cross-platform studies that you've explicitly validated on each platform: check the ones you tested. Don't ship to Android if you haven't run a pilot on Android — input handling and rendering differ.
• Pilot/test runs: check everything. Easier to test from a desktop client than to put on a VR headset every iteration.

participantAvatarMode — what participants look like

A single-select dropdown with three values. The chosen mode is applied across the entire experiment (it's not per-session or per-condition).

HIDE (default)

Forces a transparent / invisible avatar for every participant. Participants are invisible to themselves and to each other.

When to use:

• Perception studies where avatar appearance would confound results.
• Studies that supply a custom avatar via AssignAvatarToParticipant — HIDE keeps the original Cluster avatar out of the way so the assigned wrapper avatar is the only thing visible.
• Studies where the participant's own embodiment shouldn't matter at all (e.g., reaction-time tasks with no body in scene).

DEFAULT

Forces the standard LUIDA avatar on every participant — a neutral, gender-ambiguous full-body mesh. Every participant looks the same.

When to use:

• Between-subjects studies where avatar variability would confound results (e.g., a paired-trust study where you don't want one condition having "cute" avatars and another "scary" ones).
• Studies that depend on full-body presence but don't want to deal with avatar-related noise.

UNRESTRICTED

Participants keep their own Cluster avatar, including UGC and uploaded VRMs.

When to use:

• Naturalistic social studies where self-expression matters.
• Pilot or recruitment events where you want participants to feel at home.

Interaction with AssignAvatarToParticipant

If you use the runtime action AssignAvatarToParticipant("foo", 1) anywhere in your scene, the experiment's participantAvatarMode must be HIDE. Otherwise:

• With DEFAULT: the participant renders with both their LUIDA standard avatar AND the assigned wrapper avatar simultaneously, occupying the same space. Looks broken.
• With UNRESTRICTED: same problem, but with their personal Cluster avatar visible behind the wrapper.

The console shows an inline warning when you select DEFAULT or UNRESTRICTED and your project has registered avatars (LUIDA's avatar manager sets a flag the console reads). Heed it.

Where the values are stored

Both fields are columns on the Experiment Prisma model:

• allowedPlatforms: Platform[] — array of enum values.
• participantAvatarMode: AvatarMode — single enum value (HIDE / DEFAULT / UNRESTRICTED).

The Recruitment World fetches both via the questList and questInfo dispatch types; your experiment world reads them implicitly via the eligibility check.

Common pitfalls

• Checking only VR without testing in CSEmulator. CSEmulator runs as a desktop environment. Tests will hit eligibility rejection unless you temporarily check WINDOWS / MACOS for development.
• Leaving DEFAULT on while using AssignAvatarToParticipant. The double-avatar bug is visible immediately in any test session — fix by switching to HIDE.
• Forgetting that UNRESTRICTED allows UGC avatars. Some Cluster UGC avatars are very large mesh-wise or use materials that interact unpredictably with low-light experimental scenes. If lighting matters, use HIDE or DEFAULT.
• Restricting platforms after publishing. Tightening allowedPlatforms after launch means in-flight participants on now-excluded platforms get rejected on their next session. Usually fine, but flag it in your debrief.

Where to go next

• Creating an experiment — where you first set these fields.
• Sessions and balancing — the related runtime caps (maxSessionCount, exclusion lists).
• AssignAvatarToParticipant — the runtime action that requires HIDE mode.
• Reference → Web Console API → checkJoinEligibility — what the platform check looks like on the wire.