[[dswp]zietsh]

Well, title says it all:

We (dswp community) would love to see that the medic action (especially when people medic others) would be logged. In combination with the b3 where we could then parse that action it would be (a) quite informative/expressive value/data.

Just want to throw that out there, maybe we are not the only one seeking the possibility to log that.

[DSZ]

I cant imagine how server logs could be flooded by every single medic action, every single hp recover (even b3 would go crazy if somebody got low amount of lines parsed per second in b3 configuration) even if could be able to lower spam of it then info/data wouldnt be accurate or with some delays.

Im just curious but for what exactly somebody would need it? We talk about not modded servers ofc, for any statistics?
You talking as a representative of some community, come on, give more examples :D

[[KzH]mathieu]

Just speaking in my opinion i'm not from dswp community but i'd love to see that thing added
If we could somehow add it into b3, for stats or whatever people might consider being more supportive to their team.
Modded server could add it, but i don't think dswp want to mod their server, or only be the only one that can benefit something kinda useful

[Mod Iye]

i dont see my self doing more medic actions because of a statistic system, but k. medkit is item 2 in most my equipment jfyi xD
the idea is quite interesting. maybe just log a heal if its >25HP. so meding a lemming wouldnt flood the log.

i kinda suspect this is related to the ranking system i saw on dswp bomb recently. xD

[[KzH]mathieu]

Iye, on 30 May 2015 - 12:43 AM, said:

i dont see my self doing more medic actions because of a statistic system, but k. medkit is item 2 in most my equipment jfyi xD
the idea is quite interesting. maybe just log a heal if its >25HP. so meding a lemming wouldnt flood the log.

i kinda suspect this is related to the ranking system i saw on dswp bomb recently. xD

just an hypothesis, iirc in 4.1 when C9 was the only freezemode, they added a thaw counter in !xlrstats so it helps out weaker player to have good stats by team play.

[[dswp]zietsh]

Every single hit is logged. I don't think there will be more medic actions than hits. Considering that we had logs before exceeding 1.5GB (troubles occur once the logs would exceed 2GB), I don't see a problem in logging medic actions.

Once it is logged by the server it would not be too hard to configure the b3 parser to be able to log it into xlr_playerstats or some other new table.

And yes the reason is that we would like to use it for statistical purposes. And it has nothing to do with our ranking system, but we would certainly incorporated it in that.
The "real" reason:
For some time now we have been using a script (b3) to determine "friendly/good/considerate/alert" players. Since that "theory/idea" surfaced in 4.1 we have been wanting to incorporate the medic action, for I guess obvious reasons.

Edit: And it is something that sets us (UrT) apart from other games. If we can represent this when we create statistics it would be very useful in terms of marketing/attractiveness of the game.

This post has been edited by zietsh: 30 May 2015 - 01:46 PM

[Mod Iye]

oh noes! dswp is collecting big data on us. and then analyzing us....

but to be honest, i kinda like the idea. i mean this probably wont have such a big impact on regular gameplay in 4.X, but i can see some really nice achievements in HD. "Heal 1kk HP...." "heal a player that has <10 HP, after killing his attacker".. xDDD

[Lorien]

When I wrote a control/stats client for a different game engine, one of the nice things about the situation was the fact that my client could connect to the server via a UDP socket, and then declare interest in certain events.

As such, the client would only get events that it was interested in, and hence only caused a very minimal impact on the game server itself i.e. the presence of the client caused no additional disk i/o on the server, and the client could obviously be run anywhere with no remote file access of the server.log required (as all event notification was via UDP).

Just idle musing here, but if UrT had the same stye of functionality, then many "new" events (such as medding discussed here for example) could be made available to any stats gathering client with minimal impact on the game server itself ...

It would make for a very flexible solution.

[[dswp]zietsh]

My understanding is it work in this way: The server writes a log which is accessed by b3 (our "stats gathering client") in a predetermined interval (200 lines a second as an example). In this log everything is written that happens in the console similar to when you open your console, just that its the server console.
So the load on the server would not increase with more stats gathering clients. The added load would be made by the, lets say 10 more events in 30 seconds than usual(?). I really don't think that would make a big difference. I mean how often are people really medicing others? The limiting 2GB would be reached sooner, yes. But would it really make a difference?
If the server would only react to UDP request of the stats gathering client it would be a higher load on the server. Because like this the stats gathering client checks if something new happened in the log and if not, nothing happens. If the client would ask the server every second for 200 lines of info that would be a lot higher load on the server than the server just writing its log any time something happens I assume.


theory theory theory, this is just guessing how it works. I have no clue.

This post has been edited by zietsh: 31 May 2015 - 03:23 PM

[Lorien]

What I was on about is turning around how b3 works (i.e. parsing the log file for events) and doing it the other way, namely:

Stats Client sends to server "hello - I am here and I want medding events please"

Server now sends via UDP all medding events (i.e. no polling - events are sent by the server as and when they occur)

Aside from the odd keepalive message, that's it. Simple and not very load intensive.

This post has been edited by Lorien: 31 May 2015 - 06:23 PM