[bfprog] GameSpy v3 (BF2) Parsing.....

[EvilYoda]

Silly me... I figured this out. I'm still not sure how qstat deals with
spanned packets... But it was obvious once I stopped being a goon.. I
was transposing some digits, and I see that when a data chunk is
restarted in gamespy the first byte before the chunk is resumed is the
index you are starting at again.  For example, player #62 may have been
truncated in the first packet, but then you receive packet #2 with
player#62 repeated, and you will get the full name. Preceding the name
(or whatever data element is in that chunk, like score, or deaths) there
is a byte that says what index the data element resumes at.

EvilYoda wrote:

>Hi,
>
>Thanks for your responses!
>
>I've been looking at the qstat code and it is very relatively complex
>and supports many many games... It also does not provide all the data
>returned by the query for some reason... I don't know if it is just this
>early version.. But I'm the same fella who just wrote a PHP wrapper for
>the latest version (different e-mail address here!)
>http://www.unholyplayground.com/BF2Status/
>
>But... I didn't really say why I was creating a BF2 query in java... The
>reason is that for BF1 I created a web-based database driven admin tool,
>(admins had separate logins, admin cmds logd to DB, player bans kicks
>posted to web-page and had an unban request system, and integrated into
>stat DB for finding tards) The tool needed gamespy to figure out the
>teams. The admin.listplayers does not do it. So this is just one small
>piece required for me to port my web based admin tool to BF2, and I need
>it in java. I thought about simply calling qstat, but I plan on
>releasing it this time (I've been working on and using this tool for
>over 2 years now), and I don't want to make the setup that complex. I'm
>almost there... I just have to keep reading qstat to figure out how they
>deal with these crazy packets. I don't see anything in the gs3 specific
>code, so it makes me think maybe it has been this way a long time and
>the underlying query layers and assembly stuff just knows how to deal
>with it. But it is a pretty complex query tool, so I have a lot of
>reading to do.
>
>Anyways, I'll post something if I find out how to deal with split chunks.
>
>--brigham (evil yoda)
>
>ScratchMonkey wrote:
>
>  
>
>>--On Sunday, June 19, 2005 11:10 PM -0700 James Gurney
>><james at globalmegacorp.org> wrote:
>>
>>    
>>
>>>Support for the new protocol has been added to qstat (at least, the CVS
>>>version). You can get it from
>>>http://www.sourceforge.net/projects/qstat -
>>>there are cvs instructions there.
>>>      
>>>
>>If you're looking for a project, I'd suggest converting qstat to
>>become a general library that can be invoked by other languages (Perl,
>>PHP, Python). You can probably host it at SourceForge or check the
>>Subversion site for lists of free subversion providers. Also look into
>>Google's "Summer of Code" project.
>>
>>
>>_______________________________________________
>>BFProg mailing list
>>BFProg at lists.matureasskickers.net
>>http://lists.matureasskickers.net/mailman/listinfo/bfprog
>>
>>    
>>
>
>_______________________________________________
>BFProg mailing list
>BFProg at lists.matureasskickers.net
>http://lists.matureasskickers.net/mailman/listinfo/bfprog
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.matureasskickers.net/pipermail/bfprog/attachments/20050620/982a301d/attachment-0001.html