Eclipse Animator live collaboration: test a shared session

Eclipse Animator live collaboration: what is documented

Eclipse Animator live collaboration is listed by the creator as a plugin capability, and the official tutorial’s live-session chapter starts at 5:29. Use that chapter for the current plugin interface. This page provides a preparation and verification workflow so a team can establish what actually synchronizes in its own project.

We have not completed a multi-user Studio test or verified a current invitation-button sequence, participant limit, connection architecture or conflict-resolution policy. Rather than guess those details, follow the creator’s demonstrated session flow and use the checks below to record the outcome. If a teammate is still getting started, send the original plugin entry and installation guide, not a mirrored project download.

Separate plugin sessions from Roblox Team Create

There are two layers to consider. Roblox Studio collaboration controls access to a Roblox project. Eclipse’s live-session workflow concerns the plugin feature documented by its creator. A successful step in one layer does not establish permissions or synchronization behavior in the other.

Roblox’s collaboration documentation describes Owner, Edit and Play permissions and distinguishes group-owned and user-owned projects. It also documents eligibility requirements for collaboration through Team Create. Review the current requirements under the intended accounts when that is your chosen Studio workflow. They are Roblox rules; do not assume that a plugin invitation overrides them.

Do not change a production project’s ownership or grant broad access simply to diagnose an animation issue. First identify whether a participant cannot open the Roblox place, can open it but cannot edit, or can edit the place but cannot join or use the plugin session. Those are different starting points for support.

Prepare a small shared test

Use a copy containing one simple rig and a short, non-sensitive animation. The purpose is to make any mismatch visible, not to prove that every collaboration feature works at once. Each participant should record the same basic information before joining:

• The Roblox account being used, without sharing passwords or session tokens.
• Operating system, Studio version and Eclipse version.
• Which place or copied project is the agreed test.
• The project’s FPS, a chosen starting pose and an easily recognized ending pose.
• Who will host or initiate the documented session and who will perform the first edit.

Keep an editable baseline outside the experimental changes. A session connection indicator, if the current interface provides one, is useful feedback, but it is not a substitute for checking that another person can see the intended edit. Follow the creator’s chapter to begin; this site does not issue invitations or handle session traffic.

Run a one-change synchronization test

The following is a proposed acceptance test. It does not claim that Eclipse implements track locks, history merging or any other particular conflict policy.

1. Confirm a common starting state. Both participants identify the same rig, frame position and starting pose. Read the values or visible state aloud or record them in a short note.
2. Give one person the first turn. That person makes one obvious, reversible pose change through the demonstrated plugin workflow. The other person observes without editing the same object.
3. Compare the result. Check the intended track and frame, not just whether something in the viewport moved. Record whether the change appears and whether both participants see the same pose.
4. Reverse roles. The second participant changes another agreed frame or object while the first observes. This checks both directions of the intended interaction.
5. Check playback. Both participants inspect the beginning, midpoint and end. If timing differs, compare FPS and the actual frame positions before attributing it to a network defect.
6. Save and reopen through the documented flow. Agree who owns this step and verify the resulting saved work independently of the currently open session.

For a one-second change at 30 FPS, the two poses are separated by 30 frame intervals. Use your actual project rate in the timing calculator if it differs. The controls reference is helpful when teammates use the same key in different editor contexts.

Divide work so disagreements are easy to resolve

Until your team has established the plugin’s actual behavior, assign one person at a time to a shared object or overlapping keyframe range. That is a coordination recommendation, not a claim that the editor enforces a lock. Agree on the intended edit before both people begin changing the same material.

A useful initial split is one animator handling a rig’s pose while another reviews framing and notes issues. Another is taking turns on separate shot ranges with a clear handoff point. If you use animation layers, verify layer behavior in the session before relying on it as a way to isolate edits. Layers do not automatically imply separate user permissions.

For a deliberate conflict test, keep it in the disposable copy: choose one unimportant value, record its baseline, and observe what happens when both participants change it. Do not promise teammates that the last edit wins, that undo is local, or that disconnected edits merge unless the current creator documentation or your own controlled test establishes that behavior.

Saving, leaving and handing work over

End the session with an explicit handoff. Record the final project name, the person responsible for saving, the last approved frame range and any unresolved differences. Have the receiving person reopen or otherwise inspect the saved result using the documented workflow.

Saving an editable project, exporting animation output and publishing an animation for a Roblox experience are separate tasks. A teammate seeing your timeline does not demonstrate that an exported asset has the correct owner or can play in the target game. Use the export tutorial for that next boundary.

If a participant leaves or loses connection, pause overlapping edits and compare the last known common state before continuing. This is a cautious working method, not a verified statement about automatic reconnect or offline support. Keep the baseline until the team has checked the final result.

Diagnose the layer that failed

Send a concise reproduction to the creator community when basic isolation does not resolve it. A useful report describes the two participants’ starting state, one action and two observed outcomes. Do not post private place access, account credentials or invitation details publicly. Your session is ready for larger work when both participants can reproduce edits and the saved handoff, not merely when a join action succeeds.