Start of Spikester buffer: Sat Jan 06 03:03:49 2007 Session Ident: Spikester (David@host86-131-91-169.range86-131.btcentralplus.com) 00:41] i've made some changes which u noticed to mvdsv, but dunno is that enought to be compatible with last qtv 00:42] I'll start up a qtv 00:42] which port i must use 00:42] ip / port? 00:43] mmm 00:43] qtv_mvdstream 00:43] or how itcalled 00:43] last time u tell me 00:43] any so long as its not in use. :) 00:43] qtv itself defaults to 27599 00:44] but last time u tellme 00:44] set up some variable 00:44] i'm forget which one 00:44] but remmber it was some port related 00:44] mvd_streamport 27598 is what I said last time 00:44] :> 00:44] yea 00:44] use it? 00:44] yup 00:44] and tell me ip 00:45] 85.113.202.12 00:45] QTV server sent no begin command - assuming incompatable 00:46] again something with thouse parsing functions? 00:46] i've got 00:46] MVD streaming client connected from 86.131.91.169:3699 00:46] qtv, got (VERSION) ( 1) 00:46] qtv, got (AUTH) ( MD4) 00:46] qtv, got (AUTH) ( CCITT) 00:46] qtv, got (AUTH) ( PLAIN) 00:46] qtv, got (AUTH) ( NONE) 00:46] Smile, you're on QTV! 00:46] Server recording canceled, demo removed 00:47] 554 if (p->hasauthed == true) 00:47] 555 { 00:47] 556 e = ("QTVSV 1\n" 00:47] 557 "\n"); 00:47] 558 send(p->socket, e, strlen(e), 0); 00:47] 559 e = NULL; 00:47] 560 SV_MVD_Record(SV_InitStream(p->socket)); 00:47] 561 p->socket = -1; //so it's not cleared wrongly. 00:47] 562 } 00:47] change the e = ("QTVSV 1\n" "\n"); line to e = ("QTVSV 1\n" "BEGIN\n" "\n"); 00:52] check it 00:52] okay, connects 00:52] buffering, etc 00:54] yeah, I can see a player on there 00:54] :> 00:54] zu-zu, apparently 00:54] its me 00:54] %) 00:54] say something, move, etc 00:55] well, you're better at bunnyhopping than I am.. 00:55] and your teamsays come through when spectating you 00:56] k 00:56] now disconnect. : 00:56] :> 00:56] :) 00:56] thx 00:57] hrm 00:57] proxy got booted 00:58] did you kill the server? :/ 00:58] no 00:58] just reloadlevel 00:58] ah, okay 00:58] switch to dm3 00:58] well, the proxy auto-reconnects, so not a major issue 00:58] :> 00:58] might miss the start of a match, but meh 00:59] hrm... 00:59] well, I've spotted a bug in the proxy itself.. 01:00] heh 01:00] ents from the previous map are still present 01:00] but with the wrong model indexes 01:00] this is as well as the ones from the current map 01:01] may be that a server bug? 01:01] I bet they'll disapear correctly if the server sends new ents out with those numbers 01:01] nah, the server disconnected 01:01] a quirk, but not an actual bug 01:01] :> 01:01] its qtv that has the problem. :p 01:02] :> 01:02] I just need to wipe the entity frames when a new svc_serverdata is received. 01:03] k 01:03] bug should be fixed, but I won't know until next map change 01:04] go to dm4 :) 01:04] ok 01:05] woo, okay, no extra ents 01:05] thanks 01:05] btw 01:05] my'n clientgotSmile ur areon qtv 01:05] my'n client got Smile ur areon qtv 01:05] not in server console 01:06] yes 01:06] but in client 01:06] but i am not on qtv 01:06] i amdirectly on server 01:06] right? 01:06] you're on the server, yes 01:06] why i got this message 01:06] ahhh 01:06] which is being relayed to a qtv proxy somewhere (mine) 01:06] that message droadcasted 01:07] I can see your player through qtv. that's what its about 01:07] :} 01:07] ok 01:07] got it 01:07] %) 01:08] yeah, I suck at quake 01:08] heh 01:09] u play not much :| 01:09] i know onlyone: good programme can;t be good quaker %) 01:09] programmer 01:10] i am something like middle skilled quaker, and middle skilled quaker :| 01:10] I'm a total n00b. :p 01:10] heh 01:11] wish u be n00b in programming %) 01:11] although having said that I can own anyone I meet in real life, just never anyone online 01:11] :> 01:18] so, thatall for now, seems it working? 01:18] can you disconnect from the server please? 01:19] I wish to see what it does. :) 01:19] :> 01:19] mmm 01:19] will be map change immidiately 01:19] proxy will bedisconnected? 01:19] so doubt u will see anyting 01:19] yeah, but should be able to reconnect on the next map. 01:19] ok 01:20] lets see if I get the ents or not 01:21] okay, it shows the map 01:21] but with no entities at all 01:21] but its at least keeping sync 01:21] which is the important thing 01:21] what happens when you connect now 01:21] ? 01:22] okay, cool 01:22] everything appears 01:22] :> 01:23] its reasonable behaviour at least 01:23] okay, cool 01:23] do you want to commit your changes? 01:23] sure 01:24] commit it now? 01:24] I need to make qtv more user friendly. :( 01:24] yeah, might as well, depends what other changes you have. :p 01:24] thanks by the way 01:25] have only qtv changes %) 01:27] hrm 01:27] qtv 85.113.202.12:27598 01:27] Source registered 01:27] Connection established, buffering for 10 seconds 01:27] Gamedir: qw 01:27] --------------------- 01:27] The Dark Zone 01:27] --------------------- 01:27] Not enough buffered 01:27] Not enough buffered 01:27] Not enough buffered 01:27] Not enough buffered 01:27] Not enough buffered 01:27] Not enough buffered 01:27] interesting.... 01:27] no more prints, but still... 01:27] probably i has shity connection 01:28] here is night, and everyone start dl-ing 01:28] hrm, not sure... 01:28] some weird pl 01:28] that shouldn't make a difference, as its tcp/ip 01:28] lol 01:28] actually, I take that back 01:28] either way, its not saying it any more 01:29] suggests that the qtv is now relaying realtime. :/ 01:29] meh 01:29] :> 01:29] now... ezquake fun-ness 01:30] what do u mean? :P 01:31] http://localhost:27599/nowplaying.html 01:31] the http web interface to the proxy is a bit ugly... 01:31] but the qtv files that it serves up are meant to be final 01:32] ah, bum, localhost... 01:32] localhost 01:32] :> 01:32] hang on.. 01:32] okay 01:32] http://spoike.servebeer.com:27599 01:34] it would be most awesome if you adapted ezquake to be able to open one of these qtv files from web browser (or irc!) and connected to the stream 01:35] *from a web browser 01:36] mmmm 01:37] that qtv file actually for qtv proxy? 01:37] its for both really 01:37] more for the client though 01:38] seeing as the easy way to use a proxy is to point a web browser at it and choose the stream using a webbrowser, the client has to be able to accept the qtv file and start playing it 01:38] weather through a proxy or not 01:39] (fte actually connects directly, like I heard talk of ezquake intending on doing) 01:39] as i understand ezquake start qtv as background process 01:39] at current state 01:39] yes 01:40] fet doing the same? 01:40] fte 01:40] or qtv code incapsulated in client 01:40] ? 01:40] the stream itself is just mvd at the moment (hence the version info handshake I added) 01:41] so connect with a tcp socket, send some handshake info, and you've got an mvd stream sent to you just like in an mvd demo 01:41] the qtv code mostly concerns chopping up bits of mvds and converting to qw protocols and stuff 01:41] u mean we may not use qtv for that reasons 01:42] you probably want to add direct qtv playing for the multiview code that ezquake contains 01:43] direct qtv playing 01:43] which is not possible by using a local qtv proxy to convert the mvd stream to qw protocols 01:44] ah, yea, we connect to qtv proxy via qw protocol 01:44] so yea, we need grab mvd stream somehow 01:45] well, that .qtv file gives you streamid@ip:port to use. 01:46] so client may connect to some qtv and select proper stream? 01:46] even with qw protocol 01:47] its slightly different 01:47] with qw protocols the user is brought to a qizmo like start map 01:47] (unless there is only a single game being played, in which case the client is brought into that game immediatly) 01:48] with the tcp stuff, the client must tell the proxy which stream to use as part of the handshake when connecting 01:48] but you can query the current streams if required 01:50] so u can conect to qtv, query stream, popyp some select menu, where user select desired stream and play it 01:50] yes 01:50] (I'm not sure how much info about the streams qtv actually gives at the moment, so I might need to make it a little more verbose some time) 01:51] instead of clicin from browser i prefer select stream from quake 01:51] that way more ez to implement for me %) 01:51] heh 01:51] atleast for now 01:51] sure, but if you dont do the browser thing, I can't say: hey, this game is ace: http://spoike.servebeer.com:27599/watch.qtv?sid=5 01:52] :> 01:53] clicking that link in an irc client brings up a web browser, which downloads the file, works out what to open it with (a quake engine) and starts up the quake engine with the filename as a parameter. the quake engine opens the file, reads the server to connect to, and connects automagically 01:53] yea 01:53] so while it sounds longwinded, the user isn't aware of anything other than clicking the link and thier qw client playing the game. 01:53] i understand 01:53] which is the main reason for the web interface. :) 01:54] so, at least currecntly i can add connect via ordinar qw protocol? or not? 01:54] thouse 01:54] Stream: 5@spoike.servebeer.com:27599 01:54] 27599 01:54] basicaly tcpport? 01:54] basicaly tcp port? 01:55] yes it may be udp port, but basicaly that tcp port 01:55] that stream gives a tcp port, which is not always a valid udp port 01:55] yea 01:55] in this case it is, but its not guarenteed 01:55] i read some time ago qtv faq 01:56] firewalls, or even the proxy config might break that rule 01:56] actualy qw protocol is more like for compatibility 01:56] yes 01:56] so 01:56] i need add smal parser 01:56] for .qtv files 01:56] and add grabbing data from tcp socket 01:57] with small a bit of shaking 01:57] yeah 01:57] for now you can just pass it over to the qtv proxy 01:57] actually steal that from fte 01:57] :) 01:57] no 01:57] fte uses its VFS stuff, and treats the stream as a file. :) 01:57] i want steal that 01:57] from fte %) 01:57] hehe 01:58] socket is a file 01:58] only in linux 01:58] almost 01:58] oh 01:58] :< 01:58] and unix 01:58] but not on all unix-like operating systems 01:58] and definatly not in windows 01:58] that not really a porblem 01:58] and not if you're trying to read the file from a pk3 either 01:59] i just relpace vfs read functions with socket 01:59] functiosn 01:59] functions 01:59] read seek what ever u use 01:59] fte's virtual files are a structure with a load of function pointers 02:00] so you'd need to replace them with a small function that reads from either a socket or a file, depending on weather you're playing from a qtv source or an mvd demo 02:01] additionally, fte's sourcecode is further obfuscated by its q2 demo format, and the fact that fte does not derive from fuhquake 02:02] but yeah, add support for qtv connections in the engine and multiview some live games. :) 02:02] as i understand, i need establish tcp connection, than shaking, then just read from socket 02:02] than = thenb 02:02] than = then 02:02] yeah 02:03] alternativly you could request a raw connection 02:03] where the data you receive back will contain no header 02:03] not qtv addon? 02:03] just mvd? 02:04] yeah 02:04] "QTV\n" "VERSION: 1\n" "RAW: 1\n" "SOURCE: %s\n" "\n" 02:05] if you send that at a qtv proxy, you'll get a raw mvd stream 02:05] %s 02:05] what is that 02:05] printf notation. :p 02:05] you need to fill in a stream there. :p 02:05] the bit from the left of the right-most @ in the qtv file 02:05] Stream: 5@spoike.servebeer.com:27599 02:06] '5' in that case 02:06] without quotes 02:06] in that case 02:06] other cases? 02:06] demo:test.mvd 02:06] for example 02:07] nice 02:07] you can ask the proxy to relay from annother proxy 02:07] so this is also valid: demo:test.mvd@somewhere:27599 02:08] note that in that case, your qtv file would contain demo:test.mvd@somewhere:27599@spoike.serveb eer.com:27599 02:08] so yeah, you need to pay attention to the right-most @ 02:12] so, to get server adress i get right most @ 02:12] yes 02:12] and pass left side to proxy 02:12] yes 02:13] do u have some .reg file to assign fte to .qtv file ? 02:13] I don't 02:13] heh 02:14] that not matter %) 02:14] when you open the qtv file, it'll ask which program you want to run it with. just select a recent enough version of fte 02:14] linux is more awkward, no doubt 02:14] but windows is simple enough 02:15] what you have to be aware of is that the filename will be the only commandline parameter 02:15] and that the others -width, etc will need to be provided elsewhere 02:15] at least if you use that method 02:15] :> 02:15] in fte thats not so big an issue as the config files specify video width, etc instead of the commandline 02:16] yea, i know 02:16] commandlines suck. :p 02:16] sure is 02:17] you could also expand the format to support qw games too... 02:18] yeah, add join, and observe too. but make them use qw protocols. :) 02:18] hehe 02:19] to be honest, I've no idea why FTE doesn't already do that. :/ 02:40] oo 02:40] annother thing I'd like you to add 02:40] ? 02:41] I want a prox_inmenu cvar which execs different stuff when the +forward / +back / +right stuff are pressed 02:42] not sure exactly what it should do yet... 02:42] probably something qizmo compatable 02:43] I also want it so qwcl doesn't moan about a 'set' command, so it must also accept "//set prox_inmenu XXX" if sent from the server 02:43] that should make qtv's menus muuuch easier to use 02:44] 02:43] I also want it so qwcl doesn't moan about a 'set' command, so it must also accept "//set prox_inmenu XXX" if sent from the server 02:44] it moan? 02:44] what 02:44] the set command doesn't exist in qwcl 2.33 02:45] so if the server stuffcmds it, the client will print on the console 'command "set" not recognised' 02:45] which is messy 02:45] u warry about qwcl2.33? 02:45] yes 02:45] why? 02:46] mqwcl is similar to qwcl2.33 02:46] ah 02:46] and I might as well use //set 02:46] wait a moment 02:50] I want +forward, +back, +moveleft, +moveright, +left, +right to all control the proxy menu in a way that does not require changes to configs 02:50] having to rebind keys is absurd 02:51] having to write a config to rebind keys is also absurd 02:51] for older clients, qtv stuffcmds +proxfwd +proxback etc 02:51] the downside of this is that it still needs a bind, and needs to be put in configs, etc 02:53] so if those buttons are pressed when prox_inmenu is set to 1, they should trigger the relevent 'proxy:menu down' say 02:57] 02:43] I also want it so qwcl doesn't moan about a 'set' command, so it must also accept "//set prox_inmenu XXX" if sent from the server 02:57] u sure? 02:57] because // is a comment 02:57] yes, which is why I want to use // 02:57] mqwcl 2.33must ignore it? 02:58] as comment 02:58] because it won't be seen by the command execution in qwcl, and mqwcl 02:58] so, where the problem? 02:58] ezquakeignore it too ? 02:58] ezquake ignore it too ? 02:58] ezquake doesn't support //set yet 02:59] and doesn't support a prox_inmenu cvar either. :) 02:59] that allnot hard atall 03:00] a prox_inmenu cvar is harder though 03:01] aproximately thiswilltake 10 years of coding 03:01] lol 03:01] :> 03:01] joke 03:01] but we will be ready to next qw anniversary 03:02] lol End of Spikester buffer Sat Jan 06 03:03:49 2007