Case

Inconsistencies in the replaying of a track is not a problem for a stats page. Moa mentioned Tacview having some problems but this may be due to the fact that it has to guess some events. As Yoda mentioned, these problems may be solved by a dedicated script interpreting the exported events instead of the events recorded in Tacview. I think, however, that for now this is beyond my scope for the stats project.

There is the A2A kill ratio on the A2A (the index) page, but I can (and should) add the same for the A2G page. There is an inherent problem about what to do with A2A kills in bombers and A2G kills in fighters. Right now the A2A kills and losses in bombers are counted on the A2A page, whereas all the A2G stuff if counted on the A2G page. An option would be to really separate the A2A and A2G to have an A2A and A2G page for fighters, and an A2A and A2G page for bombers. Do you have any suggestions on this? Right now it is updated when the 104th and 3Sqn server admins send me the latest files. I get those every few days and then download the 4c and 51st logs as well. The 104th has not decided if they will join the experiment.

Introduced a new page showing stats of squadrons: http://www.51st.org/common/squadron.php

This is outrageous! It must stop! :music_whistling:

So from what I explained earlier on how my stats system is setup, how would you introduce SOAP here? The PHP way of reading the MySQL database seems to work perfectly, and give me all what I need to present the data. On the other hand is the transfer of the mp_logs to the server that parses them could be improved. Perhaps SOAP has some uses here.

I'd say yes to both but if you can get a lock with a K-Mav on anything at stand-off range, use them. Also, check out the CCRP training video's. You might be able to lock on to SHORAD when flying below overcast, and then climb to 15000ft to CCRP a Mk-20 on top of it.

Happy Birthday Comrade Tito!

Yes, but I am only using PHP to make the web pages which access a MySQL database. Before that there is a dedicated parser program that reads the mp_logs and generates the queries that are uploaded to the database. In that sense there are three servers involved. The first is the game server and the third is the web server. In between is a separate server that does the hard work of running the parser program. By setting it up this way all the hard work is done neither on the game server nor on the web server. This means the game server is not losing clock cycles that it could've used for running the game. On the other hand the web server is doing nothing more than execute MySQL queries to sum, group, count and order the data and use PHP to display it, which makes the web pages load extremely fast. The server running the parser program is doing the hard work of pulling the latest mp_logs from the game server, parsing the mp_log into optimized MySQL queries and uploading it to the database. So if I am not mistaken I am using a third layer between the game server and client which is not present with SOAP webservices.

Moa, can you explain what is needed for SOAP to transfer data from the game server to somewhere else?

Well for FC2.0, if we are going to replace HL with a web based chat option, forum and stats, we could have each server that wants to participate run a small LUA scripts that uploads the current players to this website. In this case it would not matter if you join through IP or otherwise.

If anyone is interested in playing with the MySQL database and php scripts, send me a PM and I will send you a dump of the MySQL database and the php scripts.

This would certainly be the way to go if the experiment succeeds. Right now I am hosting it on the 51st web server because that is where I have access :)

Yes, I have seen some strange things happen in the logs, but luckily these are very rare in regular gameplay.

Java and/or flash chat should be easy to set up, though I am not sure if the lockon executable can be started and told the IP and ports.

All the data on this stats page originates from the mp_log.txt file. This file contains events that happened in the server, enters, air-to-air and air-to-ground kills, exits, crashes, ejections and landings. It is extremely unfortunate that it does not record take offs. The 51st stats engine is the first that tries to correlate events into what I call a flight. A flight starts with a player entering the server, and should end with him exiting the server. In between the enter and exit the player can have multiple kills and landings, but can only get killed once, only have one crash and/or one eject. Hence, each flight ends with an end event, which is the last event before the player exited. He could've landed, crashed, ejected before crashing (crashed/ejected), got killed, got killed and ejected (killed/ejected), got teamkilled or got teamkilled and ejected (teamkilled/ejected). Finally there is the option of the player being still in the mission when the mission ended, in which case the end event will be mission end. Unfortunately for all sorts of reasons the log may not contain the exit message. This can be due to the players machine crashing, the connection between player and server dying, or the server crashing. Because the game does not record take offs, I have no idea of knowing if the player is still in the air or not. All I have is the last event before the mission ends or have a new enter message when the player re-enters. If that last event is an air-to-air or air-to-ground kill, then I know the player was still in the air, because any other event would've meant he ejected, crashed or got killed. Hence the stats page will show a game crash only when the last event of the flight is not an exit but an air-to-air or air-to-ground kill. I hope this clarifies things.

Now that Flaming Cliffs 2.0 is on the horizon, I decided to start an experiment to see if it is possible to have several multiplayer game servers join forces and upload their logs to a common stats page. To make the experiment successful, all game server admins that join the project must agree on how scores are computed, how events are awarded and how, in general, the stats page is maintained. If all participating admins can reach agreement on this, it should pave the way to implement a common stats page for FC2.0. Furthermore, it will allow more people working on and improving the stats page. To this end I have invited 4c, 3Sqn and the 104th to participate with the 51st in this experiment, and use the 51st stats software as a starting point for the common stats page. All of these squadrons have generously provided me with some of their multiplayer logs, and I have adapted the 51st stats engine and webpages to work multiplayer data from multiple servers. The webpages are now able to display data from single servers, as well as all servers combined. For the moment, the common stats page is located at: http://www.51st.org/common/ At present it shows statistics on three separate pages, air-to-air, air-to-ground, and overall (air-to-air and air-to-ground combined). A point based scoring scheme is used, and the scoring system of the 51st is used: http://www.51st.org/stats/rules.html (Note that the bonus points for kills on 51st pilots have been removed). This thread is meant to provide comments and suggestions on how to improve the common stats page and make it into a success. I would like to stress that as the common stats page is an experiment, it will exist next to the already present stats pages.

Congratulations!

Congratulations Tek! Have a good one! :holiday: :drink: :beer: :cheer3nc: :yay: :clap:

As always you have produced some sublime screenshots that captured the essence of the event! Very well done Viper, outstanding! :thumbup:

But do they join perfectly? Would it suffice to shift them next to each other? Cause if that is so, then a little program could be written to do this. All you'd have to do is the bookkeeping to keep track of which image going where.

Probably, but for the sake of a simple simulation things can be assumed here. In retrospect, the same is true for drag, even more so in the boost phase.

Interesting notion. There might be some truth here, but I'm also curious about the consequences of the missile just having been launched. It will be very much faster compared to its target, which may mean that proportional navigation will put the target directly on the velocity vector of the missile and that it may not need to manoeuvre much at all. Anyway, it would be interesting to do some simple simulations here, but I guess simulating the missile drag will be the tricky factor.

With LRM it is possible to restrict weapons usage. On the 51st Dedicated server on Hyperlobby we use it to restrict the weapons in one of the 5 missions in rotation to R-27R, R-27T, R-73, R-60, AIM-7 and AIM-9 only (so no R-27ER, R-27ET, R-27EM, R-77 or AIM-120). There is a hardcore group in the FC multiplayer community that really likes this mission.

All radar missiles go for chaff like crazy. Supposedly this chaff effectiveness will be reduced in FC2.0: http://forums.eagle.ru/showthread.php?t=47144 I even have heard people say that chaff will not work if you have positive line-of-sight velocity (heading towards the missile), but I can't recall if this was an ED fact or just hearsay.

Made my day AS, thanks! Man, if threads like these turn into that F-15C vs Su-27 thread then were are we going to...?