Menu
▾
▴
qstat-devx — Discussion between QStat developers
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...> - 2009-08-14 15:37:07
|
Steve, Would love to update the server but as you may remember, serverspy.net just scans all servers on the master lists so thats not possible. Is there any way to just reject the server in qstat and return no data? Pierre Steven Hartland wrote: > Looks like this is a very old server which isn't using > the new broken protocol which qstat is expecting. Try > updating the server. > > Regards > Steve > > ----- Original Message ----- From: "Pierre Smolarek" > <pi...@un...> > To: "Steven Hartland" <ki...@mu...> > Cc: <qst...@li...> > Sent: Friday, August 14, 2009 3:07 PM > Subject: Re: [QStat-devx] Qstat A2S causing "Too many fragments" error > > >> Hello Steven >> >> /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017 >> >> cssource (a2s) >> >> latest subversion version >> >> when i use that command above it will just loop the query forever. I'm >> seeing several servers do this. >> >> 62.231.190.35:27017 css >> 62.231.190.39:27015 css (hltv) >> 62.181.0.142:27213 >> 62.181.0.138:27081 >> 67.93.155.120:27014 >> 62.168.75.69:27017 >> >> FreeBSD 7.0-RELEASE-p1 >> >> >> >> Pierre >> >> >> Steven Hartland wrote: >>> Questions: >>> 1. Command line used? >>> 2. Game? >>> 3. qstat version? >>> >>> Regards >>> Steve >>> >>> ----- Original Message ----- >>> *From:* Pierre Smolarek <mailto:pi...@un...> >>> *To:* qst...@li... >>> <mailto:qst...@li...> >>> *Sent:* Thursday, August 13, 2009 2:56 PM >>> *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" >>> error >>> >>> Hello, >>> >>> Been a while since I posted a qstat bug but here's one for you >>> both. >>> >>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected, >>> pre-packet_func: 129 >>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: >>> 31229 >>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: >>> 0x2 => idx: 255, max: 2 >>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, >>> id:31229 >>> *Too many fragments 255 for packetid 31229 max 16* >>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 >>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected, >>> post-packet_func: 129 >>> FROM 62.231.190.35:27017 len 243 >>> 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha >>> 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P >>> 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen >>> 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[ >>> 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe >>> 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH >>> 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar >>> 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH >>> 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock >>> 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[ >>> 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe >>> 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*. >>> 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De >>> 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*. >>> 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD...... >>> 240: a6d343 ..C >>> >>> >>> and >>> >>> >>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected, >>> pre-packet_func: 128 >>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: >>> 31229 >>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: >>> 0x12 => idx: 0, max: 18 >>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, >>> id:31229 >>> *Too many fragments 255 for packetid 31229 max 16 >>> *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, >>> id:31229 >>> debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more >>> expected: 1 != 18 >>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 >>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected, >>> post-packet_func: 128 >>> FROM 62.231.190.39:27015 len 30 >>> 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr >>> 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G >>> >>> >>> >>> Let me know what you think. >>> >>> >>> Thanks, >>> >>> Pierre >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Let Crystal Reports handle the reporting - Free Crystal Reports >>> 2008 30-Day >>> trial. Simplify your report design, integration and deployment - >>> and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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.... >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application coding. >>> Discover what's new with Crystal Reports now. >>> http://p.sf.net/sfu/bobj-july >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> QStat-devx mailing list >>> QSt...@li... >>> https://lists.sourceforge.net/lists/listinfo/qstat-devx >>> >> >> >> ------------------------------------------------------------------------------ >> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment >> - and focus on what you do best, core application coding. Discover >> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> 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: Steven H. <ki...@mu...> - 2009-08-14 14:47:46
|
Looks like this is a very old server which isn't using
the new broken protocol which qstat is expecting. Try
updating the server.
Regards
Steve
----- Original Message -----
From: "Pierre Smolarek" <pi...@un...>
To: "Steven Hartland" <ki...@mu...>
Cc: <qst...@li...>
Sent: Friday, August 14, 2009 3:07 PM
Subject: Re: [QStat-devx] Qstat A2S causing "Too many fragments" error
> Hello Steven
>
> /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017
>
> cssource (a2s)
>
> latest subversion version
>
> when i use that command above it will just loop the query forever. I'm
> seeing several servers do this.
>
> 62.231.190.35:27017 css
> 62.231.190.39:27015 css (hltv)
> 62.181.0.142:27213
> 62.181.0.138:27081
> 67.93.155.120:27014
> 62.168.75.69:27017
>
> FreeBSD 7.0-RELEASE-p1
>
>
>
> Pierre
>
>
> Steven Hartland wrote:
>> Questions:
>> 1. Command line used?
>> 2. Game?
>> 3. qstat version?
>>
>> Regards
>> Steve
>>
>> ----- Original Message -----
>> *From:* Pierre Smolarek <mailto:pi...@un...>
>> *To:* qst...@li...
>> <mailto:qst...@li...>
>> *Sent:* Thursday, August 13, 2009 2:56 PM
>> *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" error
>>
>> Hello,
>>
>> Been a while since I posted a qstat bug but here's one for you both.
>>
>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected,
>> pre-packet_func: 129
>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]:
>> 0x2 => idx: 255, max: 2
>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2,
>> id:31229
>> *Too many fragments 255 for packetid 31229 max 16*
>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected,
>> post-packet_func: 129
>> FROM 62.231.190.35:27017 len 243
>> 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
>> 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
>> 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
>> 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
>> 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
>> 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
>> 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
>> 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
>> 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
>> 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
>> 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
>> 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
>> 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
>> 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
>> 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
>> 240: a6d343 ..C
>>
>>
>> and
>>
>>
>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected,
>> pre-packet_func: 128
>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]:
>> 0x12 => idx: 0, max: 18
>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2,
>> id:31229
>> *Too many fragments 255 for packetid 31229 max 16
>> *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18,
>> id:31229
>> debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more
>> expected: 1 != 18
>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected,
>> post-packet_func: 128
>> FROM 62.231.190.39:27015 len 30
>> 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
>> 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
>>
>>
>>
>> Let me know what you think.
>>
>>
>> Thanks,
>>
>> Pierre
>>
>>
>> ------------------------------------------------------------------------
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports
>> 2008 30-Day
>> trial. Simplify your report design, integration and deployment -
>> and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> 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....
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> QStat-devx mailing list
>> QSt...@li...
>> https://lists.sourceforge.net/lists/listinfo/qstat-devx
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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: Pierre S. <pi...@un...> - 2009-08-14 14:08:12
|
Hello Steven /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017 cssource (a2s) latest subversion version when i use that command above it will just loop the query forever. I'm seeing several servers do this. 62.231.190.35:27017 css 62.231.190.39:27015 css (hltv) 62.181.0.142:27213 62.181.0.138:27081 67.93.155.120:27014 62.168.75.69:27017 FreeBSD 7.0-RELEASE-p1 Pierre Steven Hartland wrote: > Questions: > 1. Command line used? > 2. Game? > 3. qstat version? > > Regards > Steve > > ----- Original Message ----- > *From:* Pierre Smolarek <mailto:pi...@un...> > *To:* qst...@li... > <mailto:qst...@li...> > *Sent:* Thursday, August 13, 2009 2:56 PM > *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" error > > Hello, > > Been a while since I posted a qstat bug but here's one for you both. > > debug(2) 22:21:07 qstat.c:3092 do_work() - connected, > pre-packet_func: 129 > debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229 > debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: > 0x2 => idx: 255, max: 2 > debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, > id:31229 > *Too many fragments 255 for packetid 31229 max 16* > debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 > debug(2) 22:21:07 qstat.c:3094 do_work() - connected, > post-packet_func: 129 > FROM 62.231.190.35:27017 len 243 > 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha > 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P > 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen > 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[ > 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe > 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH > 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar > 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH > 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock > 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[ > 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe > 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*. > 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De > 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*. > 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD...... > 240: a6d343 ..C > > > and > > > debug(2) 22:21:07 qstat.c:3092 do_work() - connected, > pre-packet_func: 128 > debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229 > debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: > 0x12 => idx: 0, max: 18 > debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, > id:31229 > *Too many fragments 255 for packetid 31229 max 16 > *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, > id:31229 > debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more > expected: 1 != 18 > debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 > debug(2) 22:21:07 qstat.c:3094 do_work() - connected, > post-packet_func: 128 > FROM 62.231.190.39:27015 len 30 > 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr > 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G > > > > Let me know what you think. > > > Thanks, > > Pierre > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > trial. Simplify your report design, integration and deployment - > and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > ------------------------------------------------------------------------ > _______________________________________________ > 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.... > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
|
From: Steven H. <ki...@mu...> - 2009-08-13 15:32:12
|
Questions:
1. Command line used?
2. Game?
3. qstat version?
Regards
Steve
----- Original Message -----
From: Pierre Smolarek
To: qst...@li...
Sent: Thursday, August 13, 2009 2:56 PM
Subject: [QStat-devx] Qstat A2S causing "Too many fragments" error
Hello,
Been a while since I posted a qstat bug but here's one for you both.
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 129
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x2 => idx: 255, max: 2
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
Too many fragments 255 for packetid 31229 max 16
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 129
FROM 62.231.190.35:27017 len 243
0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
240: a6d343 ..C
and
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 128
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x12 => idx: 0, max: 18
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
Too many fragments 255 for packetid 31229 max 16
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, id:31229
debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more expected: 1 != 18
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 128
FROM 62.231.190.39:27015 len 30
0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
Let me know what you think.
Thanks,
Pierre
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------------------------------------------------------
_______________________________________________
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: Pierre S. <pi...@un...> - 2009-08-13 14:15:58
|
Hello,
Been a while since I posted a qstat bug but here's one for you both.
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 129
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x2 =>
idx: 255, max: 2
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
*Too many fragments 255 for packetid 31229 max 16*
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 129
FROM 62.231.190.35:27017 len 243
0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
240: a6d343 ..C
and
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 128
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x12
=> idx: 0, max: 18
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
*Too many fragments 255 for packetid 31229 max 16
*debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, id:31229
debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more expected:
1 != 18
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 128
FROM 62.231.190.39:27015 len 30
0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
Let me know what you think.
Thanks,
Pierre
|
|
From: Ludwig N. <l-...@us...> - 2008-09-10 17:59:28
|
Steven Hartland wrote: > Should we not consider moving to something like BSD license? That would mean anyone could turn qstat into something proprietary. Artistic License 2 is fine for me. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-09-10 08:15:56
|
Should we not consider moving to something like BSD license?
Regards
Steve
----- Original Message -----
From: "Pierre Smolarek" <pi...@un...>
To: <qst...@li...>
Sent: Tuesday, September 09, 2008 10:05 PM
Subject: [QStat-devx] License of Qstat Changing to Artistic 2.0
> Hello All,
>
> Due to some incompatibility issues with other licenses, I've been
> advised, and agree, that we should move to Artistic 2.0. I've received
> approval/direction from Steve J. already and as we're under a time
> constraint to make this change over the next couple days (see below) I
> plan to update qstat on SVN later tonight and bundle a release for some
> linux distros.
>
>> Currently, Fedora is including qstat, which is licensed under
>> the Artistic 1.0 license. This license is no longer a permitted
>> license in
>> Fedora.
>>
>> Why?
>>
>> 1. The FSF says it isn't free. They say that the text is vague,
>> and
>> that it is open to misinterpretation.
>> 2. The perl community (the original authors) agrees with this
>> assessment. They went so far as to rewrite the Artistic
>> license
>> to resolve all the identified problems (see
>> http://www.perlfoundation.org/artistic_license_2_0).
>> 3. The OSI has "superseded" the license, recommending strongly
>> that
>> all users move to Artistic 2.0:
>> http://opensource.org/licenses/artistic-license-1.0.php
>>
>> qstat is a useful package, which a fair amount of other Fedora
>> packages depend upon, so we would really prefer not to remove it. Is
>> there any chance you would consider relicensing this code, for
>> example,
>> under the same license as perl5 (GPL+ or Artistic)?
>>
>> Please get back to me ASAP, our window is almost gone to keep this
>> code
>> in Fedora.
>
>
>
> I apologize for the short notice and I appreciate your patience with me.
> Hopefully there is no unforeseen issue with this, so please let me know
> otherwise.
>
> I plan to let the users group know about this change later on in the
> week - just wanted you guys to know first.
>
> Regards
>
> Pierre.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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: Pierre S. <pi...@un...> - 2008-09-09 21:04:46
|
Hello All, Due to some incompatibility issues with other licenses, I've been advised, and agree, that we should move to Artistic 2.0. I've received approval/direction from Steve J. already and as we're under a time constraint to make this change over the next couple days (see below) I plan to update qstat on SVN later tonight and bundle a release for some linux distros. > Currently, Fedora is including qstat, which is licensed under > the Artistic 1.0 license. This license is no longer a permitted > license in > Fedora. > > Why? > > 1. The FSF says it isn't free. They say that the text is vague, > and > that it is open to misinterpretation. > 2. The perl community (the original authors) agrees with this > assessment. They went so far as to rewrite the Artistic > license > to resolve all the identified problems (see > http://www.perlfoundation.org/artistic_license_2_0). > 3. The OSI has "superseded" the license, recommending strongly > that > all users move to Artistic 2.0: > http://opensource.org/licenses/artistic-license-1.0.php > > qstat is a useful package, which a fair amount of other Fedora > packages depend upon, so we would really prefer not to remove it. Is > there any chance you would consider relicensing this code, for > example, > under the same license as perl5 (GPL+ or Artistic)? > > Please get back to me ASAP, our window is almost gone to keep this > code > in Fedora. I apologize for the short notice and I appreciate your patience with me. Hopefully there is no unforeseen issue with this, so please let me know otherwise. I plan to let the users group know about this change later on in the week - just wanted you guys to know first. Regards Pierre. |
|
From: Pierre S. <pi...@un...> - 2008-04-26 21:23:06
|
Steve, I'm still having those issues on my freebsd 7 64bit box. I'm going to try a clean install in vmware and see what happens there. Pierre Steven Hartland wrote: > x86_64 sounds like a Linux distro not BSD? > > ----- Original Message ----- > From: "Ludwig Nussel" <l-...@us...> > > > >> Steven Hartland wrote: >> >>> Looked at it but wouldn't compile here saying it only runs on i386 >>> even though their docs claim amd64 compat. >>> >> Works on x86_64 for sure. I just use the distro package though. >> > > > ================================================ > 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 the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
|
From: Steven H. <ki...@mu...> - 2008-04-26 18:10:10
|
x86_64 sounds like a Linux distro not BSD? ----- Original Message ----- From: "Ludwig Nussel" <l-...@us...> > Steven Hartland wrote: >> Looked at it but wouldn't compile here saying it only runs on i386 >> even though their docs claim amd64 compat. > > Works on x86_64 for sure. I just use the distro package though. ================================================ 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-04-26 17:56:30
|
Steven Hartland wrote: > Looked at it but wouldn't compile here saying it only runs on i386 > even though their docs claim amd64 compat. Works on x86_64 for sure. I just use the distro package though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-04-26 10:20:59
|
Looked at it but wouldn't compile here saying it only runs on i386 even though
their docs claim amd64 compat.
Regards
Steve
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
To: <qst...@li...>
Sent: Friday, April 25, 2008 11:20 PM
Subject: Re: [QStat-devx] HEADSUP: deal_with_ and send_ now return int's
> Steven Hartland wrote:
>> A number of other issues where trapped and fixed with the help of efence
>> including a major memory corruption issue affecting any server which swaps
>> its port.
>
> Have you tried valgrind? It catches more than just malloc errors.
================================================
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-04-25 22:40:13
|
Pierre Smolarek wrote: > Ludwig, i forgot to reply to all but i just suggested the following for > version control: > > "We could follow a similar version numbering as perl, Where odd numbers > are 'beta build' releases and even numbers are 'stable' releases? > > So, qstat 2.14.x would be considered stable, Qstat 2.13.x would be > considered 'beta' ? " Nah, total overkill. Let's just continue with the current scheme which increments the second number with every release. If you desperately want to express bigger changes in svn with version numbers I'd suggest to use the third number for that purpose only and never use the third number in releases. I btw already have test qstat builds of svn snapshots in the opensuse build service[1]. I'll update them to current trunk tomorrow. cu Ludwig [1] http://software.opensuse.org/search -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Pierre S. <pi...@un...> - 2008-04-25 22:30:03
|
Ludwig, i forgot to reply to all but i just suggested the following for version control: "We could follow a similar version numbering as perl, Where odd numbers are 'beta build' releases and even numbers are 'stable' releases? So, qstat 2.14.x would be considered stable, Qstat 2.13.x would be considered 'beta' ? " Steve H seemed to agree, so unless you have any complaints, I'd like to enact the above version numbering from now on. Pierre Ludwig Nussel wrote: > Steven Hartland wrote: > >> A number of other issues where trapped and fixed with the help of efence >> including a major memory corruption issue affecting any server which swaps >> its port. >> > > Have you tried valgrind? It catches more than just malloc errors. > > cu > Ludwig > > |
|
From: Ludwig N. <l-...@us...> - 2008-04-25 22:20:52
|
Steven Hartland wrote: > A number of other issues where trapped and fixed with the help of efence > including a major memory corruption issue affecting any server which swaps > its port. Have you tried valgrind? It catches more than just malloc errors. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-04-25 21:24:49
|
I was never intending to release 2.12. Instead I'd suggest we moved to
2.13 once all the niggles are worked out and do a bin release then.
Regards
Steve
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
To: <qst...@li...>
Sent: Friday, April 25, 2008 10:05 PM
Subject: Re: [QStat-devx] HEADSUP: deal_with_ and send_ now return int's
> Steven Hartland wrote:
>> Included in this change is a version bump to 2.12. Until the rest
>> of the changes are complete please treat this as BETA code due
>> to the significant changes needed.
>
> It's always beta as long as it's in svn. Sometimes more and
> sometimes less. The version number is basically meaningless. However
> there should be no 2.12 before 2.12 is actually released. Otherwise
> packagers that package svn snapshots might fall into the trap that
> the final version suddenly has the same or even a lower version than
> the snapshots. So I'd rather use something like 2.11.1, 2.11.2 etc
> for bigger changes in svn and only bump the version to 2.12
> immediately before the release.
================================================
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-04-25 21:05:55
|
Steven Hartland wrote: > Included in this change is a version bump to 2.12. Until the rest > of the changes are complete please treat this as BETA code due > to the significant changes needed. It's always beta as long as it's in svn. Sometimes more and sometimes less. The version number is basically meaningless. However there should be no 2.12 before 2.12 is actually released. Otherwise packagers that package svn snapshots might fall into the trap that the final version suddenly has the same or even a lower version than the snapshots. So I'd rather use something like 2.11.1, 2.11.2 etc for bigger changes in svn and only bump the version to 2.12 immediately before the release. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-04-25 18:05:46
|
I've now completed my initial set of tests and fixes for this update.
A number of other issues where trapped and fixed with the help of efence
including a major memory corruption issue affecting any server which swaps
its port.
Given this I'd encourage people to now test this latest version in their
environments to see if it uncovers any issues.
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...> - 2008-04-25 01:59:29
|
Stage two of this work has now been committed this removes virtually
all calls to cleanup_qserver, keeping them only in the core logic.
These calls have been replaced by simple meaningful return values.
I've done just a few tests on TMF to confirm this refactor is having
the desired effects i.e. fixing the memory corruption issue caused
by the interaction of various functions with the cleanup code being
called mid stream hence invaliding the server pointer.
Treat this code as BETA / Work In Progress!
Any feedback welcomed.
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...> - 2008-04-24 22:24:34
|
In order to facilitate the ability to fix a number of core issues
with how qstat deals with servers I've been forced to commit some
sweeping changes which change the return of deal_with_ and send_
functions to return int's.
This is stage 1 of a 2 stage update which will allow some of the
nasty memory issues in qstat's core code to be fixed.
Included in this change is a version bump to 2.12. Until the rest
of the changes are complete please treat this as BETA code due
to the significant changes needed.
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...> - 2008-02-23 22:24:27
|
Hi Steve, The patch seemed to work well. Thanks you Pierre Steven Hartland wrote: > New feature valve added which caused an off by 2 error for fragmented > packets, fixed. > > Regards > Steve > > ----- Original Message ----- From: "Pierre Smolarek" > <pi...@un...> > To: <qst...@li...> > Sent: Saturday, February 23, 2008 8:53 PM > Subject: [QStat-devx] A2s Rules Truncated? > > >> Hello All. >> >> I've noticed that on some servers that I'm not getting a full list of >> rules (or players) return. >> >> Can someone try the following command and see if they can make any >> sense as to what the issue is? I suspect it's *not* related to the >> bzip2 flag. >> >> /qstat/qstat -a2s 81.19.219.104:27015 -R -d -d -d -d > > > ================================================ > 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...> - 2008-02-23 21:44:25
|
New feature valve added which caused an off by 2 error for fragmented packets, fixed.
Regards
Steve
----- Original Message -----
From: "Pierre Smolarek" <pi...@un...>
To: <qst...@li...>
Sent: Saturday, February 23, 2008 8:53 PM
Subject: [QStat-devx] A2s Rules Truncated?
> Hello All.
>
> I've noticed that on some servers that I'm not getting a full list of
> rules (or players) return.
>
> Can someone try the following command and see if they can make any sense
> as to what the issue is? I suspect it's *not* related to the bzip2 flag.
>
> /qstat/qstat -a2s 81.19.219.104:27015 -R -d -d -d -d
================================================
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-02-23 20:53:25
|
Hello All. I've noticed that on some servers that I'm not getting a full list of rules (or players) return. Can someone try the following command and see if they can make any sense as to what the issue is? I suspect it's *not* related to the bzip2 flag. /qstat/qstat -a2s 81.19.219.104:27015 -R -d -d -d -d Thanks, Pierre |
|
From: Pierre S. <pi...@un...> - 2008-02-19 01:14:43
|
Results look much better :) Thanks for the fast turn around Steve! Pierre. Steven Hartland wrote: > Fixed. > > ----- Original Message ----- > From: "Pierre Smolarek" <pi...@un...> > To: <qst...@li...> > Sent: Monday, February 18, 2008 10:32 PM > Subject: [QStat-devx] ETQWS player name truncation > > > >> Hello all, >> >> I've noticed that ETQWS seems to skip off the first few letters off a >> player name. See below for example. |
|
From: Steven H. <ki...@mu...> - 2008-02-19 00:00:56
|
Fixed. ----- Original Message ----- From: "Pierre Smolarek" <pi...@un...> To: <qst...@li...> Sent: Monday, February 18, 2008 10:32 PM Subject: [QStat-devx] ETQWS player name truncation > 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> > > > ------------------------------------------------------------------------- > 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.... |
1 message has been excluded from this view by a project administrator.
