[SCRIPT] replay.py, server-side gameplay recorder for pique

---
gameplay recording script for piqueserver
---

this script is based on BR’s aos_replay: GitHub - BR-/aos_replay: Demo recorder/player for Ace of Spades 0.75 and 0.76

recordings resulting from replay.py are compatible with BR’s Playback.py

replay.py is a server-side gameplay recording implementation which bears advantages over client-side versions such as aos_replay.

  • u wont have to deal with lag in server => client traffic.
  • it does not take up a playerslot
  • it doesnt spoof up playercount on masterlist.

recording a game for later reviewing could proof to be a powerful tool for staff. if u can record your server at all times there is no way for cheaters to hide obvious cheats such as noclip, hardaimbot and etc. and even if the cheater were to use less obvious cheats such as esp, softaimbot and etc. every instance of that will be recorded and it will just be a matter of a staff to compile, review and judge them.

command and settings

command use:

  • /replay <on> <optional: custom file name> <optional: recording time in seconds> <optional: recorded ups>
    starts to record the gameplay. optionally specify a custom file name for the recording. optionally specify for how long u want to record the gameplay. optionally specify how many world_updates per second (ups) should be recorded
    • examples:
      • /rpy on test 300 ups60 => filename: test.demo | recording time: 5 minutes | recorded ups: 60
      • /rpy on 120 ups30 => recording time: 2 minutes | recorded ups: 30
      • /rpy on test 360 => filename: test.demo | recording time: 4 minutes
      • /rpy on test ups60 => filename: test.demo | recorded ups: 60
      • /rpy on ups20 => recorded ups: 20
      • /rpy on test => filename : test.demo
      • /rpy on 600 => recording time: 10 minutes
  • /replay <off>
    stops current active recording.
  • u can replace /replay with the shorter /rpy

config settings:

  • autorecording = true (false by default)
    set the server to automatically start a recording under these conditions when there is no active recording already:
    • enough players have joined the server again (at least 2 players)
    • after the map was changed and if enough players are present (at least 2 players)
  • recorded_ups = 20 (by default)
    set how many world_update packets should be recorded per second. the higher this setting, the smoother the recorded gameplay looks, the more accurate the gameplay is being depicted in the resulting recording.
  • file_name = "rpy_{server}_{time}_{map}" (by default)
    set the file name of your recordings. choose if and where in the name u want to include the following:
    • {server} => name of your server.
    • {map} => name of the map that was recorded.
    • {time} => time and date of start of the recording.

one little advise:
download the playback.py script in the replays directory for easier viewing of the recordings.

download
one last important note

problem:
the recorder needs a unique player id. if a server is full the recorder is asigned an id outside what clients consider to be valid (0->31).
Furthermore if a server becomes full as the recording is active the new player who just joined is getting such an invalid player id asigned.
the clients wont process any packets directed to their invalid player id and thus the player is, allhtough connected to the server or playback, stuck in limbo as they cant join the spectator team on their side and thus incapable of joining a game or viewing the recording.
updated solution:
clients with following or a similar modification can view recordings made from replay.py:

download for a compatible openspades build:

      -===-

Nice work!

1 Like