Recording Global Aim Rotations for Reviewed ML Training

Short answer: what global aim recording does

Global aim recording writes yaw and pitch changes from every online player, plus players who start rotating later, into one JSON file per player per session. An operator starts it with an explicit command. Per FairPlay engineering notes, the output is raw, reviewable data rather than labeled training samples, so review which players were legitimate before any conversion.

Start, stop, and check a recording

The three commands below control the recorder. Run them from the console or as a player who holds the required permission. The alias windows also works.

• Grant fairplay.command.ml.global (default op) in addition to fairplay.command.ml. Only grant it to staff who will handle the data.
• Announce the recording to players first, using the disclosure policy you already publish.
• Start the recording with record GLOBAL and note the start time in your staging log.
• Stop the recording with stop. New samples stop entering at once, but files are still being written.
• Wait for the server console to print the completion message, or poll status until the final counts appear.

/fp ml aim window record GLOBAL
/fp ml aim window stop
/fp ml aim window status

Know what the files contain

Files are written under the plugin data folder, in a per-player directory. The name starts with the UTC recording-start time, including milliseconds, and ends with a session prefix. A new session never overwrites an earlier recording from the same day.

Each file holds the rotation samples for one observed player. Players online when recording begins get a file even if they never rotated, and late joiners get a file once they rotate. The table lists the fields an admin is most likely to check.

What is not recorded

The recorder stores rotations, timestamps, usernames, and UUIDs. It does not store IP addresses, chat messages, or world positions. That is narrower than a full movement log, but it is still personal data tied to a player account, so disclosure and retention still apply.

Long sessions can produce large files. Watch free disk space while a recording runs, and plan a deletion date for raw files once they have been reviewed and converted.

Decide which files you can use

A file that exists is not automatically usable. The file state and the drop counters decide whether it belongs in a training set. Use the table as your review gate before any import.

Review before anything reaches training

The raw files are chronological rotation samples. They are not the training database format, and they are not labeled. The operator decides which files represent confirmed legitimate players, then converts them. Do not assume that every online player was legitimate, and do not let captured data change live predictions without review.

Keep a written record of who approved each file and why. If a player later appeals, that record is the evidence you will need.

What we have not verified

The FairPlay engineering notes report unit tests for capture, late joins, stop and drain behavior, file naming, and invalid values. They also report that the full Maven build and integration tests were not verified in the packaging environment. Treat the recorder as runtime-evidence-pending until your own server builds and runs it.

Before relying on it, record a short staging session with two test accounts, stop it, and check that the files finalize, the names are unique, and the drop counters are zero. This page makes no claim about the cost of recording on your server. Measure that with your own profiler, for example the procedure in the spark timings article.