The New Power BZAdmin Client Made Powerfull By NN

[nn]

Hi all,

I have been thinking that bzadmin only did a fraction of what i would like it to.
So after that I Spent 2 or 3 days making it do more!!!

Here is the new Power Bzadmin.

Download it at:

http://userbin.net/bzadmin.tar


Some of the stuff it can do I decided not to show you can find it for your self




Some of the new stuff it can do :

nn@userbin ~/root/modeltool/bzflag/src/bzadmin $ ./bzadmin -all most -ui stdout nn-testingadmin@bzfmaps.net:6203 > show.txt
{Possible_Msg_types:bzdb,chat,admin,join,kill,leave,pause,ping,rabbit,score,spawn,time,over,tankpos,flags,grab,drop,shots,shotend,tele,extra}
Connecting to nn-testingadmin@bzfmaps.net:6203

on mode most the first thing it will dump is this

Var _agilityAdVel Was set To 2.25
Var _agilityTimeWindow Was set To 2
Var _agilityVelDelta Was set To 0.3
Var _ambientLight Was set To none
Var _angleTolerance Was set To 0.05
Var _angularAd Was set To 1.5
Var _avenueSize Was set To 2.0*_boxBase
Var _baseSize Was set To 60.0
Var _boxBase Was set To 30.0
Var _boxHeight Was set To 6.0*_muzzleHeight

............


*** Received BZDB update, 49 variables updated.
Var _wingsSlideTime Was set To 0.0
Var _worldSize Was set To 800.0
Var poll Was set To 136643744
*** Received BZDB update, 3 variables updated.


FU:|R*,0,1,0|371.522766 100.000000 396.838837|371.522766 33.566715 396.838837|371.522766 100.000000 0.000000|0.000000,2.996597,14.683324|
FU:|G*,1,2,0|337.080597 0.000000 -27.299526|337.080597 60.059994 -27.299526|337.080597 0.000000 0.000000|0.000000,2.996597,14.683324|
FU:|PZ,2,1,1|2.184381 50.000000 103.496994|68.473549 2.050000 -263.562653|68.473549 0.000000 0.000000|0.000000,2.996597,14.683324|

.........

etc...


then these message types will start showing up

[SERVER->] BZFlag server 2.0.11.20071221-DEVEL-linux-gnu-SDL, http://BZFlag.org/
[SERVER->] **************************************
[SERVER->] * Welcome to Striders map! *
[SERVER->] * Hosted by ryanakca on nn's box! *
[SERVER->] * Rules *
[SERVER->] * - Don't cheat/hack. *
[SERVER->] * - F5ing is cheating. *
[SERVER->] * - Play nice *
[SERVER->] * - No asking for admin. *
[SERVER->] * - Have fun *
[SERVER->] **************************************
[SERVER->] You are in observer mode.


FG:noiz_on!|WG,61,2,1|
FD:noiz_on!|WG,61,2,1|
Shot From:IZBOYTime,ID,FT,Pos,Vel,dt 1213.663818,17920,BU|101.453751 0.250000 -323.320770|-126.478195 0.000000 288.416687|0.000000

*** 'mrbean' has respawned At: 2.432500, -95.203438 -176.482101 0.001000 .

Shot end:scruffy2ID: 31488 Reason: 1
FG:Easy Target|F,15,5,1|
FD:Easy Target|F,15,5,1|
*** 'Easy Target' destroyed by 'scruffy2'.
scruffy2 Score: 36 wins 21 loss 1 tk's
Easy Target Score: 1 wins 2 loss 0 tk's

*** 'scruffy2' has respawned At: 2.671439, 22.283300 -384.750244 51.000000 .
*** 'magflag' has respawned At: 4.359603, 10.796240 -382.774872 51.000000 .
*** 'IZBOY' has respawned At: 0.966888, 24.035931 -381.417908 51.000000 .
*** 'Blizzard' has respawned At: 0.126142, 18.156151 -381.961731 51.000000 .
*** 'Rocococo' has respawned At: 4.915616, 6.298650 -381.173492 51.000000 .
FG:mrbean|G*,1,3,0|
FD:mrbean|G*,1,3,0|



Have fun,
NN

[blast]

It would be nice if you released a patch file (generate this with 'svn diff'). The binary probably won't work on most linux systems unless they have the exact same libraries. So, a patch would probably be about 30KB at most, and this download was 6MB...

[macsforme]

nn, if you want to get this into the main source code, you will want to submit a patch to the BZFlag project on SourceForge.net. That is were we monitor user-submitted changes to the source code.

As for the idea idea, it looks like you've put a lot of work into it, and it might be useful for some users who use bzadmin for logging. However, there are more elegant solutions for logging, such as plugins. A plugin can monitor changes in the game and log them to a file with a lot more flexibility than modifying the bzadmin source code. Also, a plugin can do this without taking up a player slot (and, in the 2.0.x client, manipulating your server's placement relative to the others by adding an observer user who isn't actually there). I'm not saying that there aren't reasons to keep bzadmin clients connected, but for logging purposes there are better solutions that you might want to consider.

[JeffM]

in addition to Constitution'as comments, this method won't work in 3.0 as player updates are not sent to bzadmin clients to save bandwith.

what advantage does having inaccurate laggy, non compensated player position values give an admin?

why would they not use the actual client that is able to at least do some form of interpolation?

We arn't trying to be mean and shoot you down, but if you intend for this to be taken as a serious enhancement we need to discuss it.

also your tarball has 6 extra megs of cruft, the entire thing can be broken down into a small patch.

[gnu-sense]

I've been hacking something similar to this for a while, when I've had the chance to work on it. There are a couple reasons I've been doing this, partly idiosyncratic to my purposes, but possibly generally useful. I'll mention these below so others can evaluate them:

(1) my original purpose: to transcode recorded game files into a form that I can use for analysis. I set up a replay server, connect with the admin client which logs the data in the format I want.

(2) recording games from an server not so enabled. While lag is an issue in this, it could be helpful for admin purposes to have the ability for one or more admins to bring up a recording client when the server is not specifically (or correctly) set up for recording.

Regarding (1), there are much better ways that one can imagine doing this, but bzadmin is far easier to modify than bzflag or bzfs, and its implementation of bzproto is much more intelligible than that elsewhere in the code base. Regarding (2), one could just tell people not to expect to record when it is not enabled (in fact the way it works now) but I have seen far too many cases where saving evidence of this type would have been useful (e.g. in catching cheaters. I know it's laggy, but the alternative in many cases is nothing at all). Also people may just like to enjoy their own recordings. Why not let them?

Apart from lack of time so far, there are a number of reasons I haven't finished this. First, one needs to control the output of the messages in a way that is sensible. bzadmin allows this in a way that is not hard to extend, and i don't know if nn's version does this or how well, but I felt that this needed to be thought through carefully before committing to a specific implementation. A second and related concern is coding style. This is a little complicated to discuss, but the different parts of the code I'm referring to (especially game recording and bzadmin) are apparently written by different people with different coding styles. I adopted one of these practices, but this is at odds with other code in the client with related functions (msgStrings.cxx, I think). I couldn't see immediately how to reconcile these, and/or remove the redundancies.

If anyone has any reactions or general recommendations regarding directions for bzadmin, I'd like to hear it. I'm disappointed to hear that future versions will not be able to see some messages. Could this be a default that is configurable, depending on a handshaking protocol between client and server (which checks for authorization, etc.)?

gnu-sense

[DTRemenak]

A modified version of BZAdmin may be configured to request a "normal set" of messages instead of a "bzadmin set." We just clamp it by default in 3.0 to save server bandwidth.

That said, logging and recording are both far better done on the server end. And cheat detection needs to be done on either the server or a fully lag-compensated client; bzadmin is really insufficient for this task.