mp_log for BlackShark?

[Moa]

Hi All,

I'm finishing up a pilot statistics program for LockOn and am looking at extending the work toward BlackShark (which will hopefully be the same as the format used by LockOn:Flaming Cliffs 2.0). I have some questions that I couldn't find answers to when I searched the forums (perhaps I'm just not good at searching :)).

 

Anyway, if anyone knows the answers to any of these I would be greatful for whatever insights you could give:

 

1) BlackShark appears to have no equivalent of the mp_log when run in game server mode. Is there a file in BlackShark that is the equivalent of the mp_log?

 

2) If there is no equivalent of the mp_log I thought I could comb the TacView server-side to find player statistics (I have written TacView parsing code already for a moving map I have). In LockOn, TacView is less reliable than the mp_log for many events - perhaps the data isn't, but the displayed information certainly shows odd things. Is the TacView also somewhat unreliable in BlackShark, or is it better than in LockOn?

 

3) I could also read data from the server in realtime using a socket in Lua (and I'd create a [Java] client that recorded player information). This is essentially the same as using TacView data (sans TacView bugs) but I could then stream to a database that wasn't on the game server (thereby not loading the game server too much). Has anyone tried this to get information for BlackShark units other than the players through Lua (I know =RvE=Yoda is an expert in getting such data for players, is it possible for all in-game units too?).

 

4) Is there some other way I haven't thought of?

 

Meanwhile, ED deserves credit for adding callsigns into the network log file on the same line as IP addresses (the BlackShark equivalent of LockOn's AsyncNet.log). However there are two minor things that could be done to perfect this file (making the job of pilot stats program writers like me a lot easier). They are:

 

a) Put in a line in the file giving the server time (either in UTC or specifying a timezone as well) and the host's clock timestamp at some point when the game is running (eg. when it is first unpaused). That way the conversion between game time and server time is known and we don't have to compare a several of log to get the server time/game time conversion and don't also have to guess at what server time the game was unpaused,

 

and

 

b) the name of the network log file has a date on it. This complicates looking for the file since you have to scan the directory and look for the latest file that is changing. A minor complication resulting from not using the same name for the file, but has the huge benefit that the file does not need to be renamed before the next server run overwrites it. So, I'll conceded that it might be better left as it is.

 

Like I said, I'm grateful for any help anyone can give on this no matter how small.

 

Thanks,

Moa

[Grimes]

Its not exactly in the same format of LO... its MUCH MUCH more detailed...

 

do a search for debrief.txt

[Moa]

Thanks Grimes. I did look at that file but it didn't seem to update in real-time. Will take a second look.

[Acedy]

If you want to extract player information from the server at runtime, take a look at the files in Scripts/net, especially server.lua and events.lua. They contain callbacks that you can use to send data over a socket or to create a stats file. By default server.lua writes some information to the Temp/net-server.log file. There are also some additional functions that you can access in these scripts to query other information, including the Lua state of the Config/Export/export.lua file (i.e. it is possible to get the same information that TacView uses) and the current mission file. I don't know though how much runtime information about AI units you can extract, you have to experiment with the net.dostring_in(state_name, string) function. See the Scripts/net/readme.txt file for more information and the ServMan mod (link in my sig) for examples.

 

I don't know where the debrief.txt file is created, but if it is a Lua script you can force it to flush text to the file as soon as it has been written. That way you should (in principle) be able to parse it at runtime. I am not sure how Windows handles concurrent r/w file accesses from different processes, but I guess that you can open the file only once in write mode and as often as you want in read-only mode. Alternatively you could change the script to send the data over a socket.

Edited February 13, 2010 by Acedy

[Krippz]

If you want to extract player information from the server at runtime, take a look at the files in Scripts/net, especially server.lua and events.lua. They contain callbacks that you can use to send data over a socket or to create a stats file. By default server.lua writes some information to the Temp/net-server.log file. There are also some additional functions that you can access in these scripts to query other information, including the Lua state of the Config/Export/export.lua file (i.e. it is possible to get the same information that TacView uses) and the current mission file. I don't know though how much runtime information about AI units you can extract, you have to experiment with the net.dostring_in(state_name, string) function. See the Scripts/net/readme.txt file for more information and the ServMan mod (link in my sig) for examples.

 

I don't know where the debrief.txt file is created, but if it is a Lua script you can force it to flush text to the file as soon as it has been written. That way you should (in principle) be able to parse it at runtime. I am not sure how Windows handles concurrent r/w file accesses from different processes, but I guess that you can open the file only once in write mode and as often as you want in read-only mode. Alternatively you could change the script to send the data over a socket.

 

Can we have a patch that allows your singleplayer logbook to carry over to multiplayer a la Falcon 4.0 Allied force?? Puuuurrrrty please ;):D

[104th_Crunch]

Evontroy, don't derail the thread. You post is OT and Moa is working hard :)

[Moa]

Thanks Acedy & Crunch, I now have some free time to delve into those scripts.