FTE Quake TV demonstration pack
2005-09-24

Installation:
- Extract this pack to your Quake dir and; QTV dir will be created
- move any MVD file to the QTV dir and rename it to 'test.mvd'
- run the two bat files inside the QTV dir

Usage:
broadcast.bat
- plays a demo, listens on TCP port 27500, and chokes client
  bandwidth (expecting clientside interpolation)
- this configuration is expected to run on server side

receive.bat
- listens on UDP port 27500, and connects to local TCP port 27500.
- this configuration is expected to run on client side

Run both .bat files and start your QuakeWorld client and type:
/connect localhost

Proxy has remote console support. You are expected to alter the 'password'
lines in your receive.cfg/broadcast.cfg to e.g. 'password 12345'.
Type 'help' in proxy console to see list of available commands.

The two seperate proxies is primarily for the sake of demonstrating
the chaining.

Edit broadcast.cfg to give it a different demo file name (one that
you actually have).

Alternativly you can edit prox.cfg and direct it at a cvs-built version of
FTE, using port specified in fte with mvd_streamport.




The above user-friendly documentation and sample files written by JohnNy_cz.

The following user-murdering documentation was written by Spike.



Note that fteqtv is just a qtv proxy made by the fte team.
The thing works by transfering mvd files over tcp/ip. The result is a reliable buffered connection, providing smooth action. The tcp protocol is purly an mvd. You can connect with a simple tcp client and remotly record your own mvd from it.

The proxy supports chaining (bar bugs). Use the tcpport option to set a port for the proxy to listen on for other proxies. You can connect to annother proxy as you would a server.

The QuakeWorld protocol it uses is qwcl2.33 compatable. It should run with all known standard quakeworld clients. However, there are some gotchas.
Firstly: maximum entities-per-packet limits. QuakeWorld has a maximum of 64 entities per packet. This means that if you want to see the entities properly, you will need to provide the proxy with a copy of the map's bsp file. This allows removing all the non-visible entities like a regular qw server would do, and the limit is bypassed. It should also help with bandwidth for regular qw clients.
Secondly: there is a 'choke' option. This option makes the proxy only send out new packets when the mvd updates them. This is a pure bandwidth optimisation. However, this results in most qw clients giving very jerky performance. If you have an overloaded proxy, it will help to set this, but some spectators with outdated clients may become annoyed. There is no eta on when there will be a perfectly smooth client when using this feature. FTE is closest as of writing, same-country proxies should be fine, but further connections may suffer.
rcon is functional. It doesn't allow certain settings to be changed (like the password). It doesn't allow relative paths to demos using rcon. Configs do allow these.

It is still in development. Development releases are only provided for windows, but if you're comfortable with compilers, you should be able to compile a copy for linux and presumably mac. Current sourcecode is included (it's hardly large).








I would say the following part was a 'faq'. However, at this point in the development, 'Frequent' doesn't apply. Also, seeing as noone has actually asked them, and I'm just giving hypothetical issues, the 'Asked' part doesn't really apply either. Luckily, they do still count as questions. So...

The __Q section:

What license is this released under?
	fteqtv is released under the terms on the GNU GPL, which you should find documented inside gnu.txt.
	It contains some sections of code found inside the quake engine.
	The bulk of the new code was written by Spike. He is also a fan of the GPL, so no asking for non-gpled bits and pieces.

Why .mvd why tcp?
	mvd is an easy to parse relativly small format. It contains only simple deltas (due to certain expectations of the parser). It is also very close to standard qw protocols. It also has timing built in (meaning decent parse delays).
	mvd is common-place. A proxy that communicates with mvd is better able to record mvd, as well as play mvd as a substitute server for group spectating.
	tcp is used because it's a reliable (mostly) efficient protocol. It's also easy to set up. tcp however is famous for stalling. Hopefully the data transfers are small enough and steady enough that stalling doesn't become a huge issue. The proxy has built-in buffering too, which will mean that cumulative stalls result in the proxy becoming more tollerant of them.

Which servers does it support?
	Personally, I believe this question ought to be the other way around.
	As of writing, FTE (builds greater than 2460) is the only server that supports this.
	To allow a proxy to connect to an FTE server, you will need to set the mvd_streamport cvar in fte to a usable tcp port.
	You can then connect a proxy to that port.
	The mvdsv team are intending to add support. I do not know the current state of that. I assume it'll work using the same cvars as FTE.

	There is not yet any password protection on connecting proxies.
	This is a testing/concept release. Setting the mvd_streamport will open up your quake server to an easy DoS attack. This will be fixed at some point, note that this release will then be unable to connect to passworded servers.

How is it so friggin tiny?
	Releases made by Spike are compiled with gcc. They are also upx compressed, just to make a point of how simple a proxy can be. Okay, so size isn't complexity, but tell that to my ego.
	To be honest, it is fairly large. It communicates mvd, qwd, supports loading bsps and paks, so it does have a fair ammount of code.
	The fact that it's documentation is over half of it's size is somewhat worrying.

Why is it not just called 'qtv'?
	The quakeforge guys are still around, and still seem to be writing a proxy too, the fte prefix helps avoid any naming conflict if they release.

Why does the proxy only accept the name of a cfg on the commandline, why does it not accept quake's '+' commandline notation?
	Simplicity in the code.
	Note that the proxy will attempt to load ftv.cfg if no config was named.

What's this 'choke' feature?
	The choke option is a way to conserve bandwidth. Most mvds are recorded at 20 'frames' per second. We don't expect a different default with qtv chains.
	QuakeWorld clients tend to run at 72 packets per second. This means that 52 out of 72 packets result in proxy-side interpolation. This does give a smooth game, yeah, however, it's a lot of wasted bandwidth.
	The choke option stops the proxy from sending entity states without an mvd frame. This results in jerky spectating. This is ideally fixed with a new client, but we still have to write one that copes properly with it.

What's this 'late' feature?
	The proxy is chainable, this means you can connect one proxy to annother proxy to annother proxy to the game server (or a proxy playing an mvd).
	To cut down on latency, each proxy forwards it's received information immediatly.
	The proxy then buffers the incoming data for 10 seconds before it starts reading it.
	This leaves a window for cheating (by secretly spectating your opponant). This will be more effective if you're close to the server.
	The late forwarding option basically delays when a proxy forwards a message to when it parses the message itself. This prevents any cheaters, but results in an additional delay, of course. Unfortunatly, this is the only guarenteed solution to this problem. The first of the proxy chain should use this option, but no child proxies should.

Why does the proxy by default try connecting to tcp localhost:27500 ?
	To make it easier for server admins already running qw servers.
	Well, that's the theory at least.
	It might as well try connecting there because that's more probable than anywhere else.
	You should be able to override this behaviour with a config. Currently the proxy does not support not attempting to connect.

Can I change the ports the proxy listens to?
	Yes, mid-level even.
	You won't loose child proxies, but all qw clients will eventually time out.

Why is this part of the readme not capped to a line length?
	Because Spike has a 1600*1200 moniter and expects people to have word wrap enabled because that leads to the most economical screen-space usage.

How does the proxy load bsps?
	BSPs are needed to avoid the maximum of 64 entities in the quakeworld protocol.
	The proxy is able to look in the working directory for id1/pak*.pak and qw/pak*.pak. It'll also look in the gamedir stated by the server.
	It is able to read from the maps as well as from inside the pak files.
	If you run it from the same directory as you run a qw server, you should be fine.
	The proxy will work without the relevent bsp, but many (complex) maps will exhibit visibility problems without the bsp.
	you can disable bsp loading (and possibly save some loadtime) by using this command (via console, config or rcon):
	option nobsp 1

How does the hostname work?
	There is a hostname option.
	The proxy's hostname is inserted first, and the origional server's hostname is inserted after, inside brackets, with the server type (demo/live).
	The proxy is currently unable to change the  displayed hostname mid-level. You can either reconnect, or wait for the game to change levels.

How do I set a proxy to use the qw master servers?
	use this, either via config, 'console' or rcon:
	option master 192.246.40.37:27000
	That will make your proxy appear on the 'id Limbo' master server. Remember to give your serverbrowser time to update.
	The proxy only supports using one master  at a time.

Are there any spectator/child-proxy limits?
	No. Not yet. These are on the todo list, and should be fairly trivial. Until then, the proxy will allow as many connections as you have the memory, cpu, and bandwidth for.

How well does on-proxy chatting work?
	Chatting is not chained. Chatting on one proxy is visible only to other clients on that proxy. Clients connected to child proxies will not currently see the message.
	Instead of a : in the chat message, a right-facing arrow is used instead. This is to avoid confusion between other spectators and the players themselves.
	Spectators using f_version etc will not recognised by all tested clients.
	There is no flood protection yet.
	But there is a proxy option to block ALL spectator chat.

Why is there no quit command?
	Because quitting is for loosers. Get a backbone. Learn some general computer use. Understand that ctrl+c is just as good. :p

What happens when the proxy is still connecting/buffering? Can I connect at this time?
	Not much happens during this time. The proxy will reject new connects, and will start to time out current qw clients. This does prevent the client from loading too many times, of course. Current qw clients will be sent a gamestate as soon as the proxy has finished parsing it.
	Other proxies are accepted, but no connection info will be sent to them until the proxy has received the entire gamestate.

What about FPS limiting?
	The proxy doesn't currently offer a way to change the fps cap. The proxy doesn't test for it either, of course. Mostly a spectators movement commands will be ignored totally. We would rather clients use independant physics and interpolation than to send high packet rates to the proxy, as this will allow more spectators. We request that client maintainers have respect for other people's proxies.

How does the proxy keep playing even though it got a read error/eof?
	The proxy uses buffering. It's connection closing (or ending) is not the end of the world. The proxy will continue reading it's buffered data, and reconnect to buffer some more. In the case of files, the proxy will just fill it's buffers up.
	Due to the delayed parsing, the end-of-file message can often happen before the intermission. It's only a problem if the game stops or you get the in-game net icon.

Are there any memory leaks?
	God I hope not...

Can the proxy cope with corrupt input?
	The last time it crashed, it was fixed. Chances are that it'll try reconnecting (or restarting if playing from an mvd).
	I am reasonably confident that a corrupt mvd will not crash the proxy. I am not so sure about corrupt qw clients, however.

Are there any timer overflow bugs after 72 days?
	It's possible that the proxy will fail every 72 days.
	It's an awkward one to test. :p
	The proxy uses only ints (in miliseconds) to express time. There is no degredation after only a few days, you won't need to constantly keep restarting the proxy.
	Care has been payed to times in all instances. Hopefully it'll never be noticed. Failing that, hopefully it'll never be an issue. It is impossible for me to say that the proxy is perfect. At this stage of development, anything could happen.

How clean is the source code?
	Clean enough, depending on what you want to do with it.
	For instance, it'd be easy enough to split it up a bit into a library, and invoke it directly from inside a quake engine. Of course, most engines have mvd playback already, so the advantages of this are not so large.

What are the future plans?
	I don't know, the plans we devise in the future are in the future. I'm not a fortune teller.

What are the current plans for the future?
	Ahh, a correctly worded question.
	Aritificial limits on the numbers of servers/clients allowed to connect (a required feature).
	Working challenges (instead of always 4).
	Password protected proxies/servers (other than rcon password) (seperate qw/tcp passwords).
	Voice chat (/me dreams on).
	NQ client support (NQ servers are free to generate the required mvd tcp stream if they so choose, or you can use fteqwsv for most NQ mods).
	Perhaps q2/q3 bsp support, perhaps also pk3 support for loading bsps. These are supported by FTEQW already.
	Per-player chat blocking rather than per-proxy (both sending and receiving).
	floodprot.
	Support for chearing ?
	A udp alternative to mvd?
	motd
	fteqw advertising. :)
	Annoying other server maintaners into supporting the server->proxy protocol.
	Protocol extensions.

Why are there no more questions?
	Because it's 4:51 am. Just try and make me write some more fictional questions and then some helpful answers. See if you can.
	Snore zzzz....