You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(12) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(14) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(20) |
Sep
|
Oct
(13) |
Nov
(22) |
Dec
(3) |
2005 |
Jan
|
Feb
|
Mar
(3) |
Apr
(7) |
May
|
Jun
(13) |
Jul
(5) |
Aug
|
Sep
|
Oct
(15) |
Nov
(5) |
Dec
|
2006 |
Jan
|
Feb
|
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(3) |
Nov
(6) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
2008 |
Jan
(5) |
Feb
(6) |
Mar
|
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Pierre S. <pi...@un...> - 2008-02-18 22:32:51
|
Hello all, I've noticed that ETQWS seems to skip off the first few letters off a player name. See below for example. Hopefully this is a simple fix ? Not sure if this article is dated in regards to our implementation: http://community.enemyterritory.com/forums/showthread.php?t=4960 ./qstat -etqws 74.86.237.192:27733 -P -xml -d -d -d -d <?xml version="1.0" encoding="iso-8859-1"?> <qstat> debug(1) 22:15:59 qstat.c:4574 bind_sockets() - send 74.86.237.192:27733 debug(2) 22:15:59 qstat.c:4577 bind_sockets() - calling status_query_func for 0x8084000 debug(3) 22:15:59 qstat.c:4612 send_packets() - processing... debug(2) 22:15:59 qstat.c:2896 do_work() - connected: 1 debug(2) 22:15:59 qstat.c:5689 qserver_get_timeout() - timeout for 0x8084000 is diff1 1000 diff2 65535 debug(2) 22:16:00 qstat.c:2919 do_work() - rc 0 debug(2) 22:16:00 qstat.c:2981 do_work() - fill: 0 < 40 debug(3) 22:16:00 qstat.c:4612 send_packets() - processing... debug(2) 22:16:00 qstat.c:4655 send_packets() - server 0x8084000, name (null), retry1 2, next_rule 0x0, next_player_info 65535, num_players 0, n_retries 3 debug(2) 22:16:00 qstat.c:5689 qserver_get_timeout() - timeout for 0x8084000 is diff1 0 diff2 65535 debug(2) 22:16:00 qstat.c:4675 send_packets() - calling status_query_func for 0x8084000 debug(3) 22:16:00 qstat.c:4747 send_packets() - done debug(2) 22:16:00 qstat.c:3058 do_work() - connected: 1 debug(2) 22:16:00 qstat.c:5689 qserver_get_timeout() - timeout for 0x8084000 is diff1 500 diff2 65535 debug(2) 22:16:01 qstat.c:2919 do_work() - rc 0 debug(2) 22:16:01 qstat.c:2981 do_work() - fill: 0 < 40 debug(3) 22:16:01 qstat.c:4612 send_packets() - processing... debug(2) 22:16:01 qstat.c:4655 send_packets() - server 0x8084000, name (null), retry1 1, next_rule 0x0, next_player_info 65535, num_players 0, n_retries 3 debug(2) 22:16:01 qstat.c:5689 qserver_get_timeout() - timeout for 0x8084000 is diff1 -1 diff2 65535 debug(2) 22:16:01 qstat.c:4675 send_packets() - calling status_query_func for 0x8084000 debug(3) 22:16:01 qstat.c:4747 send_packets() - done debug(2) 22:16:01 qstat.c:3058 do_work() - connected: 1 debug(2) 22:16:01 qstat.c:5689 qserver_get_timeout() - timeout for 0x8084000 is diff1 499 diff2 65535 debug(2) 22:16:01 qstat.c:2919 do_work() - rc 1 debug(2) 22:16:01 qstat.c:2947 do_work() - recvfrom: 1588 debug(1) 22:16:01 qstat.c:2972 do_work() - recv 1508 1508 74.86.237.192:27733 debug(2) 22:16:01 qstat.c:2981 do_work() - fill: 1 < 40 FROM 74.86.237.192:27733 len 1588 0: ffff696e 666f5265 73706f6e 73650000 ..infoRe sponse.. 16: 000000ff ffffff13 000a0015 0600006e ........ .......n 32: 65745f73 65727665 7250756e 6b627573 et_serve rPunkbus 48: 74657245 6e61626c 65640031 006e6574 terEnabl ed.1.net 64: 5f736572 76657244 65646963 61746564 _serverD edicated 80: 00310073 695f7665 7273696f 6e004554 .1.si_ve rsion.ET 96: 51572031 2e342e31 32333335 2e333330 QW 1.4.1 2335.330 112: 34352020 77696e2d 78383620 4a616e20 45 win- x86 Jan 128: 31352032 30303820 31383a33 383a3337 15 2008 18:38:37 144: 0073695f 6d617870 6c617965 72730033 .si_maxp layers.3 160: 32007369 5f67616d 65526576 69657752 2.si_gam eReviewR 176: 65616479 57616974 00300073 695f6469 eadyWait .0.si_di 192: 7361626c 65476c6f 62616c43 68617400 sableGlo balChat. 208: 30007369 5f6e6f50 726f6669 6369656e 0.si_noP roficien 224: 63790030 0073695f 616c6c6f 774c6174 cy.0.si_ allowLat 240: 654a6f69 6e003100 73695f6d 696e506c eJoin.1. si_minPl 256: 61796572 73003600 73695f72 65616479 ayers.6. si_ready 272: 50657263 656e7400 35310073 695f6469 Percent. 51.si_di 288: 7361626c 65566f74 696e6700 31007369 sableVot ing.1.si 304: 5f61646d 696e5374 61727400 30007369 _adminSt art.0.si 320: 5f6d6f74 645f3400 0073695f 6d6f7464 _motd_4. .si_motd 336: 5f330000 73695f6d 6f74645f 32000073 _3..si_m otd_2..s 352: 695f6d6f 74645f31 00506f77 65726564 i_motd_1 .Powered 368: 20627920 5472696e 69747920 47616d69 by Trin ity Gami 384: 6e670073 695f656d 61696c00 68747470 ng.si_em ail.http 400: 3a2f2f77 77772e66 756c6c63 6f6e7461 ://www.f ullconta 416: 63747761 722e636f 6d007369 5f61646d ctwar.co m.si_adm 432: 696e6e61 6d650000 73695f77 65627369 inname.. si_websi 448: 74650068 7474703a 2f2f7777 772e6675 te.http: //www.fu 464: 6c6c636f 6e746163 74776172 2e636f6d llcontac twar.com 480: 0073695f 7465616d 466f7263 6542616c .si_team ForceBal 496: 616e6365 00310073 695f7469 6d656c69 ance.1.s i_timeli 512: 6d697400 32300073 695f7275 6c657300 mit.20.s i_rules. 528: 73644761 6d655275 6c657343 616d7061 sdGameRu lesCampa 544: 69676e00 73695f73 70656374 61746f72 ign.si_s pectator 560: 73003100 73695f70 75726500 31007369 s.1.si_p ure.1.si 576: 5f6e6565 64506173 73003000 73695f74 _needPas s.0.si_t 592: 65616d44 616d6167 65003100 73695f70 eamDamag e.1.si_p 608: 72697661 7465436c 69656e74 73003000 rivateCl ients.0. 624: 73695f6e 616d6500 46756c6c 436f6e74 si_name. FullCont 640: 61637457 61722046 756c6c20 526f7461 actWar F ull Rota 656: 74696f6e 0073695f 616e7469 4c616746 tion.si_ antiLagF 672: 6f726769 76696e67 00300073 695f616e orgiving .0.si_an 688: 74694c61 674f6e6c 79003000 73695f61 tiLagOnl y.0.si_a 704: 6e74694c 61670031 00626f74 5f656e61 ntiLag.1 .bot_ena 720: 626c6500 30006761 6d656e61 6d650062 ble.0.ga mename.b 736: 61736545 5451572d 31007369 5f63616d aseETQW- 1.si_cam 752: 70616967 6e006361 6d706169 676e5f6e paign.ca mpaign_n 768: 6f727468 6575726f 70650073 695f6d61 ortheuro pe.si_ma 784: 70006d61 70732f73 616c7661 67650073 p.maps/s alvage.s 800: 695f6361 6d706169 676e496e 666f0032 i_campai gnInfo.2 816: 20320000 00004a00 5e325a75 5e346c67 2....J. ^2Zu^4lg 832: 5e31696e 00000000 01480044 615f4669 ^1in.... .H.Da_Fi 848: 6e675200 00000002 ab005448 452d4255 ngR..... ..THE-BU 864: 54434845 522e554b 00000000 036a005e TCHER.UK .....j.^ 880: 48435e3c 485e324f 57444148 48455e3c HC^<H^2O WDAHHE^< 896: 415e4844 00010000 04bf0049 6c6f6769 A^HD.... ...Ilogi 912: 4b000000 00056000 5e315265 645e3f4d K.....`. ^1Red^?M 928: 6f726761 6e00005e 3d5b6462 635d5e30 organ..^ =[dbc]^0 944: 00000655 005e3173 6d6f6b65 5e376d5e ...U.^1s moke^7m^ 960: 34737200 00000008 ac005e3b 44726573 4sr..... ..^;Dres 976: 735e3754 6f5e3b4b 696c6c00 005e307c s^7To^;K ill..^0| 992: 5e3b7c5e 317c5e33 7c5e377c 5e300000 ^;|^1|^3 |^7|^0.. 1008: 09c10062 65727365 726b6572 30000000 ...berse rker0... 1024: 000ab700 444a5e39 50756e69 73686572 ....DJ^9 Punisher 1040: 00015e30 5b5e3842 6f6e655e 3768756e ..^0[^8B one^7hun 1056: 7465525d 5e300000 0b550050 697a7a61 teR]^0.. .U.Pizza 1072: 706f7461 6d757300 0000000c 59004d61 potamus. ....Y.Ma 1088: 78373036 00005e31 7b534346 44377d5e x706..^1 {SCFD7}^ 1104: 3000000d 36005e31 5377695e 3773735e 0...6.^1 Swi^7ss^ 1120: 34656400 005e312f 5e375f5e 345c205e 4ed..^1/ ^7_^4\ ^ 1136: 3000000e 56005e31 525e396f 6163685e 0...V.^1 R^9oach^ 1152: 314d5e39 6f00015e 313e5e3a 4275475e 1M^9o..^ 1>^:BuG^ 1168: 313c5e30 00000f4a 005e4163 68616e5e 1<^0...J .^Achan^ 1184: 3961626b 00000000 10550074 68697331 9abk.... .U.this1 1200: 00000000 11d00061 76693734 64697363 .......a vi74disc 1216: 6f000000 00123d00 5e316163 6c5e3969 o.....=. ^1acl^9i 1232: 5e317073 6100005e 392f5e31 5f5e395c ^1psa..^ 9/^1_^9\Sc1s sors 1248: 205e3000 0013b700 5e3b556c 746f725e ^0..... ^;Ultor^ 1264: 6b50484f 454e4958 00000000 14ab005e kPHOENIX .......^ 1280: 70707564 615e3765 5e346800 00000015 ppuda^7e ^4h..... 1296: 56005367 742e4461 726b6d61 6e00005e V.Sgt.Da rkman..^ 1312: 317b5343 46442037 7d5e3000 00165400 1{SCFD 7 }^0...T. 1328: 5e315265 645e3f42 61646765 00000000 ^1Red^?B adge.... 1344: 1730005e 34425e38 2d5e3149 5e382d5e .0.^4B^8 -^1I^8-^ 1360: 374e5e38 2d5e3247 5e382d5e 334f5e38 7N^8-^2G ^8-^3O^8 1376: 5f5e354d 5e4f6173 74657200 00000018 _^5M^Oas ter..... 1392: 96005e39 546f615e 32645e31 72617800 ..^9Toa^ 2d^1rax. 1408: 015e392d 2d4a7567 5e32675e 31616c6f .^9--Jug ^2g^1alo 1424: 5e300000 19530053 65727669 75734f72 ^0...S.S erviusOr 1440: 74757300 0000001a 3400486f 672d5769 tus..... 4.Hog-Wi 1456: 6c640000 00001b59 006c6164 79627567 ld.....Y .ladybug 1472: 38380000 00001c56 00456973 6d617573 88.....V .Eismaus 1488: 00000000 1d5b005e 78736f5e 7a635e78 .....[.^ xso^zc^x 1504: 6365725e 7a6b5e78 727a7900 005e6268 cer^zk^x rzy..^bh 1520: 6b7c2d5e 3000001e 80004d69 6e696d69 k|-^0... ..Minimi 1536: 6b650000 5e317b53 43464437 7d5e3000 ke..^1{S CFD7}^0. 1552: 001f0220 53633173 736f7273 00005e30 ... *Sc1s sors*..^0 1568: 4442435e 30000020 05000000 01fa4f0d DBC^0.. ......O. 1584: 00020000 .... debug(2) 22:16:01 qstat.c:3040 do_work() - connected, pre-packet_func: 1 debug(2) 22:16:01 doom3.c:296 _deal_with_doom3_packet() - challenge: 0xFFFFFFFF, protocol: 10.19 (0xA0013) debug(2) 22:16:01 doom3.c:306 _deal_with_doom3_packet() - Size = 1557 debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:net_serverPunkbusterEnabled=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:net_serverDedicated=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_version=ETQW 1.4.12335.33045 win-x86 Jan 15 2008 18:38:37: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_maxplayers=32: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_gameReviewReadyWait=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_disableGlobalChat=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_noProficiency=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_allowLateJoin=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_minPlayers=6: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_readyPercent=51: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_disableVoting=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_adminStart=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_motd_4=: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_motd_3=: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_motd_2=: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_motd_1=Powered by Trinity Gaming: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_email=http://www.fullcontactwar.com: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_adminname=: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_website=http://www.fullcontactwar.com: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_teamForceBalance=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_timelimit=20: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_rules=sdGameRulesCampaign: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_spectators=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_pure=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_needPass=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_teamDamage=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_privateClients=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_name=FullContactWar Full Rotation: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_antiLagForgiving=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_antiLagOnly=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_antiLag=1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:bot_enable=0: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:gamename=baseETQW-1: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_campaign=campaign_northeurope: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_map=maps/salvage: debug(2) 22:16:01 doom3.c:356 _deal_with_doom3_packet() - key:si_campaignInfo=2 2: debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 0 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[0] = ^4lg^1in, ping 74, rate 1968845406, id 0, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 1 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[1] = ingR, ping 72, rate 1180655940, id 1, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 2 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[2] = BUTCHER.UK, ping 171, rate 759515220, id 2, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 3 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[3] = <H^2OWDAHHE^<A^HD, ping 106, rate 1581467742, id 3, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 4 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[4] = iK, ping 191, rate 1735355465, id 4, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 5 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[5] = d^?Morgan, ping 96, rate 1699885406, id 5, bot 0, clan ^=[dbc]^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 6 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[6] = oke^7m^4sr, ping 85, rate 1836265822, id 6, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 8 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[7] = ess^7To^;Kill, ping 172, rate 1917074270, id 8, bot 0, clan ^0|^;|^1|^3|^7|^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 9 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[8] = erker0, ping 193, rate 1936876898, id 9, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 10 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[9] = Punisher, ping 183, rate 962480708, id 10, bot 0, clan ^0[^8Bone^7hunteR]^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 11 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[10] = apotamus, ping 85, rate 2054842704, id 11, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 12 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[11] = 06, ping 89, rate 930636109, id 12, bot 0, clan ^1{SCFD7}^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 13 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[12] = i^7ss^4ed, ping 54, rate 2001940830, id 13, bot 0, clan ^1/^7_^4\ ^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 14 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[13] = 9oach^1M^9o, ping 86, rate 1582444894, id 14, bot 0, clan ^1>^:BuG^1<^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 15 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[14] = an^9abk, ping 74, rate 1751335262, id 15, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 16 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[15] = 1, ping 85, rate 1936287860, id 16, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 17 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[16] = 4disco, ping 208, rate 929658465, id 17, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 18 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[17] = l^9i^1psa, ping 61, rate 1667314014, id 18, bot 0, clan ^9/^1_^9\ ^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 19 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[18] = tor^kPHOENIX, ping 183, rate 1817525086, id 19, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 20 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[19] = da^7e^4h, ping 171, rate 1970303070, id 20, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 21 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[20] = Darkman, ping 86, rate 779380563, id 21, bot 0, clan ^1{SCFD 7}^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 22 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[21] = d^?Badge, ping 84, rate 1699885406, id 22, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 23 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[22] = 8-^1I^8-^7N^8-^2G^8-^3O^8_^5M^Oaster, ping 48, rate 1581397086, id 23, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 24 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[23] = a^2d^1rax, ping 150, rate 1867790686, id 24, bot 0, clan ^9--Jug^2g^1alo^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 25 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[24] = iusOrtus, ping 83, rate 1987208531, id 25, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 26 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[25] = Wild, ping 52, rate 761753416, id 26, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 27 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[26] = bug88, ping 89, rate 2036621676, id 27, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 28 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[27] = aus, ping 86, rate 1836280133, id 28, bot 0, clan debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 29 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[28] = ^zc^xcer^zk^xrzy, ping 91, rate 1869838430, id 29, bot 0, clan ^bhk|-^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 30 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[29] = mike, ping 128, rate 1768843597, id 30, bot 0, clan ^1{SCFD7}^0 debug(2) 22:16:01 doom3.c:437 _deal_with_doom3_packet() - ID = 31 debug(2) 22:16:01 doom3.c:551 _deal_with_doom3_packet() - Player[30] = *sors*, ping 8194, rate 1932616531, id 31, bot 0, clan ^0DBC^0 debug(2) 22:16:01 doom3.c:573 _deal_with_doom3_packet() - osmask 0x5 debug(2) 22:16:01 doom3.c:645 _deal_with_doom3_packet() - Num players = 31 debug(3) 22:16:01 qstat.c:5609 cleanup_qserver() - no server rules and next_player_info >= num_players, forcing close debug(3) 22:16:01 qstat.c:5613 cleanup_qserver() - close_it 1 <server type="ETQWS" address="74.86.237.192:27733" status="UP"> <hostname>74.86.237.192:27733</hostname> <name>FullContactWar Full Rotation</name> <gametype></gametype> <map>salvage</map> <numplayers>31</numplayers> <maxplayers>32</maxplayers> <numspectators>0</numspectators> <maxspectators>0</maxspectators> <ping>1508</ping> <retries>2</retries> <players> <player> <number>31</number> <name>*sors*</name> <score>0</score> <ping>8194</ping> <clan>DBC</clan> <type>player</type> <rate>1932616531</rate> </player> <player> <number>30</number> <name>mike</name> <score>0</score> <ping>128</ping> <clan>{SCFD7}</clan> <type>player</type> <rate>1768843597</rate> </player> <player> <number>29</number> <name>ccerkrzy</name> <score>0</score> <ping>91</ping> <clan>hk|-</clan> <type>player</type> <rate>1869838430</rate> </player> <player> <number>28</number> <name>aus</name> <score>0</score> <ping>86</ping> <clan></clan> <type>player</type> <rate>1836280133</rate> </player> <player> <number>27</number> <name>bug88</name> <score>0</score> <ping>89</ping> <clan></clan> <type>player</type> <rate>2036621676</rate> </player> <player> <number>26</number> <name>Wild</name> <score>0</score> <ping>52</ping> <clan></clan> <type>player</type> <rate>761753416</rate> </player> <player> <number>25</number> <name>iusOrtus</name> <score>0</score> <ping>83</ping> <clan></clan> <type>player</type> <rate>1987208531</rate> </player> <player> <number>24</number> <name>adrax</name> <score>0</score> <ping>150</ping> <clan>--Juggalo</clan> <type>player</type> <rate>1867790686</rate> </player> <player> <number>23</number> <name>8-I-N-G-O_Master</name> <score>0</score> <ping>48</ping> <clan></clan> <type>player</type> <rate>1581397086</rate> </player> <player> <number>22</number> <name>dBadge</name> <score>0</score> <ping>84</ping> <clan></clan> <type>player</type> <rate>1699885406</rate> </player> <player> <number>21</number> <name>Darkman</name> <score>0</score> <ping>86</ping> <clan>{SCFD 7}</clan> <type>player</type> <rate>779380563</rate> </player> <player> <number>20</number> <name>daeh</name> <score>0</score> <ping>171</ping> <clan></clan> <type>player</type> <rate>1970303070</rate> </player> <player> <number>19</number> <name>torPHOENIX</name> <score>0</score> <ping>183</ping> <clan></clan> <type>player</type> <rate>1817525086</rate> </player> <player> <number>18</number> <name>lipsa</name> <score>0</score> <ping>61</ping> <clan>/_\ </clan> <type>player</type> <rate>1667314014</rate> </player> <player> <number>17</number> <name>4disco</name> <score>0</score> <ping>208</ping> <clan></clan> <type>player</type> <rate>929658465</rate> </player> <player> <number>16</number> <name>1</name> <score>0</score> <ping>85</ping> <clan></clan> <type>player</type> <rate>1936287860</rate> </player> <player> <number>15</number> <name>anabk</name> <score>0</score> <ping>74</ping> <clan></clan> <type>player</type> <rate>1751335262</rate> </player> <player> <number>14</number> <name>9oachMo</name> <score>0</score> <ping>86</ping> <clan>>BuG<</clan> <type>player</type> <rate>1582444894</rate> </player> <player> <number>13</number> <name>issed</name> <score>0</score> <ping>54</ping> <clan>/_\ </clan> <type>player</type> <rate>2001940830</rate> </player> <player> <number>12</number> <name>06</name> <score>0</score> <ping>89</ping> <clan>{SCFD7}</clan> <type>player</type> <rate>930636109</rate> </player> <player> <number>11</number> <name>apotamus</name> <score>0</score> <ping>85</ping> <clan></clan> <type>player</type> <rate>2054842704</rate> </player> <player> <number>10</number> <name>Punisher</name> <score>0</score> <ping>183</ping> <clan>[BonehunteR]</clan> <type>player</type> <rate>962480708</rate> </player> <player> <number>9</number> <name>erker0</name> <score>0</score> <ping>193</ping> <clan></clan> <type>player</type> <rate>1936876898</rate> </player> <player> <number>8</number> <name>essToKill</name> <score>0</score> <ping>172</ping> <clan>|||||</clan> <type>player</type> <rate>1917074270</rate> </player> <player> <number>6</number> <name>okemsr</name> <score>0</score> <ping>85</ping> <clan></clan> <type>player</type> <rate>1836265822</rate> </player> <player> <number>5</number> <name>dMorgan</name> <score>0</score> <ping>96</ping> <clan>[dbc]</clan> <type>player</type> <rate>1699885406</rate> </player> <player> <number>4</number> <name>iK</name> <score>0</score> <ping>191</ping> <clan></clan> <type>player</type> <rate>1735355465</rate> </player> <player> <number>3</number> <name><HOWDAHHEAD</name> <score>0</score> <ping>106</ping> <clan></clan> <type>player</type> <rate>1581467742</rate> </player> <player> <number>2</number> <name>BUTCHER.UK</name> <score>0</score> <ping>171</ping> <clan></clan> <type>player</type> <rate>759515220</rate> </player> <player> <number>1</number> <name>ingR</name> <score>0</score> <ping>72</ping> <clan></clan> <type>player</type> <rate>1180655940</rate> </player> <player> <number>0</number> <name>lgin</name> <score>0</score> <ping>74</ping> <clan></clan> <type>player</type> <rate>1968845406</rate> </player> </players> </server> debug(2) 22:16:01 qstat.c:3042 do_work() - connected, post-packet_func: 0 debug(3) 22:16:01 qstat.c:4612 send_packets() - processing... debug(3) 22:16:01 qstat.c:4747 send_packets() - done debug(2) 22:16:01 qstat.c:3058 do_work() - connected: 0 </qstat> |
From: Steven H. <ki...@mu...> - 2008-01-20 17:40:58
|
I've added translations as I've found them for things like that in the past so, in fact that's already translated. If there are more personally I'd just add them. I'm still trying to get Epic to sort their lives out with respect the ut3 query protocol as its at total and utter mess. Regards Steve ----- Original Message ----- From: "Ludwig Nussel" <l-...@us...> To: <qst...@li...> Sent: Sunday, January 20, 2008 4:25 PM Subject: [QStat-devx] how to deal unreadable with ut3 rule names? > Hi, > > UT3 uses the gs4 protocol. Unfortunately they use weird strings > instead of human readable strings as rules. E.g. "p268435705" means > "time limit", "s7" means "password required" [1]. Now I wonder > whether qstat should translate those strings to readable rule names > or whether that should be left to a front-end such as xqf. Does > anyone know whether all games with gs4 protocol use the same meaning > for those rules? > > cu > Ludwig > > [1] http://wiki.unrealadmin.org/UT3_query_protocol > > -- > (o_ Ludwig Nussel > //\ > V_/_ PGP Key: FF8135CE > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Ludwig N. <l-...@us...> - 2008-01-20 16:22:33
|
Hi, UT3 uses the gs4 protocol. Unfortunately they use weird strings instead of human readable strings as rules. E.g. "p268435705" means "time limit", "s7" means "password required" [1]. Now I wonder whether qstat should translate those strings to readable rule names or whether that should be left to a front-end such as xqf. Does anyone know whether all games with gs4 protocol use the same meaning for those rules? cu Ludwig [1] http://wiki.unrealadmin.org/UT3_query_protocol -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
From: Ludwig N. <l-...@us...> - 2008-01-20 16:18:17
|
Pierre Smolarek wrote: > Can someone confirm if we have the recent bzip2 compression support > added into qstat's a2s protocol. I checked the source and saw nothing > obvious that indicated we had. > > http://developer.valvesoftware.com/wiki/Server_Queries#Protocol It's not straigt forward to implement due to the way fragments are currently reordered and processed by qstat. Their bzip2 extension compresses the whole packet and then splits it up whereas qstat expects to be able to parse individual fragments. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
From: Steven H. <ki...@mu...> - 2008-01-02 10:29:23
|
Not that I'm aware of. Regards Steve ----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> > Hello all, > > Can someone confirm if we have the recent bzip2 compression support > added into qstat's a2s protocol. I checked the source and saw nothing > obvious that indicated we had. > > http://developer.valvesoftware.com/wiki/Server_Queries#Protocol ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2008-01-02 04:07:12
|
Hello all, Can someone confirm if we have the recent bzip2 compression support added into qstat's a2s protocol. I checked the source and saw nothing obvious that indicated we had. http://developer.valvesoftware.com/wiki/Server_Queries#Protocol Pierre |
From: Pierre S. <pi...@un...> - 2007-12-26 19:41:42
|
Hi All, I hope all are having a good Christmas :) I've noticed a bug in a2s where players and remaining rules arn't being shows. qstat -a2s 84.45.99.217:27025 -R -P I think this is related to users who are running an additional mod (mani?) for CS. Or possible a steamID ban mod. In either case, there are many servers running this combo and I hope this is something we can accommodate within qstat. Let me know. Pierre |
From: Steven H. <ki...@mu...> - 2007-12-06 21:14:38
|
I've just checked in some basic support for wic based on their rcon protocol along with a few other fixes for gs3 and ut3. Due to using rcon WiC queries require: -wics,port=<gameport>,password=<admin_password> <ip>:<admin_port> Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2007-11-01 17:55:16
|
Hi Steve, I saw some commits in svn and see you're working hard on the etqw fixes. As an aid I found this info, hope it helps: http://www.modwiki.net/wiki/Server_query_protocol Pierre Steven Hartland wrote: > This is a change in the v1.2 patch. I'm testing a patch here now and > will commit as soon as I'm happy. > > Regards > Steve > > ----- Original Message ----- > From: "Pierre Smolarek" <pi...@un...> > > > >> All of a sudden today I have been experiencing qstat core dumping when >> querying etqw servers. Its not impossible that i could have a couple >> rouge servers in my last as has happened in the past, but the issue >> seems to persist even when I remove suspected IP's. >> >> Have you guys experienced a similar issue, if I shall go ahead and >> submit some debug data. >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > or return the E.mail to pos...@mu.... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
From: Steven H. <ki...@mu...> - 2007-10-30 21:44:37
|
This is a change in the v1.2 patch. I'm testing a patch here now and will commit as soon as I'm happy. Regards Steve ----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> > All of a sudden today I have been experiencing qstat core dumping when > querying etqw servers. Its not impossible that i could have a couple > rouge servers in my last as has happened in the past, but the issue > seems to persist even when I remove suspected IP's. > > Have you guys experienced a similar issue, if I shall go ahead and > submit some debug data. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2007-10-30 21:36:22
|
All of a sudden today I have been experiencing qstat core dumping when querying etqw servers. Its not impossible that i could have a couple rouge servers in my last as has happened in the past, but the issue seems to persist even when I remove suspected IP's. Have you guys experienced a similar issue, if I shall go ahead and submit some debug data. Thanks, Pierre |
From: Pierre S. <pi...@un...> - 2007-08-16 15:25:01
|
Hello All, This is to notify you that qstat has now migrated from CVS to Subversion. This has been done at the request of the current maintainers and should therefore help ease and speed development (and documentation) of qstat. The CVS repository _has been shut down_ and will therefore not accept any more commits or checkouts. As from this moment, please use Subversion for any bleeding edge source code requirements. To checkout the current working branch of Qstat please use the following command: svn checkout https://qstat.svn.sourceforge.net/svnroot/qstat/trunk/qstat2 qstat2 If you are a developer of qstat, you will need generate a new working copy of your source tree and patch any changes made since your last commit to your new subversion tree before committing. The new website should be up soon that will echo this and any additional information. If anyone has any question, please feel free to contact me. Pierre. |
From: Pierre S. <pi...@un...> - 2007-08-14 22:51:54
|
Hello, For some reason I can't seem to get a full list of rules and players for the following hl2dm/steam server ip's. 193.47.83.200:27015 193.47.83.200:27016 193.47.83.200:27018 193.47.83.200:27025 I can submit a -d -d -d report but wanted to avoid spamming your inboxs. I'm using the latest CVS qstat. My command is: qstat -a2s 193.47.83.200:27018 -R -P -xml I'd appreciate it if you could confirm if its working your end. P. |
From: Steven H. <ki...@mu...> - 2007-07-22 18:39:30
|
Please do, I don't have much time atm. Regards Steve ----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> > Steve H, > > I managed to get admin to the qstat project and subversion should now be > all setup to do a cvstosvn. If you prefer I can do that for you, but > thought i'd check with you first. > > Also i noticed that the quake4 -q4s protocal has stopped showing scores. > Can you look into that for me and confirm if its okay and possibly > something my end. > > P. > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2007-07-22 15:46:27
|
Steve H, I managed to get admin to the qstat project and subversion should now be all setup to do a cvstosvn. If you prefer I can do that for you, but thought i'd check with you first. Also i noticed that the quake4 -q4s protocal has stopped showing scores. Can you look into that for me and confirm if its okay and possibly something my end. P. |
From: Steven H. <ki...@mu...> - 2007-07-10 17:19:33
|
Yes the protocol is in a state of flux atm. I'm talking directly with the game devs from iD and SD so the code as good as atm. Steve ----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> To: <qst...@li...> Cc: "Steven Hartland" <ki...@mu...> Sent: Tuesday, July 10, 2007 6:02 PM Subject: [QStat-devx] [Fwd: ETQW query protocol] > Hey Steve H. > > I know you've already deployed the code for etqw in qstat, but as a > double check I have the attached/forwarded email that should reconfirm > any suspicions about the protocol. > > On the website - Unfortunately my move back to Canada from the UK > lingered on for a bit longer then expected. I should get the new site up > for you and others to see this week. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2007-07-10 17:02:28
|
Hey Steve H. I know you've already deployed the code for etqw in qstat, but as a double check I have the attached/forwarded email that should reconfirm any suspicions about the protocol. On the website - Unfortunately my move back to Canada from the UK lingered on for a bit longer then expected. I should get the new site up for you and others to see this week. P. |
From: Steven H. <ki...@mu...> - 2007-06-18 01:36:34
|
----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> > It looks like the long running battle Steve J had with his previous > registrar has been resolved (i'm sure he must have told me when but > honestly can't recall the moment). It seems as though I can now correct > the DNS entries and get the site back up. This is still not returning any DNS results :( ;; connection timed out; no servers could be reached > I did develop a new site/logo some time ago which I can throw up over > the next week, assuming no technical issues. Was everyone okay with the > logo we developed? Got a link? > In regards to subversion. I think Steve J said he gave you (Steve H) > access to do this. If this isn't the case (as seems to be from your > email) I can pester him to have another attempt at providing you with > admin access to the sourceforge site. Just had a good check and it doesnt look like I have the relavent access. Under admin it says: "You are listed as a developer (not administrator) for this project." So I guess thats a yes to the pester ;-) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Pierre S. <pi...@un...> - 2007-06-14 10:07:20
|
It looks like the long running battle Steve J had with his previous registrar has been resolved (i'm sure he must have told me when but honestly can't recall the moment). It seems as though I can now correct the DNS entries and get the site back up. I did develop a new site/logo some time ago which I can throw up over the next week, assuming no technical issues. Was everyone okay with the logo we developed? In regards to subversion. I think Steve J said he gave you (Steve H) access to do this. If this isn't the case (as seems to be from your email) I can pester him to have another attempt at providing you with admin access to the sourceforge site. Thanks for the continuing support work to Steve H. and Ludwig. I am quite dependant on qstat so fully appreciate all the time you have both put in over the past several months. Pierre. Steven Hartland wrote: > ----- Original Message ----- > From: "Pierre Smolarek" <pi...@un...> > > > >> Steve J is having some issues with the domain provider and is unable to >> change DNS servers. >> >> We are hosting the site but we had an IP and DNS name change and Steve >> is still wrestling to get it all working. >> > > Quite a while since I last checked on this but atm it seems qstat.org isn't delegated anywhere. Quit willing to host the site / > DNS here if we can get > the DNS delegated. > > Another thing that came up quite a while ago was the move to svn from cvs which would be nice anyone heard any news on that. I > personally don't have enough privs on sourceforge to the qstat project to make that change does anyone else? > > For those interested I've recently committed updates to support ET:QW. > > Regards > Steve > > |
From: Steven H. <ki...@mu...> - 2007-06-09 18:18:11
|
----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> > Steve J is having some issues with the domain provider and is unable to > change DNS servers. > > We are hosting the site but we had an IP and DNS name change and Steve > is still wrestling to get it all working. Quite a while since I last checked on this but atm it seems qstat.org isn't delegated anywhere. Quit willing to host the site / DNS here if we can get the DNS delegated. Another thing that came up quite a while ago was the move to svn from cvs which would be nice anyone heard any news on that. I personally don't have enough privs on sourceforge to the qstat project to make that change does anyone else? For those interested I've recently committed updates to support ET:QW. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Steven H. <ki...@mu...> - 2006-11-04 16:39:03
|
> PS: qstat.org is down, who can fix that? Yer been down for a while now, I dont have any access. If it needs to be moved, we can provide hosting. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
From: Ludwig N. <l-...@us...> - 2006-11-04 16:31:41
|
Hi, I've just uploaded qstat 2.11 to sourceforge: http://sourceforge.net/project/showfiles.php?group_id=56603&package_id=51888&release_id=460941 rpms are available at the xqf project: http://sourceforge.net/project/showfiles.php?group_id=13296&package_id=34590&release_id=460919 Summary of New Features ----------------------- new protocols: Warsow [-warsows, -warsowm] Prey [-preys, -preym] TrackMania [-tm] Tremulous [-tremulous, -tremulousm] add -nx and -nnx options that enable resp. disable name transformation calculate player score for AMS servers Fixes ----- fix segfault when a "tribes2 master" returns garbage cu Ludwig PS: qstat.org is down, who can fix that? -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
From: Ludwig N. <l-...@us...> - 2006-11-04 12:34:34
|
Pierre Smolarek wrote: > Ludwig Nussel wrote: > > The -interval and -retry options influence how long qstat spends on > > a server. Individual protocols may misbehave though. > > > > > My actual command for my scanner is: > > /qstat/qstat -cfg /qstat/qstat.cfg -P -R -progress -sendinterval 0 > -retry 1 -maxsim 100 -timeout 600 -u -tsw -f qstat.list -raw,game ,, > > Relying on retry and interval (which has a default of 0.5s) isn't enough > it seems. That probably means some protocol misbehaves and clogs the queue with servers that don't time out. The protocol needs to be identified and fixed. > >> more /tmp/list > >> bf2142s 192.168.1.103:29900 > >> hl1 192.168.0.101:27015 > >> sf2 192.168.1.50:20100 > >> cod 192.168.0.2:28960 > >> mhss 192.168.101.47:12300 > >> mhbs 192.168.2.10:12203 > >> css 192.168.2.100:27015 > >> css 192.168.0.102:8080 > >> swb 192.168.2.2:3658 > >> fear 192.168.0.4:27888 > >> hlo 192.168.1.110:2302 > >> > > > > All private addresses with unoffical protocols. I can't reproduce > > with that list. > > > > > This is an example list of servers that will all timeout for the sake of > the later examples demonstrating the timeout functionality on a per scan > basis In this case the attached patch helps. I'll commit it after the 2.11 release. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
From: Pierre S. <pi...@un...> - 2006-11-02 19:26:47
|
Ludwig Nussel wrote: > The -interval and -retry options influence how long qstat spends on > a server. Individual protocols may misbehave though. > > My actual command for my scanner is: /qstat/qstat -cfg /qstat/qstat.cfg -P -R -progress -sendinterval 0 -retry 1 -maxsim 100 -timeout 600 -u -tsw -f qstat.list -raw,game ,, Relying on retry and interval (which has a default of 0.5s) isn't enough it seems. >> more /tmp/list >> bf2142s 192.168.1.103:29900 >> hl1 192.168.0.101:27015 >> sf2 192.168.1.50:20100 >> cod 192.168.0.2:28960 >> mhss 192.168.101.47:12300 >> mhbs 192.168.2.10:12203 >> css 192.168.2.100:27015 >> css 192.168.0.102:8080 >> swb 192.168.2.2:3658 >> fear 192.168.0.4:27888 >> hlo 192.168.1.110:2302 >> > > All private addresses with unoffical protocols. I can't reproduce > with that list. > > This is an example list of servers that will all timeout for the sake of the later examples demonstrating the timeout functionality on a per scan basis >> [...] >> time /qstat/qstat -cfg /qstat/qstat.cfg -f /tmp/list -timeout 1 -raw ,, >> -d -d -d -d >> > > Looks like no server responds until the timeout hits. > Exactly, therefore I want to know which servers didn't make it within this threshold so that i can purge them from the list. > cu > Ludwig > > |
From: Ludwig N. <l-...@us...> - 2006-11-02 18:59:04
|
Pierre Smolarek wrote: > I remember talking to Steve J a few years about this in that the > -timeout clause in this situation is based on the time taken for the > list to scan and not for each individual server. Ideally this needs to > be corrected to the latter functionality, however that beyond my ability > so would really appreciate it if someone could see how possible that > feature would be to implement. I have a tentative 20 minute timeout for The -interval and -retry options influence how long qstat spends on a server. Individual protocols may misbehave though. > more /tmp/list > bf2142s 192.168.1.103:29900 > hl1 192.168.0.101:27015 > sf2 192.168.1.50:20100 > cod 192.168.0.2:28960 > mhss 192.168.101.47:12300 > mhbs 192.168.2.10:12203 > css 192.168.2.100:27015 > css 192.168.0.102:8080 > swb 192.168.2.2:3658 > fear 192.168.0.4:27888 > hlo 192.168.1.110:2302 All private addresses with unoffical protocols. I can't reproduce with that list. > [...] > time /qstat/qstat -cfg /qstat/qstat.cfg -f /tmp/list -timeout 1 -raw ,, > -d -d -d -d Looks like no server responds until the timeout hits. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |