Служба підтримки Steam
Team Fortress 2 Replay Server Overview

Вступ

Для нетехнічного огляду функції повторів перегляньте цей прес-реліз.

По суті функція повтору є продовженням SourceTV. The feature must be enabled on the server side, and the "demo" files that are ultimately generated include the full PVS, meaning everyone's perspective is recorded. Якщо говорити про звичайні демофайли, у них буде записано лише те, що бачить локальний користувач.

На початку етапу «підготовки» до раунду гри система повторів одразу ж почне записувати, якщо її ввімкнено (через консольну змінну replay_enable). Цей раунд, також відомий як сеанс запису, отримує унікальне ім’я на основі дати й часу його запису. Упродовж раунду/сеансу запису невеликі блоки даних періодично публікуються на файловому сервері, звідки їх можуть завантажити клієнти.

Типи файлів повтору

Публікуються два типи файлів:

1. Блоки сеансів запису — ці файли фактично є стиснутими частинами демофайлу. Коли клієнт зберігає повтор, система визначає, скільки блоків їй потрібно завантажити, щоб відтворити відповідний файл. Коли клієнт збирається відтворити конкретний повтор, блоки розпаковуються, перевіряються і записуються в один єдиний демофайл, який показує гра.

2. Файли даних про сеанс — у кожного раунду/сеансу запису є один файл з даними про нього, який містить інформацію про стан всіх блоків сеансів запису. Цей файл має розширення .dmx і оновлюється щоразу, коли змінюється стан будь-якого блоку. Клієнтам потрібно завантажувати файл даних про сеанс конкретного повтору кілька разів, якщо доступні не всі блоки (наприклад, якщо вони й досі публікуються чи пройшло не так багато часу). У файлах даних про сеанс також міститься інформація про те, чи сеанс зараз записується, чи ні.

There is no client-specific data in recording session blocks or session info files, since any resultant demo file contains everyone's perspective. Кожен клієнт записує інформацію про своїх гравців, щоб можна було увімкнути повтор від правильної першої особи.

Коли клієнт надсилає запит на збереження повтору, він повинен завантажити всі блоки з початку раунду. Якщо вам цікаво, причиною цього є те, що демофайли — «дельта-стиснені», тобто кожен «кадр» у демофайлі залежить від попереднього кадра. Хоч це й не ідеальне рішення, варто зазначити, що клієнти знають, які блоки потрібно завантажити. Це означає, що для будь-якого раунду кожен блок буде завантажено лише один раз.

Публікування

Є два способи, як сервер повтору може опублікувати файли завантаження для клієнтів:

1. Локальний вебсервер — для цього способу потрібно інсталювати вебсервер на той самий пристрій, на якому знаходиться ігровий сервер. Щоб опублікувати файл, сервер запише його на тимчасове місце на диску, а потім перемістить (перейменує) до локального шляху, який бачить вебсервер. Якщо файл не вдасться перейменувати, система скопіює його в місце призначення і видалить вихідний файл.

Перевагою цього підходу є те, що він безпечніший (на думку деяких користувачів), а також його легше налаштувати.

Варто взяти до уваги й кілька недоліків. Найбільше проблема — клієнти, що завантажують з вебсервера, можуть використовувати пропускну здатність й ресурси ЦП, необхідні для безперешкодної роботи гри. Цей підхід також є доволі «витратним» для ігрового сервера з точки зору пропускної здатності, оскільки навантаження збільшується з кожним клієнтом, що завантажує файли. Lastly, this approach may open your server up to potential "Denial of Service" attacks if proper security measures are not taken. For faster machines with faster connections, this approach may be preferred.

2. Розвантажування FTP — альтернативний спосіб, який потребує доступу до ще одного комп’ютера, на якому повинні бути запущені як FTP-сервер, так і вебсервер. Система повторів асинхронно розвантажуватиме файли повторів з ігрового сервера на другий комп’ютер через FTP. Вебсервер повинен вказувати на той самий шлях на диску, щоб клієнти могли отримувати з нього вивантажені файли.

Головна перевага цього підходу — тягар розповсюдження даних повторів більше не падає на комп’ютер з ігровим сервером; це робить другий комп’ютер. «Витрати» пропускної здатності мінімізовані, оскільки кожен блок файлів повтору транслюється (вивантажується) лише раз (порівнюючи з локальним вебсервером, де кожен клієнт, який зберігає повтор конкретного раунду, завантажуватиме перший блок файлу).

FTP не є захищеним протоколом, тому варто бути обережними із логіном і паролем, щоб вони не потрапили в руки зловмисників.

Configuring Replay

Для повтору буде створено три пов’язані файли з розширенням .cfg, кожен з яких міститиме детальні коментарі. Важливими є лише два з них.

replay_local_http.cfg - Edit this file if you plan on using the "Local Web server" method described above.

replay_ftp.cfg - Edit this file if you plan on using the "FTP Offloading" method described above.

replay.cfg - Edit the bottom of this file to execute either replay_local_http.cfg or replay_ftp.cfg. This is the main configuration file for Replay and should be executed on server launch (i.e. "+exec replay.cfg").

Regardless of which publishing method you choose for your server, you'll need to set the following three ConVars:

replay_fileserver_host

replay_fileserver_port

replay_fileserver_path

These ConVars are shared with clients and are used to construct the URLs for downloading recording session blocks and session info files.

The URL is constructed using the following as a template:

http:// (replay_fileserver_host) : (replay_fileserver_port) (replay_fileserver_path)

So, as an example, if you have a Web server running on my.domain.com on port 80, you would set replay_fileserver_host to "my.domain.com" and replay_fileserver_port to 80. replay_fileserver_path should be set to the relative path where replay files will be published, so this would be something like "/" or "/replay". Note that none of these ConVars should contain "http://". You also do not want to include any slashes in your replay_fileserver_host.

If you cannot successfully point a Web browser to the URL constructed by replacing the template above with the values you have specified for the three fileserver ConVars, clients will not be able to download their Replays.

Configuring replay_local_http.cfg

You will only need to edit replay_local_fileserver_path, which is the full path for the Web server. For Apache on a Windows machine, using the replay_fileserver_* ConVars above, this path might be something like:

"C:\MyWebServer\htdocs\replay"

On Linux, this might be something like:

"/path/to/my/web/server/htdocs/replay"

Configuring replay_ftp.cfg


You will need to edit the following ConVars, which are used to login and upload and clean up Replay files:

replay_fileserver_offload_hostname - The host name of your FTP server.

replay_fileserver_offload_port - The port needed to connected to your FTP server. This is usually 21.

replay_fileserver_offload_login - Your FTP username.

replay_fileserver_offload_password - Your FTP password.

replay_fileserver_offload_remotepath - The path on the FTP server where Replay files should be uploaded. For example, "/users/myusername/replay"

Testing Your Replay Configuration

Once you've edited the config files, you can test everything by start a dedicated server, making sure to include +exec replay.cfg to the command line parameters.

Once the game launches, the Replay system will run a series of self-tests using your configuration. Depending on the publishing method you chose, the system will either try to publish a temporary file to your local HTTP path or publish a file to your FTP server. At the time of this writing, your replay_fileserver_* ConVars will not be validated - you should do this yourself by filling out the template URL noted in the "Configuring Replay" section above and pointing a Web browser to that location.

Cleanup of Stale Replay Data

Replay files are considered "stale" if they were published more than replay_data_lifespan days ago. An asynchronous cleanup operation is launched in between every round, although it can be cleaned up explicitly using the replay_docleanup command.


Frequently Asked Questions

I want to run a Replay-enabled server. Where do I start?
Read this document, from beginning to the end.

I'm running multiple servers on the same machine. Is there a way to specify a different directory for each server?
Yes. Add -replayserverdir <dir name> to each server command line. The directory name should be something like "server01" or "server02," and not a full path.

When a client presses the F6 key, what exactly does that do?
On the client side, number of kills, spawn and death ticks, dominations, etc are maintained on a per-life basis. If a life goes by and the client does not press F6, the data is thrown away. If a client does press F6, however, this data gets flagged and is saved to disk. Once the player dies (if they weren't already dead when the pressed F6), the death tick is written and the system figures out the maximum recording session block needed to reconstruct a demo that will cover the entire life.

If no one saves a Replay for a particular round, does the data get thrown away?
Yes.

Does Replay record on an empty server?
No. Replay begins recording at the start of the "setup" phase and ends with each round.

If clients disconnect from my server, will they still be able to download their Replay data?
Yes. Since Replay data is served on a Web server (and not on the game server itself), clients can download replays after disconnecting.

Will executing a changelevel command disrupt recording or publishing of Replay data?
No.

Will shutting down my server mess up Replays?
If you shut down your server using the "exit" command, it should publish any data it needs to and shut down gracefully. The "quit" command should work fine, too.


Потрібна допомога зі Steam?
Скористайтеся помічником підтримки Steam, щоб звузити тему та отримати відповідну допомогу.
Допомога спільноти
Створіть допис або пошукайте відповідь на своє запитання в обговореннях Steam.