WolfWiki - User contributions [en]

ETTV:Viewer's Guide

2006-08-14T12:44:20Z

DA*Rogue: /* External Links */

== ETTV Viewer's Guide ==
=== Introduction ===
ETTV is a modification that allows anybody to spectate Enemy Territory matches without actually being on the server the teams are playing on. The purpose is so that you have have thousands of people all able to watch an exciting match live, without being able to interfere or otherwise cause problems with the match.

The ETTV modification is supplied within the ETPro modification, you do not need any further modification unless you intend to run an [[ETTV:Server_Configuration|ETTV Server]].

=== Watching ETTV ===
Simply connect to an ETTV server like any other Enemy Territory server. Once you are connected it will look and feel very much like you are in spectator mode on any normal server.

There are some issues which occur frequently enough to make it worth noting here, however.

* ETTV servers frequently do not allow clients (that's you/your game) to auto-download any missing files. You should try to ensure you '''have the correct patch, modification and custom map versions before you join'''. This is usually, but not necessarily the latest official version. If you do not have the correct versions you may be unable to join, or disconnected at some point during viewing.

* '''Do not be concerned about interfering with the match''', you cant. The ETTV server you join is essentially playing a live demo of the match which is actually being played on another server. You can spectate freely and talk crap with the other viewers on the same ETTV server, thats it. Chat from ETTV viewers is distinguished from chat in the match by the red "ETTV" preceding it.

* '''Connecting via IP address''' (command-line or console) is identical to any other Enemy Territory server. If you've been given the IP address of an ETTV server and are wondering what to do with it, open the console (usually by pressing the key under ESCape, often the ~ or ` key) and use the following command (including the forwardslash) - <tt>/connect ip.add.ress:port</tt>
:(for example: <tt>/connect 62.75.178.112:27962</tt>)

=== Additional Controls ===
* cycle between everybody on the server (who shows up on the scoresheet)
:fire <tt><Left Mouse button></tt>
* cycle following only objective carriers
:Prone + (fire / altweapon) <tt><X + LeftMouse></tt>
* cycle following only spectators / shoutcasters
:Zoom + (fire / altweapon) <tt><nowiki></nowiki></tt>
* Jump directly to following a player in view
: Press activate while pointing crosshair at player
* return to free floating mode.
: Press jump or activate <tt><Spacebar></tt>

=== Generally Useful Tips ===
* Chats from other ETTV spectators can be hidden with the console command <tt>/tvchat off</tt>, and re-enabled with <tt>/tvchat on</tt>. All chat done on ETTV won't be seen on the game server (luckily). If certain chatters start to irritate you, you can easily ignore specific people with the <tt>/ignore</tt> command and can use the <tt>/unignore</tt> command to show their chat messages again.

* To spectate a specific player through their eyes, open console and put in the command <tt>/players</tt>, and notice the player number. Now just <tt>/follow x</tt>. If you're new to Enemy Territory, you might find it most entertaining to follow a shoutcaster, if there is one.

* Viewing ETTV in a window can be convenient while you find other IP's, talk in IRC, or access WinAmp, for example. To do this, you can go to the options screen and set a resolution which is smaller than your desktop screen resolution, and then select windowed mode. Alternatively, enter <tt>/r_mode 3</tt> into console, and then hit ALT+Enter.

* Normal cvar restrictions dont apply when viewing demos, nor do they (usually) when viewing ETTV. This is OK because you're not playing against anyone. Several leagues remove the foliage (all the grassy stuff) on Radar because it hurts performance and, some say, isnt good for competitive gaming. As an ETTV viewer you can remove it via console: <tt>/r_drawfoliage 0</tt>. To further incrase performance you can remove wolffog (an effect which "adds" fog to the map, sometimes restricting the viewing distance [e.g. Railgun]) by setting <tt>r_wolffog 0</tt>. You might want to ensure that is reset to 1 before you join a normal gameserver however.

* ETTV is generally not live; normally a few minute long delay is added so competing teams cannot have another member watching and sending participants advantagous information.

== Shoutcasts ==
A [http://en.wikipedia.org/wiki/Shoutcast shoutcast] is essentially a match commentary, broadcast over something akin to internet radio. The shoutcaster is usually someone heavily involved with the ET community and listening to the shoutcast greatly enhances the entertainment value of ETTV.

A shoutcast is completely seperate from ETTV however, to listen to a shoutcast you will need to open the URL with a suitable program - [http://winamp.com/ WinAmp] being one of many such programs. The shoutcast URL is often available at the same place you found the ETTV details for the match you want to watch.

Like ETTV, shoutcasts are usually not totally live - normally a few minutes delay is added so competing teams cannot have another member watching or listening in and sending participants advantagous information. Typically ETTV has a longer delay than the shoutcast does, so the result is ETTV and shoutcast are out of sync.

Fortunately it isnt the other way around, because you can pause WinAmp to syncronise the two. Simply listen for some event in the shoutcast (often shoutcaster will read out the time on the clock for this purpose, or you can listen for event's like 'FIGHT!' or 'dynamite planted') and immediately hit pause. When the event occurs in ETTV, hit play again. This can be easier if you view ETTV in windowed mode, also if you make a mistake and pause WinAmp for too long, reconnect to the shoutcast URL.

== Replaying ETTV demos on a local Windows server ==

If you have ETTV Demo files (*.tv84), you can watch them locally on your windows machine. in order to do so, you will need a ETTV-Server. Download the latest version (currently: http://returntocastlewolfenstein.filefront.com/file/ETTV;52030) and proceed with the following steps:

* Extract all files except tvgame.mp.i386.so into your "Wolfenstein - Enemy Territory" root directory (not etmain).
* The tvgame.mp.i386.so file goes into the etpro directory.
* Put the *.tv_84 files in your etpro\demos directory
* Create a shortcut to ETTV.exe (Right click in explorer windows, "new..." -> "Shortcut").
* Change the program call in the shortcut (Right click, "Properties") to: '"path\ettv.exe" +set fs_game etpro +set ettv_autoplay 1 +demo demo0000'

When you double click on the shortcut, ETTV should come up displaying a console and starting the playback. Note that the demo files are required to be named like demo0000.tv_84, demo0001.tv_84, etc. in order to work like this. The server will autoplay all demos in successive order. You can now start your ET and connect to your local server (choose "Internet Play", then "connect to IP" 127.0.0.1.

==== Known Issues ====

You have to install the complete etpro package for servers - the pk3 file that clients have is not enough.

I have discovered client error "MAX_GAMESTATE_CHARS" on several demos: The ETTV seems to run fine but local clients get kicked for that reason. I have not yet found why this happens, nor a solution. Any hints on that would be helpful.

This short How-To was written on request for gamestv.org, they are hereby permitted to use this text on their own site.

== External Links ==
* [http://www.gamestv.org/ GamesTV.org] is an ETTV listings site.
* [http://www.radioitg.com/schedule.php Radio iTG's schedule] is a source of shoutcasts.
* [http://www.gamestah.com/ Gamestah] is a source of Australian shoutcasts.

[[Category:ETTV]]

ETTV:Server Configuration

2005-11-29T09:11:13Z

DA*Rogue: /* Troubleshooting */

<dot_graph>
digraph ettv {
master -> slave1
master -> slave2
slave1 -> "client1.."
slave1 -> "..client50"
slave2 -> "client51.."
slave2 -> "..client100"
slave1 -> "chained_slave1"
chained_slave1 -> "client101"
chained_slave1 -> "...client150"
}
</dot_graph>

==Installation - "Master" (gameserver)==

Copy ettv.x86 to the same directory your etded.x86 is located.
Start your gameserver as normal, but run ettv.x86 instead of etded.x86.

===Set some cvars===

'''ettv_sv_maxslaves''' (default 0, no slave connections allowed)
:Number of ettv slaves allowed to connect.
:''Note:'' Slave slots are always reserved, like private slots.
'''ettv_password''' (default "", no slave connections allowed)
:Password for ettv slaves.
:Must be set, or no slaves will be able to connect!
'''b_ettv_flags''' (default 1)
:1 = prevent slaves from being callvote kicked
:2 = grant shoutcaster status to slaves
:values can be added together, eg 3 for both features.

===Playing on the master===
Players may now connect to your gameserver as normal.

==Installation - "Slave" (broadcast server)==

Copy ettv.x86 to the same directory your etded.x86 is located.
Copy tvgame.mp.i386.so to the same directory as your etpro/qagame.mp.i386.so is located.

===Set some cvars===
'''sv_maxclients'''
:Number of spectator clients to allow. This number is only limited by available cpu and memory.
:Some guidelines when provisioning a broadcast server:
:*100 spectator slots will require ~ 128mb ram. Use com_hunkmegs to set this.
:*100 spectator slots will require ~ 768kbyte/sec (6mbits), roughly 6kbyte/sec per client
:*100 spectator slots will take ~ 80% cpu of a Xeon 2.2ghz
:*Each slave will require ~20-40kbyte/sec from the master.

'''ettv_clientname''' (default "ETTV")
:Playername the slave will use when connecting to the master, eg "ETTV-xyz"

'''ettv_delay''' (default 0, disabled)
:number of seconds for slave to delay the master feed. Recording/playback chains should no longer be needed, and slaves should always maintain an exact delay from the master server.
:''note'': this should ONLY be set on the slave.
:''note'': only supported in ettv beta8 and later

===Chat passwords===
In order to curb the rampant abuse of ettv chat, admins may set "chat passwords" on their servers. If enabled, viewers are not allowed to chat unless they have a password. You can define as many passwords as you like, so you can easily track down individual abusers and limit the damage of stolen passwords.

'''ettv_chatpasswords''' (default 0, disabled)
:number of chat passwords defined.
'''ettv_chatpassword'''(1-99999)
:individual chat passwords.

viewers use <tt>/chatpassword <password></tt> to login.

if logged in, ettv chats will be tagged with a number in parentheses identifying which chat password the viewer is using.
===Misc commands for viewers===
;For ettv beta 4 and above
* spectators may <tt>/ignore</tt> and <tt>/unignore</tt> other spectators
* semiadmin functionality now works for slaves
* rcon may now mute/unmute specs

===Connect the slave===
Now start your slave server by running ettv.x86

Tell the slave server to connect up to the master server:
:<tt>tv connect master.ip.address:port ettv_password(required) g_password(if the master has a g_password set)</tt>

If you have configured everything correctly, the slave should connect to the master.
Clients should now be able to connect to the slave and spectate the game in progress.

This is a "live broadcast" with no delay.

===Disconnect the slave===
To tell the slave to disconnect from the master:
:<tt>tv disconnect</tt>

===Slave Chaining===

==== What is chaining and why chain slaves? ====

ETTV allows chaining slaves together. This very neat feature lets you connect one ETTV slave to another ETTV slave that is broadcasting a match instead of directly to the game server hosting the match. Apart from the "w00t this is very cool" factor, why is this feature so important for admins? Basicly, working in a chained model allows to broadcast a match to a large number of spectators without too much hastle and too many risks for the master server.

Chaining was developped for a simple reason: if you take into account that one ETTV slave connects at an '''unlimited''' rate to a master, you really don't want to connect 15 or 20 slaves to a game server to broadcast let's say the ''Atlantic Battle''. Chances are you will bring down the master game server and thus the game. Chaining slaves firmly alleviates the load on the master game server. 2 or 4 of these ''Hubs'' can do the job of delaying the signal and feeding it to other slaves.

Other benefits might include better network performance. If you can choose to either connect your slave to the game server where your connection is not optimal or to a nearby slave who is on a better connection to the master, it might help the quality of your broadcast. Plus you don't need to record anything when connecting to a delayed slave.

==== Setting up your slave to allow connections from other slaves ====

This part is actually pretty easy. You need to set up your slave as if you were setting up a master game server. This means that, next to the normal slave parameters, you have to set up the following:

* '''b_ettv_flags''': set this to at least 1
* '''ettv_sv_maxslaves''': set this to at least 1. Depending on how powerful your machine is you can set this number higher. Don't set it too high though, a slave still connects at an unlimited rate
* '''ettv_password''': set to something else than "". This password is needed by the slaves connecting to your slave (together with g_password of course)

Other settings such as ettv_netblast, ettv_tv_iptos etc... can be set as well. You can even use autorecord if you wish, or just add an extra delay.

==== Pitfalls ====

There are however a few risks associated with slave chaining. One of the biggest issues is '''PK3 dependancies'''.

As you know, a slave needs to have at least all the PK3s of the server it connects too. But a slave can have more PK3s installed, as long as it has the ones on the server's pure list. This is what complicates things! The further you go down the "chain", the more the chances exist of PK3 pollution, which makes the job of the last slave very hard. And the viewers connecting to that slave will not be very happy either.

So for those of you venturing into chaining slaves here's a rule of thumb: '''always keep the installed PK3s to the bare minimum'''! Do not add stuff you do not need. If you want to know what PK3s you need and not need, connect your slave to the master or the hub, see which PK3s are on the pure list and rename or remove the PK3s that are not on the list. You will make your viewers and other admins connecting to your slave very happy.

Another risk could be '''chained lag'''. If one of the slaves that is higher in the chain starts lagging, the consequenses for the slaves depending on it will be seen immedeatily. So if you offer to be one of the higher slaves in the chain, make sure your machine can handle it! An ETTV chain is much like the food chain ;-).

==== Admin contributions ====

If by now you feel like getting your hands dirty in ETTV chaining madness and you want to see some example of hubs, slaves, broadcasters and scripts to get it all working, you can already start by checking out [[User:Deej|deej's page]].

==ETTV Demos==
ETTV can record and playback '''ETTV demos'''. ETTV demos have the extension .tv_84 (or .tv_83 for older versions) and are completely different from the .dm_84 demos recorded on clients.

You may record the match in progress to a file, with the command:
:<tt>record <'''demo name'''></tt>
If you omit the demo name, ettv will start recording using a filename of demoXXXX where XXXX is the first available number starting from 0000.

Demos will stop recording when a map changes.

To stop recording a demo:
:<tt>stoprecord</tt>

To play back a recorded demo:
:<tt>demo <'''demo name'''></tt>

To check the status of an ettv slave:
:<tt>tv status</tt>
This will tell you if the slave is connected to a master, or if it is currently playing back a demo.

To fastforward a demo:
:<tt>ff <seconds></tt>
Eg <tt>ff 30</tt> will fast foward 30 seconds. Fast forward stops at map restarts, so you can safely ff 999 to fast forward through a warmup.
:''note'': requires ettv beta 7 or later

===Autorecording demos===
ettv is able to automatically continuously record demos, creating new demofiles when the map changes. To do this, set the cvar ettv_autorecord to 1. ettv will start recording demos with the name demoXXXX where XXXX is a number starting at 0000 and incrementing on each map change.

Server admins may find it useful to use the demo recording feature of ettv to record matches, instead of requiring individual players to record them. An ettv demo records everything that happens on a server, including all player viewpoints.

===How to create demo based delayed feeds===
Autorecording demos is the first half of the process for delayed feeds. Typically you would run a passworded slave server with the smallest number of sv_maxclients possible. No spectators should connect to this server. The only purpose of this slave is to connect up to the master and record the match to sequentially numbered demofiles.

Now start up a slave, and tell it to broadcast the demo being recorded.

:<tt>demo demo0000</tt>

If you wait approx. 60 seconds after the master begins recording before issuing this command to your slaves, then you have a 60 second delay on your broadcast.

If you want slaves to automatically switch to the next demo when the end of the demo is reached (eg on a map change), you would set the cvar ettv_autoplay to 1. If a slave is playing demo0000 and it reaches the end, it will then try to play demo0001 and so on.

Disadvantage of this method: It is not automated in ettv itself, though admins can script it.
Advantage of this method: You may run multiple broadcast servers from the same single demo stream.

Automated delayed feeds are supported in ettv beta 8. See the above.

===Playing back previously recorded ETTV demos===
This is essentially the same as delayed feeds above.
* Configure your server as described in [[ETTV:Server_Configuration#Installation_-_.22Slave.22_.28broadcast_server.29|Slave Installation]] section
* Obtain the <tt>.tv_*</tt> demos and place them in <tt>''fs_game''/demos</tt>
* Start the ettv executable with pb disabled
* <tt>set ettv_autoplay 1</tt> if you want to play back sequential demos named <tt>demo0000.tv_84</tt>, <tt>demo0001.tv_84</tt> etc.
* <tt>demo '''<yourdemoname>'''</tt>
* connect a client and enjoy the show!

==Troubleshooting==

* The slave server must be running the same fs_game setting as the master server.
* The slave server must have a copy of every map pk3 the master server is using.
* If the master server loads a map the slave server doesn't have, the slave will get stuck.
* Spectators will be forced to download any custom pk3 you are using.
* It is a good idea to keep the master server pk3 list to a minimum.
* If you are using the autorecord/autoplay feature for running delayed feeds, you will usually want to make sure you clear out the demos directory first. Autorecording will start numbering demofiles using the first available number, so if you have old recorded demos then ettv might start recording from eg demo0017. If your scripts expect to start playback from demo0000 then you might end up broadcasting a game recorded at some earlier date...
* If the broadcaster constantly reloads on round starts etc, it's probably a problem with too many pk3s on the ettv servers.

==Miscellaneous==

Slaves may send chats to the master with the command msay
Slaves may list players on the master with the command players

==Performance tuning==

Spectator servers with large numbers of clients (eg >100) will push the OS very hard with huge amounts of UDP traffic. The default OS buffer settings for Linux are inadequate and can hurt performance, causing lag and/or disconnects.

If you get messages like
:<tt>NET_SendPacket ERROR: No buffer space available to 192.168.120.142:27960</tt>

Then you definitely need to increase your kernel network buffers.

Large spectator servers should increase the kernel buffers.

The following commands should be issued as root on linux:
:<tt>echo "524288" > /proc/sys/net/core/rmem_max</tt>
:<tt>echo "524288" > /proc/sys/net/core/wmem_max</tt>

FreeBSD can try this:
:<tt>sysctl -w net.inet.udp.recvspace=65535</tt>
:<tt>sysctl -w net.inet.udp.maxdgram=57344</tt>
:<tt>sysctl -w kern.ipc.maxsockbuf=8388608</tt>

===Network tuning cvars===
;The following are only available in ettv beta 7 and later.
By default, et uses small packets of 1400 bytes or less to send to clients. If messages need to be larger, they are 'fragmented' and sent over several server frames. ettv slave messages tend to be large and often fragment. ettv normally tries to send slaves all fragments at once to avoid jittery playback, but some networks / OSes handle this badly. ettv beta 7 introduces new controls so admins can optimize ettv for their individual network.

'''ettv_netblast''' (default 1)
:by default, ettv tries to send all fragments at once. some networks may handle this badly. setting this to 0 disables. warning: setting this to 0 without increasing ettv_mtu will result in severely laggy slave playback.

'''ettv_mtu''' (default 1400)
:; master only
:if your network / os supports it, you can set this to large values (eg 16000) to prevent message fragmentation and provide smoother ettv links. this cvar has no effect on normal ET clients.
:''note'': ettv_mtu must currently be set from commandline, it cannot be changed on the fly (yet).

'''ettv_tv_iptos''' (default 0)
:you can set the ip type of service field of ettv link packets. if your network/ISP supports it, you can use a value like 16 ("minimize delay") to prioritize ettv link packets over others on the network.

'''ettv_sv_iptos''' (default 0)
:same as ettv_tv_iptos, but affects packets for normal ET clients.

[[Category:ETTV]]