Menu
▾
▴
qstat-devx
|
From: Steve J. <st...@qs...> - 2004-10-04 21:01:19
|
I see the problem. The GS protocol allows arbitrary per-player data. This
makes sense given that GS protocol is game agnostic (designed to work with any
game). However, qstat did not anticipate this. QStat has a fixed set of
per-player data (frags, score, team, etc) and only looks for certain per-player
data keys (frags_, ping_, team_, etc). Anything qstat does not recognize
becomes server rule data. I've never seen the keys in your example below and
they go far beyond what would be considered a "common" key like frags_. What
are roe_ and kia_ ??
The hack solution is to add support for these keys and map them to existing
player data fields. This would be awkward since roe_ might be mapped to
$(SHIP) or something equally incongruous.
The real solution is to add support for arbitrary player keys; a list of key,
value pairs. This is analogus to the server rules, but for each player. The
info could be accessed in the player template with something like $(INFO:key).
Maybe one of the qstat programmers will like the idea and take it on for the
next release. Steven? Ludwig?
I see the new GS protocol format finally removes the redudant data (frags_,
ping_, etc were repeated for each player). And it may remove the parsing
ambiguity when players have / in their name. Looks like a good thing. Is the
same query port used for the new protocol?
Your original message stated that we should be able to support GS master
servers. Did you mean to say GS game servers?
Steve
--- Jeff Jones <jj...@om...> wrote:
> Steve,
> Sorry, should have been more clear.
>
> When I do for example qstat -gps 213.228.239.251:1717 -R -P
> I get the data below. I have to include the -R to get the score data,
> however it is not formatted with the player data. The frags aren't the
> kills. The kills for player 1 are in the rule data under enemy_1, enemy_2
> and so on. I assume the enemy_1 var relates to in this case [CBI]Lucifer. My
> problem is that the player data is not formatted with the players using the
> new gamespy protocol. Qstat is waaaay fast compared to other methods I have
> seen. If I could just get over this hurdle, I'm good to go. Is there any
> way, using rules or whatever, that I can get the player data formatted with
> kills, goals, kia, etc? Also, see my info at the end of this email.
>
> Thanks
> Jeff
>
> qstat -gps 213.228.239.251:1717 -R -P
>
> ADDRESS PLAYERS MAP RESPONSE TIME NAME
> 213.228.239.251:1717 16/16 Pipeline 156 / 0 AAGP_GameTeamObjective -=
> Honorbude = =]vu[= - [AGF] = Germany =-
>
> gamename=armygame,gamever=2.1.0,hostport=1716,gametype=AAGP_GameTeamObjectiv
> e,numteams=2,gamemode=closedplaying,password=0,tour=2,official=1,leased=1,na
> to=0,miles=0,cheats=0,minhonor=1,maxhonor=100,groups=ALL,current_round=4/7,m
> ission_time=9:14,sv_punkbuster=1,tournament=0,ultimate_arena=0,thirdparty=0,
> custom=0,AdminName=,AdminEMail=,leader_0=0,leader_1=0,leader_2=0,leader_3=0,
> leader_4=-20,leader_5=-5,leader_6=0,leader_7=0,leader_8=80,leader_9=0,leader
> _10=170,leader_11=70,leader_12=0,leader_13=0,leader_14=0,leader_15=10,goal_0
> =0,goal_1=0,goal_2=0,goal_3=0,goal_4=10,goal_5=45,goal_6=5,goal_7=5,goal_8=9
> 0,goal_9=90,goal_10=90,goal_11=90,goal_12=90,goal_13=20,goal_14=60,goal_15=1
> 10,honor_0=20,honor_1=61,honor_2=9,honor_3=32,honor_4=20,honor_5=30,honor_6=
> 13,honor_7=41,honor_8=34,honor_9=32,honor_10=48,honor_11=8,honor_12=22,honor
> _13=16,honor_14=49,honor_15=60,roe_0=0,roe_1=0,roe_2=0,roe_3=0,roe_4=0,roe_5
> =0,roe_6=0,roe_7=0,roe_8=0,roe_9=0,roe_10=0,roe_11=0,roe_12=0,roe_13=0,roe_1
> 4=0,roe_15=0,kia_0=0,kia_1=0,kia_2=0,kia_3=0,kia_4=-20,kia_5=-20,kia_6=-30,k
> ia_7=-30,kia_8=-20,kia_9=-10,kia_10=-10,kia_11=-10,kia_12=-20,kia_13=-40,kia
> _14=-20,kia_15=-10,enemy_0=0,enemy_1=0,enemy_2=0,enemy_3=0,enemy_4=40,enemy_
> 5=10,enemy_6=0,enemy_7=10,enemy_8=10,enemy_9=20,enemy_10=10,enemy_11=50,enem
> y_12=0,enemy_13=20,enemy_14=60,enemy_15=50,score_t0=0,score_t1=3
> 0 frags 98ms [CBI]Lucifer
> 0 frags 245ms [ZG]Zelot
> 0 frags 120ms mamuska_pl
> 0 frags 82ms [SA-TS]AngryMissnry
> 0 frags 119ms Warrior^[PT]
> 0 frags 89ms [PDF]Dragon_Eyes[PT]
> 0 frags 92ms PT_To_Traves_PT
> 0 frags 105ms -=[BA]=-d(O_o)b-R_PL
> 0 frags 78ms [PDF]_I_U_R_[PT]
> 0 frags 224ms hirowin
> 0 frags 53ms [PDF]fire_gates(PT)
> 0 frags 34ms __]X=Ray[__
> 0 frags 104ms {DP}Jan_marijnissen
> 0 frags 183ms Germany2008
> 0 frags 89ms ]pMw[^Chupa-mos
> 0 frags 83ms DieOlli
>
>
> Also, here is some info on the Gamespy query.
> http://dev.kquery.com/index.php?article=42
> QUERY PACKET :
> FE FD 00 04 05 06 07 FF FF FF
> ^------^ Query Header
> ^---------^ 4 byte ID field
> (can be anything, is returned back to user in query
> results)
> ^- Request for server + rules info (00 to disable)
> ^- Request for Player information (00 to disable)
> ^- Request for Team information (00 to disable)
>
> Sending this in a VB program with the player information set to FF I get:
>
> leader_ goal_ honor_ player_ ping_ roe_ kia_ enemy_ 0 0 10
> Devils_Desires 159 0 0 0 0 0 22 =]TFC[=YOS 68 0 -10 0 0 0 17
> {-bot-}murek13-PL 95 0 0 0 0 0 85 [PAO]_sNeAk_[PL] 74 -183 -10 10 0 0 13
> hirowin 259 -68 -20 0 0 20 22 [SA-TS]AngryMissnry 77 0 -30 10 -10 10 40
> Gr3NiTy! 68 0 -40 30 0 30 10 [FRA]FrenchCisco 57 0 -40 0 0 65 13 Cpl_DeeP 78
> 0 -30 20 0 40 30 [PDF]fire_gates(PT) 59 0 -30 10 20 60 40 Debian-pt 99 0 -10
> 40 0 55 16 mamuska_pl 126 0 -30 60 0 50 74 [GMA.fla$h][at] 73 0 -40 30 -10
> 10 49 [ZG]Zelot 237 -5 -30 50 0 10 60 [CBI]Lucifer 96 -34 -30 70 0 65 33
> Black_Death-{GER}- 90 0 -30 60
>
> If only I knew C, I could do this easily.
>
>
>
>
>
> ----- Original Message -----
> From: "Steve Jankowski" <st...@qs...>
> To: "Jeffrey M. Jones" <jj...@om...>
> Sent: Monday, October 04, 2004 12:40 AM
> Subject: Re: AAO Server query help
>
>
> > I'm not sure I understand your question. What exactly do you want qstat
> to do?
> > If you want to get rid of the grepping step, then there's currently no
> > solution because there's no string comparison in the qstat templates.
> >
> > It's possible to run qstat from php and read the qstat output at the same
> time,
> > in php. Then you can search for your players and ignore everything else.
> >
> > If the gamespy masters are open, then I'm sure someone will add support.
> Post
> > a message to qst...@ya... with some pointers to gs master
> > protocol information.
> >
> > Thanks,
> >
> > Steve
> >
> > --- "Jeffrey M. Jones" <jj...@om...> wrote:
> >
> > > Steve,
> > >
> > > Sorry if you get this multiple times. I sent it to 3 different email
> > > addresses. Didn't know which one you were using.
> > >
> > > I have been using qstat for a while now to do queries of AAO servers.
> I
> > > have a tracker that tracks all the members of my clan. I am having to
> use a
> > > secondary php file to run queries to get player info. I use qstat with
> the
> > > $IPPADR|$PLAYERNAME template to get a complete list of all players. I
> then
> > > grep each player in my clan from this list. This tells me that they are
> > > online, and what server they are on. I then run a php file I hacked from
> AAO
> > > webspectator (which is very slow) to query just these servers and to
> give me
> > > all the player info. I parse all this info to a flat file for each clan
> > > member (sort of a log file if you will). It looks like this:
> > >
> > >
> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
> > > -[HigHoMan]-|60|2|2|60|40|20|0|65|69.25.18.233:1716|5/7
> > >
> > > I then parse this info out and take the stats from their highest round
> > > ,detect when the player goes offline, and update their info into a mysql
> > > database. It's kind of a sloppy mess, but it works.
> > >
> > > My question is this: Is it possible using a rules template with qstat
> that I
> > > can get the player info in a format I can use without having to use the
> php
> > > script? I have worked on this for weeks, and have not figured out any
> way to
> > > parse out the correct information. If the player data was numbered as
> the
> > > other variables, it would be somewhat easier. I can get it to parse out
> the
> > > enemy_0, kia_0, and all that. I just can't get it to output with the
> player
> > > name. Is there a quick hack I can do to make it do what I want? I am
> > > somewhat proficient in php, but not really in C/C++, but any info you
> can
> > > give me will be appreciated.
> > >
> > > Also, on another note, is it possible that qstat will support querying
> > > gamespy master servers again? It seems to be somewhat easy to do now.
> > > AABrowse contains the code to do it. The KQuery forums also have a lot
> of
> > > info on it.
> > >
> > > I'll be here banging my head on the desk -
> > >
> > > Thanks for your time.
> > >
> > > Jeff Jones
> > >
> > >
> > >
>
>
=== message truncated ===
|
|
From: Steven H. <ki...@mu...> - 2004-10-04 21:56:11
|
I've quickly added the basis of this to the CVS tree. Output only
currently supported under -xml.
Steve / K
----- Original Message -----
From: "Steve Jankowski" <st...@qs...>
To: "Jeff Jones" <jj...@om...>
Cc: <qst...@li...>
Sent: Monday, October 04, 2004 9:50 PM
Subject: [QStat-devx] Re: AAO Server query help
>I see the problem. The GS protocol allows arbitrary per-player data. This
> makes sense given that GS protocol is game agnostic (designed to work with any
> game). However, qstat did not anticipate this. QStat has a fixed set of
> per-player data (frags, score, team, etc) and only looks for certain per-player
> data keys (frags_, ping_, team_, etc). Anything qstat does not recognize
> becomes server rule data. I've never seen the keys in your example below and
> they go far beyond what would be considered a "common" key like frags_. What
> are roe_ and kia_ ??
>
> The hack solution is to add support for these keys and map them to existing
> player data fields. This would be awkward since roe_ might be mapped to
> $(SHIP) or something equally incongruous.
>
> The real solution is to add support for arbitrary player keys; a list of key,
> value pairs. This is analogus to the server rules, but for each player. The
> info could be accessed in the player template with something like $(INFO:key).
>
> Maybe one of the qstat programmers will like the idea and take it on for the
> next release. Steven? Ludwig?
>
>
> I see the new GS protocol format finally removes the redudant data (frags_,
> ping_, etc were repeated for each player). And it may remove the parsing
> ambiguity when players have / in their name. Looks like a good thing. Is the
> same query port used for the new protocol?
>
>
> Your original message stated that we should be able to support GS master
> servers. Did you mean to say GS game servers?
>
>
> Steve
>
>
> --- Jeff Jones <jj...@om...> wrote:
>
>> Steve,
>> Sorry, should have been more clear.
>>
>> When I do for example qstat -gps 213.228.239.251:1717 -R -P
>> I get the data below. I have to include the -R to get the score data,
>> however it is not formatted with the player data. The frags aren't the
>> kills. The kills for player 1 are in the rule data under enemy_1, enemy_2
>> and so on. I assume the enemy_1 var relates to in this case [CBI]Lucifer. My
>> problem is that the player data is not formatted with the players using the
>> new gamespy protocol. Qstat is waaaay fast compared to other methods I have
>> seen. If I could just get over this hurdle, I'm good to go. Is there any
>> way, using rules or whatever, that I can get the player data formatted with
>> kills, goals, kia, etc? Also, see my info at the end of this email.
>>
>> Thanks
>> Jeff
>>
>> qstat -gps 213.228.239.251:1717 -R -P
>>
>> ADDRESS PLAYERS MAP RESPONSE TIME NAME
>> 213.228.239.251:1717 16/16 Pipeline 156 / 0 AAGP_GameTeamObjective -=
>> Honorbude = =]vu[= - [AGF] = Germany =-
>>
>> gamename=armygame,gamever=2.1.0,hostport=1716,gametype=AAGP_GameTeamObjectiv
>> e,numteams=2,gamemode=closedplaying,password=0,tour=2,official=1,leased=1,na
>> to=0,miles=0,cheats=0,minhonor=1,maxhonor=100,groups=ALL,current_round=4/7,m
>> ission_time=9:14,sv_punkbuster=1,tournament=0,ultimate_arena=0,thirdparty=0,
>> custom=0,AdminName=,AdminEMail=,leader_0=0,leader_1=0,leader_2=0,leader_3=0,
>> leader_4=-20,leader_5=-5,leader_6=0,leader_7=0,leader_8=80,leader_9=0,leader
>> _10=170,leader_11=70,leader_12=0,leader_13=0,leader_14=0,leader_15=10,goal_0
>> =0,goal_1=0,goal_2=0,goal_3=0,goal_4=10,goal_5=45,goal_6=5,goal_7=5,goal_8=9
>> 0,goal_9=90,goal_10=90,goal_11=90,goal_12=90,goal_13=20,goal_14=60,goal_15=1
>> 10,honor_0=20,honor_1=61,honor_2=9,honor_3=32,honor_4=20,honor_5=30,honor_6=
>> 13,honor_7=41,honor_8=34,honor_9=32,honor_10=48,honor_11=8,honor_12=22,honor
>> _13=16,honor_14=49,honor_15=60,roe_0=0,roe_1=0,roe_2=0,roe_3=0,roe_4=0,roe_5
>> =0,roe_6=0,roe_7=0,roe_8=0,roe_9=0,roe_10=0,roe_11=0,roe_12=0,roe_13=0,roe_1
>> 4=0,roe_15=0,kia_0=0,kia_1=0,kia_2=0,kia_3=0,kia_4=-20,kia_5=-20,kia_6=-30,k
>> ia_7=-30,kia_8=-20,kia_9=-10,kia_10=-10,kia_11=-10,kia_12=-20,kia_13=-40,kia
>> _14=-20,kia_15=-10,enemy_0=0,enemy_1=0,enemy_2=0,enemy_3=0,enemy_4=40,enemy_
>> 5=10,enemy_6=0,enemy_7=10,enemy_8=10,enemy_9=20,enemy_10=10,enemy_11=50,enem
>> y_12=0,enemy_13=20,enemy_14=60,enemy_15=50,score_t0=0,score_t1=3
>> 0 frags 98ms [CBI]Lucifer
>> 0 frags 245ms [ZG]Zelot
>> 0 frags 120ms mamuska_pl
>> 0 frags 82ms [SA-TS]AngryMissnry
>> 0 frags 119ms Warrior^[PT]
>> 0 frags 89ms [PDF]Dragon_Eyes[PT]
>> 0 frags 92ms PT_To_Traves_PT
>> 0 frags 105ms -=[BA]=-d(O_o)b-R_PL
>> 0 frags 78ms [PDF]_I_U_R_[PT]
>> 0 frags 224ms hirowin
>> 0 frags 53ms [PDF]fire_gates(PT)
>> 0 frags 34ms __]X=Ray[__
>> 0 frags 104ms {DP}Jan_marijnissen
>> 0 frags 183ms Germany2008
>> 0 frags 89ms ]pMw[^Chupa-mos
>> 0 frags 83ms DieOlli
>>
>>
>> Also, here is some info on the Gamespy query.
>> http://dev.kquery.com/index.php?article=42
>> QUERY PACKET :
>> FE FD 00 04 05 06 07 FF FF FF
>> ^------^ Query Header
>> ^---------^ 4 byte ID field
>> (can be anything, is returned back to user in query
>> results)
>> ^- Request for server + rules info (00 to disable)
>> ^- Request for Player information (00 to disable)
>> ^- Request for Team information (00 to disable)
>>
>> Sending this in a VB program with the player information set to FF I get:
>>
>> leader_ goal_ honor_ player_ ping_ roe_ kia_ enemy_ 0 0 10
>> Devils_Desires 159 0 0 0 0 0 22 =]TFC[=YOS 68 0 -10 0 0 0 17
>> {-bot-}murek13-PL 95 0 0 0 0 0 85 [PAO]_sNeAk_[PL] 74 -183 -10 10 0 0 13
>> hirowin 259 -68 -20 0 0 20 22 [SA-TS]AngryMissnry 77 0 -30 10 -10 10 40
>> Gr3NiTy! 68 0 -40 30 0 30 10 [FRA]FrenchCisco 57 0 -40 0 0 65 13 Cpl_DeeP 78
>> 0 -30 20 0 40 30 [PDF]fire_gates(PT) 59 0 -30 10 20 60 40 Debian-pt 99 0 -10
>> 40 0 55 16 mamuska_pl 126 0 -30 60 0 50 74 [GMA.fla$h][at] 73 0 -40 30 -10
>> 10 49 [ZG]Zelot 237 -5 -30 50 0 10 60 [CBI]Lucifer 96 -34 -30 70 0 65 33
>> Black_Death-{GER}- 90 0 -30 60
>>
>> If only I knew C, I could do this easily.
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Steve Jankowski" <st...@qs...>
>> To: "Jeffrey M. Jones" <jj...@om...>
>> Sent: Monday, October 04, 2004 12:40 AM
>> Subject: Re: AAO Server query help
>>
>>
>> > I'm not sure I understand your question. What exactly do you want qstat
>> to do?
>> > If you want to get rid of the grepping step, then there's currently no
>> > solution because there's no string comparison in the qstat templates.
>> >
>> > It's possible to run qstat from php and read the qstat output at the same
>> time,
>> > in php. Then you can search for your players and ignore everything else.
>> >
>> > If the gamespy masters are open, then I'm sure someone will add support.
>> Post
>> > a message to qst...@ya... with some pointers to gs master
>> > protocol information.
>> >
>> > Thanks,
>> >
>> > Steve
>> >
>> > --- "Jeffrey M. Jones" <jj...@om...> wrote:
>> >
>> > > Steve,
>> > >
>> > > Sorry if you get this multiple times. I sent it to 3 different email
>> > > addresses. Didn't know which one you were using.
>> > >
>> > > I have been using qstat for a while now to do queries of AAO servers.
>> I
>> > > have a tracker that tracks all the members of my clan. I am having to
>> use a
>> > > secondary php file to run queries to get player info. I use qstat with
>> the
>> > > $IPPADR|$PLAYERNAME template to get a complete list of all players. I
>> then
>> > > grep each player in my clan from this list. This tells me that they are
>> > > online, and what server they are on. I then run a php file I hacked from
>> AAO
>> > > webspectator (which is very slow) to query just these servers and to
>> give me
>> > > all the player info. I parse all this info to a flat file for each clan
>> > > member (sort of a log file if you will). It looks like this:
>> > >
>> > >
>> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|1|0|80|40|30|0|58|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|80|40|30|0|60|69.25.18.233:1716|3/7
>> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|1|75|40|25|0|61|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|65|40|25|0|63|69.25.18.233:1716|4/7
>> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
>> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
>> > > -[HigHoMan]-|60|2|2|60|40|20|0|63|69.25.18.233:1716|5/7
>> > > -[HigHoMan]-|60|2|2|60|40|20|0|65|69.25.18.233:1716|5/7
>> > >
>> > > I then parse this info out and take the stats from their highest round
>> > > ,detect when the player goes offline, and update their info into a mysql
>> > > database. It's kind of a sloppy mess, but it works.
>> > >
>> > > My question is this: Is it possible using a rules template with qstat
>> that I
>> > > can get the player info in a format I can use without having to use the
>> php
>> > > script? I have worked on this for weeks, and have not figured out any
>> way to
>> > > parse out the correct information. If the player data was numbered as
>> the
>> > > other variables, it would be somewhat easier. I can get it to parse out
>> the
>> > > enemy_0, kia_0, and all that. I just can't get it to output with the
>> player
>> > > name. Is there a quick hack I can do to make it do what I want? I am
>> > > somewhat proficient in php, but not really in C/C++, but any info you
>> can
>> > > give me will be appreciated.
>> > >
>> > > Also, on another note, is it possible that qstat will support querying
>> > > gamespy master servers again? It seems to be somewhat easy to do now.
>> > > AABrowse contains the code to do it. The KQuery forums also have a lot
>> of
>> > > info on it.
>> > >
>> > > I'll be here banging my head on the desk -
>> > >
>> > > Thanks for your time.
>> > >
>> > > Jeff Jones
>> > >
>> > >
>> > >
>>
>>
> === message truncated ===
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> 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 (023) 8024 3137
or return the E.mail to pos...@mu....
|
|
From: Steven H. <ki...@mu...> - 2004-10-27 15:41:32
|
Someone being playing :P Cant even get close to compiling the current version: /usr/local/work/utils/qstat/qstat2/qstat.c:3073: undefined reference to `get_debug_level' /usr/local/work/utils/qstat/qstat2/qstat.c:3073: undefined reference to `set_debug_level' /usr/local/work/utils/qstat/qstat2/qstat.c:3274: undefined reference to `malformed_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:3323: undefined reference to `get_debug_level' /usr/local/work/utils/qstat/qstat2/qstat.c:3324: undefined reference to `print_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:3326: undefined reference to `get_debug_level' /usr/local/work/utils/qstat/qstat2/qstat.c:3327: undefined reference to `dump_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_qw_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:5502: undefined reference to `print_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:5586: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_q1qw_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:5715: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_doom3master_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:5958: undefined reference to `malformed_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_qwmaster_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:6092: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_tribesmaster_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:6221: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_unrealmaster_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:7657: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o: In function `deal_with_halflife_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:7687: undefined reference to `print_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:7874: undefined reference to `print_packet' /var/tmp//ccrjNDPD.o:/usr/local/work/utils/qstat/qstat2/qstat.c:9873: more undefined references to `print_packet' follow /var/tmp//ccrjNDPD.o: In function `deal_with_doom3_packet': /usr/local/work/utils/qstat/qstat2/qstat.c:10198: undefined reference to `malformed_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:10216: undefined reference to `malformed_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:10236: undefined reference to `malformed_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:10246: undefined reference to `malformed_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:10293: undefined reference to `malformed_packet' /var/tmp//ccrjNDPD.o:/usr/local/work/utils/qstat/qstat2/qstat.c:10322: more undefined references to `malformed_packet' follow /var/tmp//ccrjNDPD.o: In function `raw_display_server': /usr/local/work/utils/qstat/qstat2/qstat.c:1193: undefined reference to `send_ut2004master_request_packet' /usr/local/work/utils/qstat/qstat2/qstat.c:1193: undefined reference to `deal_with_ut2004master_packet' *** Error code 1 ================================================ 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 (023) 8024 3137 or return the E.mail to pos...@mu.... |
|
From: Steven H. <ki...@mu...> - 2004-10-27 15:56:36
|
Looks like this was an old make file? needed: SRC = qstat.c config.c hcache.c template.c debug.c ut2004.c md5.c qserver.c Plus: #include <stdarg.h> missing from debug.h possibly OS dependent? ----- Original Message ----- From: "Steven Hartland" <ki...@mu...> > Someone being playing :P > Cant even get close to compiling the current version: .... ================================================ 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 (023) 8024 3137 or return the E.mail to pos...@mu.... |
|
From: Ludwig N. <l-...@us...> - 2004-10-27 21:15:19
|
Steven Hartland wrote: > Looks like this was an old make file? > needed: > SRC = qstat.c config.c hcache.c template.c debug.c ut2004.c md5.c qserver.c We need to clean up that mess. There's GNUmakefile and Makefile, since make here prefers GNUmakefile I always modified that. > Plus: > #include <stdarg.h> > missing from debug.h possibly OS dependent? No idea. If it's needed, add it. What OS are you compiling on? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2004-10-27 21:34:40
|
My vote goes with remove GNUMakefile. gmake will fall
back to Makefile iirc.
FreeBSD 5.2.1 is my standard compile box. Changes committed
worth testing on linux to see if they work.
Steve / K
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
>> #include <stdarg.h>
>> missing from debug.h possibly OS dependent?
>
> No idea. If it's needed, add it. What OS are you compiling on?
================================================
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 (023) 8024 3137
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2004-10-27 21:55:24
Attachments:
configure.ac
Makefile.am
|
Steven Hartland wrote: > My vote goes with remove GNUMakefile. gmake will fall > back to Makefile iirc. I'd vote for dropping the custom Makefiles and use automake. Since qstat doesn't use any fancy stuff files are pretty simple. Attached are configure.ac and Makefile.am as a start. Just copy them into the qstat dir and run "autoreconf -f -i". That gets us a lot for free on un*x. I have no idea if it's useful on windows though. > FreeBSD 5.2.1 is my standard compile box. Changes committed > worth testing on linux to see if they work. Works, thanks. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2004-10-27 22:10:22
|
As u say doesnt exist on windows boxes so not really an option :(
Dont u wish it was all unix :P
Steve / K
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
> Steven Hartland wrote:
>> My vote goes with remove GNUMakefile. gmake will fall
>> back to Makefile iirc.
>
> I'd vote for dropping the custom Makefiles and use automake. Since
> qstat doesn't use any fancy stuff files are pretty simple. Attached
> are configure.ac and Makefile.am as a start. Just copy them into the
> qstat dir and run "autoreconf -f -i". That gets us a lot for free on
> un*x. I have no idea if it's useful on windows 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 (023) 8024 3137
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2004-10-27 22:22:38
|
Steven Hartland wrote: > As u say doesnt exist on windows boxes so not really an option :( > Dont u wish it was all unix :P Doesn't it work in cygwin? If not, you or whoever wants to compile on windows can maintain a separate Makefile, VC project file or whatever. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steve J. <st...@qs...> - 2004-10-28 04:19:25
|
I suggest renaming the current Makefile to Makefile.win and rename GNUMakefile to Makefile. 99% of windows users do not compile qstat, they use a pre-built binary. So requiring them to use a special build command is ok: nmake -f Makefile.win The GNUMakefile uses constructs not supported by old-school make. However, gmake is universal now (even ships on most commercial unixes) so making that a requirement for compiling qstat is fine. We'll still need to keep two makefiles in-sync. Looks like Steven is reorganizing the code; please try to update the windows makefile whenever the unix makefile is updated. And don't forget to update COMPILE.txt Sourceforge provides shell access to a compile farm. This can be used to validate changes against other platforms. Don't know if they have a windows compile target. MS provides the VC++ command line compile tools for free now: http://msdn.microsoft.com/visualc/vctoolkit2003/ Steve --- Steven Hartland <ki...@mu...> wrote: > As u say doesnt exist on windows boxes so not really an option :( > Dont u wish it was all unix :P > > Steve / K > ----- Original Message ----- > From: "Ludwig Nussel" <l-...@us...> > > > Steven Hartland wrote: > >> My vote goes with remove GNUMakefile. gmake will fall > >> back to Makefile iirc. > > > > I'd vote for dropping the custom Makefiles and use automake. Since > > qstat doesn't use any fancy stuff files are pretty simple. Attached > > are configure.ac and Makefile.am as a start. Just copy them into the > > qstat dir and run "autoreconf -f -i". That gets us a lot for free on > > un*x. I have no idea if it's useful on windows 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 (023) 8024 3137 > or return the E.mail to pos...@mu.... > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
|
From: Steven H. <ki...@mu...> - 2004-10-28 10:08:42
|
Not true I for one cant compile on any of my machines with that make file.
As Ludwig said we don't do anything special in the make file so just ditching
the GNU one and going with lowest common denominator is the best way
to go imo.
Are we looking to have a big clear up with the current code base?
Modularising it some what, proper API etc?
Steve / K
----- Original Message -----
From: "Steve Jankowski" <st...@qs...>
To: <qst...@li...>
Sent: 28 October 2004 05:19
Subject: Re: [QStat-devx] Current cvs version total broken
>I suggest renaming the current Makefile to Makefile.win
> and rename GNUMakefile to Makefile.
>
> 99% of windows users do not compile qstat, they use a pre-built binary. So
> requiring them to use a special build command is ok: nmake -f Makefile.win
>
> The GNUMakefile uses constructs not supported by old-school make. However,
> gmake is universal now (even ships on most commercial unixes) so making that a
> requirement for compiling qstat is fine.
>
> We'll still need to keep two makefiles in-sync. Looks like Steven is
> reorganizing the code; please try to update the windows makefile whenever the
> unix makefile is updated.
>
> And don't forget to update COMPILE.txt
>
> Sourceforge provides shell access to a compile farm. This can be used to
> validate changes against other platforms. Don't know if they have a windows
> compile target. MS provides the VC++ command line compile tools for free now:
> http://msdn.microsoft.com/visualc/vctoolkit2003/
>
> 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 (023) 8024 3137
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2004-10-28 17:13:42
|
Steven Hartland wrote: > Are we looking to have a big clear up with the current code base? > Modularising it some what, proper API etc? I've put the ut2004 stuff in a separate file since that one big qstat.c just gets more and more confusing and also takes long to compile. Cleaning up everything would require quite some time. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Ludwig N. <l-...@us...> - 2004-10-28 17:06:47
|
Steve Jankowski wrote: > I suggest renaming the current Makefile to Makefile.win > and rename GNUMakefile to Makefile. > > 99% of windows users do not compile qstat, they use a pre-built binary. So > requiring them to use a special build command is ok: nmake -f Makefile.win So you would be fine with automake for the Linux side as well? > [...] > Sourceforge provides shell access to a compile farm. This can be used to > validate changes against other platforms. Don't know if they have a windows > compile target. MS provides the VC++ command line compile tools for free now: > http://msdn.microsoft.com/visualc/vctoolkit2003/ Had do find someone to install this in Windows, the installer doesn't work in wine. There is no make inside and winsock stuff is missing so it's not possible to compile qstat with that package. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X