Johnny_cz, the answer is simple, it's still not easy to spectate. Haven't seen a crashing qizmo either
If the proxy that you're connecting to is set up correctly, just connect to it like any other qw server, as qtv is able to translate protocols as required. It can even appear on master servers/ase just like qizmo can. I'm thinking about making it default to doing this by default.
Otherwise, if the proxy isn't set up to accept qw clients, easiest way is to download fteqw and type 'playqtv 1.2.3.4:1234', you don't even need the qtv proxy installed locally.
Claiming that it's hard to spectate a game isn't a well founded argument.
On the other hand, claiming that the qtv proxy is horrendously buggy, a pain to configure properly, lacks documentation, lacks nearly everything you want it to do, and burns cpu cycles, then you might have an argument. :p
Recent changes:
1: Spectators are able to use a '.qtv' command (via say) once connected to instruct the qtv proxy to connect to an additional source. '.demo' too.
2: Hopefully works on debian. :p
In development:
1: Password protected proxys (preventing home users from connecting 20 proxys to the game server). Only bit left is the proxy's server componants (in-dev fteqwsv supports it). Warning: current proxys will be incompatable with future servers (but current servers will work with future proxies unless a password is actually required).
2: Proxys using a single tcp port for multiple games (making the .qtv command more useful). I'm not sure if this'll make things easier or harder though. It will allow a 'currently playing' listing though. Coupled with 1, this will allow all sorts of funky extra features in the future.
3: Protocol version negotiation.
4: a .qw command allowing a spectator to to connect to an unmodified qw server from the pov of the player with the most frags. This is working, but has a few packetloss issues still, also doesn't currently chain or delay to other spectators.
5: .join, allowing a player to play through the proxy and broadcast their game.
Future plans:
1: Protocol changes to allow commentry.
2: World domination.
3: Getting ezquake team to support proper interpolation, and running at 20 packets-per-second.
4: Encouraging server admins to allow proxy admins to connect, without exposing to less usable home user proxys that noone can connect to.
5: Extending the on-proxy menus.
6: Getting an agreement on common, standard extensions to the underlying mvd protocol.
7: On-Proxy demo player/chooser.
8: Getting enough time and motivation to actually work on it again.
Wow, that was a long post.
News