next »

[GedankenBlitz]

Aloha hey!

After a quick glimpse, it seems like this question has not been covered or at least answered in depth.

How should the perfect logfile for b3 look like?

Now that quake3 is open source for quite a while and most games using its engine (or ioquake) are open source as well, we have the power to create the ultimate logfile! Furthermore, commands like /rcon status and such could also be modified.
Please not that this could be used as a guideline for other games which use the ioquake engine, as I'm certain they are willing to improve their code.

I only took a quick look at the regexps b3 uses and it seems like some of the existing loglines could be improved, i.e. to use client ids rather than names for say/say_team. The kill logline instead seems to include same information twice.
Other events, like dropping items, calling votes, awards and such are missing completely. They might not be usefull to plain b3 though.
Thus the logfile could use loglevels, i.e. with a new cvar g_logLevel. If one were to run xlrstats, he'd have to choose the loglevel which includes damage loglines. Otherwise the log would be small and short.

I don't mind sacrifying readability from the point of an admin. That is only client ids and numbers instead of names all over.

Even if you are no b3 developer, please help by naming events in game which you can think of and their importance (as in loglevel ).
These don't have to be quake3 (based) specific either.

Currently I think of:

• Connect, disconnect
• Join game (i.e. after successfull connect)
• Join team
• Say, say team, private message
• Callvote, vote
• Damage (self, others, team, world)
• Kill
• Die
• Pickup item
• Drop item
• Scoring (not neccessarily the same as killing in some gametypes)
• Changing player settings like name, spray, whatever
• Gaining awards
• Change of server setting (like point- or timelimit)
• ...

Awards, item pickup and dropping should include most gametype specific events (like capturing a flag, dropping, returning, defending etc.).
Some events might be caught by monitoring ClientUserinfoChanged without separate loglines. What's nice coding practice here?

I assume the ideal logline should look like "$eventname: ($cid) $additional_information", such as "say: 0 2 hey there"?
Should loglines include text like MOD_CHAINSAW or just a number?


I honestly don't know what sort of response to expect. Even if this does not help the general public, I'll build my very own perfect-log-b3-game
P.S.: If this is the wrong forum section, feel free to move

[Courgette]

Hi GedankenBlitz

First, let me tell you that having a consistent format between Q3 like games (and mods) is an utopia. Having guidelines for game developers who care about having a good admin experience with B3 is still very useful info. Nice move here

Indeed what you described is what we like to see in game logs. Now let me write down my own remarks :

logfile :
* consistent information (some games have bugs that make some of the line have incorrect slot id in them, we then have to cross check slot id with character name)
* always refer to players by something more identifying than their name (slot id or better guid)
* have the game server log as much info as it can (call votes, vote results are never seen but would be useful)

rcon must-haves :
* status : should list all connected players with slot id. Having it provide lots of info could save lots of dumpuser queries
* tell <player> <msg> : It allows the bot to talk in private message to players avoiding chat zone spamming and allowing sensitive info transmition
* dumpuser <player> : should dump as much info as possible. Should give guid, team, ip, etc. Often missing here is the muted status

Other events, like dropping items, calling votes, awards and such are missing completely. They might not be usefull to plain b3 though.

not required but they allow useful or funny stuf. callvote spam preventing ! I want that for years

loglevel which includes damage loglines.

some games have cvar like g_loghits that does such a thing. Indeed it would be nice to see more game having such a cvar

Should loglines include text like MOD_CHAINSAW or just a number?

I like constant names as they are more meaningful than numbers. There is no additional cost at converting such a constant to B3 event.

From what game community are you from ? and what game are you working on ?

[GedankenBlitz]

First of all, thanks for your detailed reply  

First, let me tell you that having a consistent format between Q3 like games (and mods) is an utopia.

I'm afraid you're right. Especially since there are so many forks, thanks to open source. Nevertheless it would be a good idea to include some sort of README inside b3 download which states "If you want to have full b3 support for your game, follow these rules" (dpmaster has such a thing). Maybe some game authors would actually read it

* consistent information (some games have bugs that make some of the line have incorrect slot id in them, we then have to cross check slot id with character name)

I have not seen this yet, at least not in the games I'm familiar with. Could you give an example?

* always refer to players by something more identifying than their name (slot id or better guid)

I think slot id is better suited to "identify" a player, since some games don't have GUIDs or they are not realiable. Does this mean you want name and slot id in the log, or would the slot id be enough (assuming it's always correct ) ?

* have the game server log as much info as it can (call votes, vote results are never seen but would be useful)

This is why I'd like loglevels. The log grows really really quick if you log everything. With a cvar for this, one could only activate the loglines he really needs.

* status : should list all connected players with slot id. Having it provide lots of info could save lots of dumpuser queries

Since this is engine sided, it does not have access to certain information. Currently it includes slot id, name and ip for each player as well as the current map. I doubt score, ping, lastmsg, qport and rate are usefull. So what do add? GUIDs come into mind.

* tell <player> <msg> : It allows the bot to talk in private message to players avoiding chat zone spamming and allowing sensitive info transmition

This can be done either in engine or gamecode, while the first method should work with all mods (maybe tell ioquake team about this). If you want those messages to actually be messages, like the usual chat text by other players, it might become a litte hacky (and game/mod specific), since there is no client behind the message. If the messages should just be printed at the client, everything's fine (but they would not be handled as chat messages clientside). I prefer just printing them
On a sidenote, would it be usefull if the gamecode hides messages starting with a certain prefix ("!" as default in b3, configurable via cvar in game) so other players don't see these commands (less spam) and one could use plaintext login functions, like "!login mypassword", which would otherwise be visible to all playery? I think this does not interfere normal chat, since real chatmessages messages seldomly start with "!"

* dumpuser <player> : should dump as much info as possible. Should give guid, team, ip, etc. Often missing here is the muted status

This is also part of the engine. It simply prints the client's userinfo. If userinfo does not contain a certain information, the engine won't know about it (see note about /rcon status). This could be moved/copied to gamecode to print further information which only gamecode knows about. Muted status is such a thing, if the game/mod has support for it at all.

callvote spam preventing ! I want that for years

How could b3 prevent callvote spam? It could either disable votes alltoghether or kick the player. Anything else, like vote-muting the player would require support by a gamecode serverside mod.

some games have cvar like g_loghits that does such a thing.

This would be "replaced" by g_logLevel. Let's say it defaults to 0 and hitlogs are printed at loglevel 1 and above.

From what game community are you from ? and what game are you working on ?

I'm working on World of Padman. Since the code is similar across most ioquake games, I could also apply these modifications to Smokin' Guns, Open Arena and others (at least on my own server, since I'm not part of their official dev team). But as stated above, I'm rather certain their devs would be willing to incorporate the changes we talk about.

Which additional commands could b3 need? The kick command could also use a reason as additional argument and print this to (the kicked) client for example.


P.S.: I'm currently thinking about some sort of interface between gamecode and b3. Gamecode could maintain a separate userinfo for each client with additional information and do a logprint each time it changes. At the same time, it could provide a command to set specific key/value pairs inside that userinfo, like muted/votemuted or any mod-specific data. How does that sound?

[Courgette]

* consistent information (some games have bugs that make some of the line have incorrect slot id in them, we then have to cross check slot id with character name)

I have not seen this yet, at least not in the games I'm familiar with. Could you give an example?

We have met such a bug in Urban Terror : http://www.bigbrotherbot.net/forums/urt/b3-bot-sometimes-mix-up-client-id's/

* always refer to players by something more identifying than their name (slot id or better guid)

I think slot id is better suited to "identify" a player, since some games don't have GUIDs or they are not realiable. Does this mean you want name and slot id in the log, or would the slot id be enough (assuming it's always correct ) ?

From my point of view, consistent guid > consistent slot id > guid > slot id > name

* status : should list all connected players with slot id. Having it provide lots of info could save lots of dumpuser queries

Since this is engine sided, it does not have access to certain information. Currently it includes slot id, name and ip for each player as well as the current map. I doubt score, ping, lastmsg, qport and rate are usefull. So what do add? GUIDs come into mind.

* dumpuser <player> : should dump as much info as possible. Should give guid, team, ip, etc. Often missing here is the muted status

This is also part of the engine. It simply prints the client's userinfo. If userinfo does not contain a certain information, the engine won't know about it (see note about /rcon status). This could be moved/copied to gamecode to print further information which only gamecode knows about. Muted status is such a thing, if the game/mod has support for it at all.

I have no clue what feature comes from what part of the game (engine/game code). That where you point of view is very valuable to us. Pings/lastmsg is useful info, it is used for ping kicker feature of b3 (which only kick player with repeated high pings over many minutes to avoid kicking ppl who happened to have a bad ping for just a short time). Score is used by status plugin which in turn provide parsable info meant to be integrated in teams/communities websites.

* tell <player> <msg> : It allows the bot to talk in private message to players avoiding chat zone spamming and allowing sensitive info transmition

This can be done either in engine or gamecode, while the first method should work with all mods (maybe tell ioquake team about this). If you want those messages to actually be messages, like the usual chat text by other players, it might become a litte hacky (and game/mod specific), since there is no client behind the message. If the messages should just be printed at the client, everything's fine (but they would not be handled as chat messages clientside). I prefer just printing them

For Urban Terror, there are two chat zones : up-left and bottom-left. Up-left is used for server messages. bottom-left for user chat (broadcast/team/tell) (with the hotpe that this bit of info if of any use to you)

On a sidenote, would it be usefull if the gamecode hides messages starting with a certain prefix ("!" as default in b3, configurable via cvar in game) so other players don't see these commands (less spam) and one could use plaintext login functions, like "!login mypassword", which would otherwise be visible to all playery? I think this does not interfere normal chat, since real chatmessages messages seldomly start with "!"

that would indeed be useful. The actual trick to do such a thing in Urban Terror is to send a tell message to yourself. I know this would be used by many admins although IMHO I prefer seeing admins be honnest and transparent regarding the actions they take on servers. This firstly shows to the player crowed that the server is being watched after, it is also educative and teach less experienced admins how to use the many commands provided by B3. Maybe if such a feature is one day part of ioQ3, it would be wise to be able to distinguish such 'chat' from classical chat lines.

callvote spam preventing ! I want that for years

How could b3 prevent callvote spam? It could either disable votes alltoghether or kick the player. Anything else, like vote-muting the player would require support by a gamecode serverside mod.

B3 has a warning system. It will warn players for unwanted behavior with an educative message. This way players are taught the server rules. Once a given player is given too many warnings in a short period of time, he gets a tempban (duration depends on warnings gravity scores).  B3 could easily detect ppl abusing the vote system and give them warnings (then tempban). Vote muting could of course also be exploited, but that's luxury and probably too much trouble on the game code side to code/debug/test/stabilize to be worth the effort.

From what game community are you from ? and what game are you working on ?

I'm working on World of Padman. Since the code is similar across most ioquake games, I could also apply these modifications to Smokin' Guns, Open Arena and others (at least on my own server, since I'm not part of their official dev team). But as stated above, I'm rather certain their devs would be willing to incorporate the changes we talk about.

I know WoP thanks to B3 Xlr8or from these forums made a B3 parser for it I believe. I installed it again on my computer last week after reading news from the Gamescon and WoP future Xmas present

Which additional commands could b3 need? The kick command could also use a reason as additional argument and print this to (the kicked) client for example.

of course, that would be educative. Next version of Urban Terror will have such a feature (I had the chance to test it months ago). Maybe you could get in touch with Kalish who did code that part. Perhaps he can provide a patch that could be adapted to ioQ3 or WoP.

P.S.: I'm currently thinking about some sort of interface between gamecode and b3. Gamecode could maintain a separate userinfo for each client with additional information and do a logprint each time it changes. At the same time, it could provide a command to set specific key/value pairs inside that userinfo, like muted/votemuted or any mod-specific data. How does that sound?

That sounds very good indeed. We need to have a longer chat about futures efforts both teams could put in to make B3-WoP work better together (or better B3-ioQ3). Maybe you also prefer irc/email/wave over forums to discuss such things ?

[GedankenBlitz]

Quoted quotes are getting ridiculous

We have met such a bug in Urban Terror : http://bigbrotherbot.net/forums/urt/b3-bot-sometimes-mix-up-client-id's/

This looks like b3's problem, since the logline does not contain a slot id, but a name.

From my point of view, consistent guid > consistent slot id > guid > slot id > name

Slot ids on loglines should always be consistent, since the entire gamecode and engine relies on the clients being consistent. Since I already said, that GUIDs are not reliable in ioquake based games and one does not need them to identify players which are currently on the server either, I'll go with slot ids.

I have no clue what feature comes from what part of the game (engine/game code). That where you point of view is very valuable to us. Pings/lastmsg is useful info, it is used for ping kicker feature of b3 (which only kick player with repeated high pings over many minutes to avoid kicking ppl who happened to have a bad ping for just a short time). Score is used by status plugin which in turn provide parsable info meant to be integrated in teams/communities websites.

Aww, I forgot about those. Note to myself: Fix PERS_SCORE for all gametypes and check where new ioquake omits portnumbers.

For Urban Terror, there are two chat zones : up-left and bottom-left. Up-left is used for server messages. bottom-left for user chat (broadcast/team/tell) (with the hope that this bit of info if of any use to you)

I have never played UrT, but the concept of different types of message prints applies to other games as well

that would indeed be useful. [..] Maybe if such a feature is one day part of ioQ3, it would be wise to be able to distinguish such 'chat' from classical chat lines.

If we take the "!" prefix as the only characteristic for "external commands", I could change the loglines right now to differ from usual chat.

B3 has a warning system. It will warn players for unwanted behavior with an educative message. This way players are taught the server rules. Once a given player is given too many warnings in a short period of time, he gets a tempban (duration depends on warnings gravity scores).  B3 could easily detect ppl abusing the vote system and give them warnings (then tempban). Vote muting could of course also be exploited, but that's luxury and probably too much trouble on the game code side to code/debug/test/stabilize to be worth the effort.

Aww, didn't think about that either. Seems like I should get into B3 more in-depth. It shouldn't be too hard to implement some additional servercommands to mute, votemute, cancelvote, callvote (latter one in case votes are globally disabled but still can be invoked via rcon).

Next version of Urban Terror will have such a feature (I had the chance to test it months ago). Maybe you could get in touch with Kalish who did code that part. Perhaps he can provide a patch that could be adapted to ioQ3 or WoP

Thanks for the info. Does UrT's new kick work properly while people are still connecting? I stumbled upon some bugs/limitations within the ioquake engine as far as that goes.

We need to have a longer chat about futures efforts both teams could put in to make B3-WoP work better together (or better B3-ioQ3). Maybe you also prefer irc/email/wave over forums to discuss such things ?

I'd also prefer instant messaging, as long as we don't forget to post results here or in some doc/README Unfortunately I can not write PM's yet, seems like I need to spam more

[Courgette]

 0:00 ClientConnect: 0
  0:00 ClientUserinfo: 0 \ip\91.61.158.223:27960\name\-=GF=- Flashkilla\password\***\racered\0\raceblue\0\rate\8000\ut_timenudge\0\cg_rgb\128 128 128\cg_predictitems\0\cg_physics\1\gear\GMAARWU\cl_anonymous\0\sex\male\handicap\100\color2\5\color1\4\team_headmodel\*james\team_model\james\headmodel\sarge\model\sarge\snaps\20\teamtask\0\cl_guid\7BC6C22A44F0D933BDE0F1D5932ED351\weapmodes\00000110220000020002
  0:00 ClientUserinfoChanged: 0 n\-=GF=-Flashkilla\t\1\r\0\tl\0\f0\\f1\\f2\\a0\0\a1\0\a2\255
[...]
  0:00 ClientConnect: 13
  0:00 ClientUserinfo: 13 \ip\78.52.193.200:27960\name\-=GF=-KaroTTe\password\***\racered\3\raceblue\1\rate\25000\ut_timenudge\0\cg_rgb\0 0 0\funred\pbeard,mohwkbk,patch\funblue\ninja,shades,ponybl\cg_predictitems\0\cg_physics\1\gear\GeAARWV\cl_anonymous\0\sex\male\handicap\100\color2\5\color1\4\team_headmodel\*james\team_model\james\headmodel\sarge\model\sarge\snaps\20\teamtask\0\cl_guid\FA7017F262E89EF464EF9C301164695F\weapmodes\00000110220000020002
  0:00 ClientUserinfoChanged: 13 n\-=GF=-KaroTTe\t\1\r\3\tl\0\f0\pbeard\f1\mohwkbk\f2\patch\a0\0\a1\255\a2\168
[...]
  0:14 ClientBegin: 0
[...]
  0:18 say: 0 -=GF=-KaroTTe: !xlrstats
  0:18 ClientBegin: 13
[...]
  0:58 Kill: 0 5 15: -=GF=-Flashkilla killed JohnnyCrash by UT_MOD_DEAGLE
[...]
  1:07 Kill: 13 9 12: -=GF=-KaroTTe killed chrish by UT_MOD_KNIFE

as you can see here, -=GF=-KaroTTe is given the slot id '0' on the say line where he says !xlrstats while his real slot id is 12 at that time.
This has been proved to be on the Urt/q3 server side. It happens quite frequently and mostly when people chat just before map/round change. They are usually mistakenly given the slot id 0 (but I've also found cases where wrong slot id is not 0)

Does UrT's new kick work properly while people are still connecting? I stumbled upon some bugs/limitations within the ioquake engine as far as that goes.

I have no idea, but I've never met this issue on UrT over the years.

You might be interested in http://www.bigbrotherbot.net/forums/general-discussion/urban-terror-bug-list-and-wish-list/

[xlr8or]

Good thing going on here. Can we change this valuable info into a paper in our wiki? This could become an interesting log-convention for gamedevelopers that make use of game logging.

[Courgette]

Hi, any update ?

[GedankenBlitz]

I started working on the improved log, but got sidetracked by real life.

I'll do a doc/readme on this lateron, but current changes involve this

Item: $cid $classname
DropItem: $cid $classname
Award: $cid $awardname
AddScore: $cid $score $reason
Kill: $cid_attacker $modname $cid_target
CvarChange: $cvarname $newvalue
Teamscores: red $redscore  blue $bluescore
Score: $cid $score
Callvote: $cid $vote
Vote: failed timeout
Vote: passed
Vote: failed
AddTeamScore: $teamname $score $reason
Say: $cid $text
SayTeam: $cid $text
Tell: $cid_from $cid_to $text

Newly added commands are "ssay $text", "stell $cid $text", "scp $cid $text", "smp $cid $text" and "sprint $cid $text".

I could provide a real log aswell, just need to remove any spoilers beforehand

I don't know whether it's of any use to B3, but statusResponse now includes team and isbot for each player. infoResponse includes g_needpass and g_humanplayers cvars.

[Courgette]

nice. The more info the better.
Don't forget to have player related event logged as well (player connect, player enter game, player disconnect, player change name, etc)

If you want XLRstats to be fully working as well, hits / hits locations (head, torso, legs, etc) / hits dammage / weapon are also welcome

[GedankenBlitz]

Most of the events mentioned in my first post can be derived from the ClientUserinfoChanged logline, which is still there (same for ClientConnect, ClientBegin etc. I just didn't mention them because they did not change).

World of Padman does not have any locational damage.
Logging every damage being made is quite expensive, so I'll need to introduce a new cvar to toggle it, which defaults to off.
Does XLRStats only count hits, ignoring how often a weapon is actually being shot? Does it account for powerups like quaddamage, mods like instagib?

[Courgette]

I don't know well XLRstats, xlr8or or Freelander could provide you with more details

[Freelander]

Does XLRStats only count hits, ignoring how often a weapon is actually being shot?

Yes it only counts hits. Here is an xlrstats page for wop. Looks like only missing thing is hitlocations..

Does it account for powerups like quaddamage, mods like instagib?

Sorry I'm not familiar with wop and not sure I understand your question. xlr8or is running a wop server, he can answer this I guess.

[Courgette]

isn't quaddamage an item you pickup which raises the damage inflicted by weapons ? Effect being limited in time

I though instagib was a game mod. Is it a kind of weapon ?

[GedankenBlitz]

Yes it only counts hits. [..] Looks like only missing thing is hitlocations.

How can xlrstats claim to calculate skill, if it does not consider shots that missed?

World of Padman (like Quake3 and OpenArena) does not have hitlocations, there is only one big bounding box around each player. So you can either hit or miss, there are no specific body parts to hit.


Quaddamage multiplies your damage and protects from some damage at the same time. Instagib is usually a mod, where you spawn with the sniper weapon and each shot kills instantly.
Both (and other powerups) should be considered when xlrstats calculates "skill" due to damage/kills/ratio/whatever.

In general, xlrstats should not use kills for its calculations. Almost each gametype has a different scoring system, where kills usualy do not matter at all.

P.S.: Seems like the SNT Twente WoP server is offline?