Proposal for an improved track recording system.

[19//Moach]

This is to detail the concept for a new method for recording ingame action hereby suggested.

 

 

Advantages:

 

* Removes the necessity of player-initiated recording control.

* Does not interfere with existing manual recording features.

* Uses same logic as existing features, with minimal extra coding needed.

* Records continuously, allowing post-facto decision on whether to keep tracks.

* Transparent operation, does not require action from player when not in use.

* Minimal file storage overhead, with settings-defined cycle length, for space saving considerations.

 

Benefits:

 

* Moments of unexpected action may be captured on track, even when not manually recording.

* Ingame bugs, glitches and any such elusive phenomena can be documented trivially.

* Ultimately greater and richer stream of user videos, due to capture of unexpected ingame events.

* Self-recycling, yields less file wastage than preemptive recording of unpredictable moments.

 

 

Principle of Operation:

 

 

This novel recording method relies on the existing system for the same purpose, with changes only to the manner of its application.

 

Whereas the current system records between user controlled start and stop, the proposed system is to record continuously.

 

A block length duration is specified by game settings (default 5 minutes).  Once the continuous recording reaches this duration, the track is saved and a new recording is automatically started. 

 

A maximum number of blocks to be kept as files is also determined by settings in the same way (default 6).  Once the maximum number of recording blocks is reached, the oldest of these is deleted.

 

This results in a continuous flight-recorder style loop of track (30 minutes length, by defaults) being kept during all moments of gameplay.  Optionally, this may be disabled entirely in settings, for performance considerations should the user desire it.

 

During play, the user may at any time press a given key for the purpose of "Save Replay".  Having activated this, the current set of recording blocks is moved to a separate folder, preventing its eventual deletion by the block cycle. The currently active recording is also finished at this same moment, then saved and moved along with the preceding blocks. The system then resets and resumes its cycle anew.

 

Additional key bindings may be employed also, to selectively store a smaller number of recording blocks than maximum. Thus giving the user more control of "Replay" timing, making for more convenient storage of brief chance events found to be of interest.

 

These continuous recording tracks should be stored in a sub-folder of the tracks directory, reducing the amount of clutter in the file system.

 

When manually recording with the old (current) manual system, the continuous block system is interrupted and put on standby. This eliminates the need to accommodate two recordings at the same time.  Loop recording resumes after manual recording is finished.   

 

Optionally (by settings), a "save replay" action may be triggered simultaneously when the user initiates a manual recording. This is due to the understanding that the decision to start recording is often made a few moments after an exciting event has occurred. It is then reasonable to assume, that the latest recorded blocks prior to manual operation may very likely contain events of interest for later review.

 

 

 

Optionally, the game may also offer an option to "stitch" together two recorded blocks into one larger single file.   However, since this relies on currently unsupported functionality, it is not critical to this request.  This is moreso given the issue that the playback system becomes less responsive proportionally to track length, making it more convenient to use with smaller blocks, even when captured manually.   Such a feature, however, would be beneficial in cases of intense action caught "in between" blocks. In these instances, it would be indeed desirable to have one or more blocks combined for continuous viewing.

 

 

 

 

Thanks for your attention.

Edited November 29, 2017 by 19//Moach

[56RAF_Roblex]

I seem to remember that CLoD servers often suffered performance problems when too many people were recording tracks. If BoX has the same issue then making every player record tracks non-stop would be a bad idea.  Just a thought.  I have no idea if BoX is affected in the same way.

[19//Moach]

Hopefully not.... That would indeed be a bad thing.

 

Anyways, I see no reason for client-side recording to affect server performance. Not saying it couldn't happen, but it would be very weird if it did.  CloD was an unfinished product, hence its excuse.  This is a whole different beast, with a completely new engine which is wholly apart from CloD.  I wouldn't expect any bugs from one in the other.