Add script commands for start/stop/check Replay

[Emistry]

Is your feature request related to a problem? Please describe. Is there a way for us to add script command that allow us to control the game client's record replay feature?

but at clif.c seem like don't have the packets for these right? since its possible to manual trigger through the game clients, so its also possible to implement it to trigger from server side? Maybe useful to allow player to save recording in case they are forgotten, and transfer the replay anywhere after that?

Useful Scenario: You wanted player to save a replay to help you debug something, but often end up forgotten. So you implemented this in NPC scripts, the NPC script will auto enforce the recording if any. Players will always end up saving the related replay that you may need, unless they manually deleted it from the Replay folder.

Describe the solution you'd like 3 script commands to control the replay feature.

1. isRecordingReplay() - check whether the client is currently recording any replay.
2. startRecordReplay("replay_file_name"{, "npc_event_if_cancelled_by_player"});
3. stopRecordReplay() - stop any recording if any

Sample NPC scripts to start/stop recording a replay.

// check if any recording are in progress
if (isRecordingReplay() == false) {
    // start the recording and stored with the name given.
    // if player manually cancel the recording, trigger OnCancelEvent 
    // (only happen if the recording are created by script)
    startRecordReplay("new_replay_file_name", "npc_name::OnCancelEvent"); 
}
else {
   // stop the recording that created by the NPC script
    stopRecordReplay();
}

[rdw-software]

since its possible to manual trigger through the game clients, so its also possible to implement it to trigger from server side?

That isn't necessarily true though, is it? If the client doesn't recognize any packets related to replays, the server can't tell it to start/stop recording, even if the client (obviously) knows how to do these actions.

Disclaimer: I don't know whether the client actually knows any such packets. Just saying that the existence of client functionality doesn't imply said functionality to also be exposed via the networking layer.