Case

Enough that it would've been obvious if it was a problem. Just try it in a single mission and see how it works. What is there to lose? Also add in some randomization of the ground unit and their behaviour to make sure you are not shooting the same fish in the same barrel each and every time.

That's not true with the recent DCS versions. All of the missions on the 51st server have moving units and we see no or few crashes because of them. In fact in my Mountain Divide mission there is a task which has over two dozen units moving and firing at each other.

Many thanks for those flying on our server to test out the stats. With the data that was generated I was able to trace down a few bugs in my stats code that have now been fixed. I will reset the stats board on March 1st, so upto that time people can still mess around a bit, but after that the stats will last for a life time :D

Here's an old tutorial that should still apply.

Thanks Grimes! Awaiting your findings.

My choice would also be S-25 or FAB-500. Success is determined by how close you can get your weapon to the target, but if you can these are better than S-13.

Mission events like take-offs, landings, ejects, etc are logged in three separate ways; 1. server side in the on_landing function in scripts/net/events.lua, 2. client side using the scripting engine S_EVENT event handlers, 3. in the debriefing log at the end of a flight. It appears that the landing events for the Su-27 are not logged consistently for some airbases after a player has taken off. The attached track and debriefing log show that for both ground and air started MiG-29S and Su-33's the take-off and landing events are logged correctly. However, for the Su-27 the landing event is not logged when a human player takes off first. Instead, if the human player air starts, the landing event is logged correctly. From my tests so far I find that this bug affects the Krymsk and Mineralny Vody airbases, and possibly more, and only when flying the Su-27. landing_tests.trk test.zip

Thanks Cali, Falcon, Gaanalma, Flanky! Glad to see you guys are still around!

At the moment the setup is very much tailored to the 51st server, but if you have knowledge of C, php and mysql, it can be adapted.

The 51st PVO Regiment is proud to present statistics for our DCS World server http://www.51st.org/stats/ After the FC1.12 stats page and the FC2/BS stats page, this is the third installment of the 51st stats page, now for DCS World. Points are awarded to pilots based on the events present in the multiplayer log. All events are attributed to flights, which start with a pilot entering the server and end when he or she exits. During a flight, a pilot can score points from air-to-air and air-to-ground points and double these points by safely returning to a friendly airbase. Bonus points are awarded for air-to-air kills on pilots of the 51st PVO Regiment (those wearing <51> tags) and for ejecting before crashing. Kills on friendly units will be penalized. A detailed account of the scoring system is given at http://www.51st.org/stats/rules.html. The stats pages are separated in an air-to-air page, an air-to-ground page, a page showing the overall pilot statistics, stats for each mission and a page grouping stats of pilots belonging to squadrons. The logs are parsed and uploaded to the stats page at the end of each mission. For questions, comments or suggestions about the stats page, use this thread or the Server Support Desk of our forums.

Thanks for the reply. Indeed I am asking from a stats perspective. I tried Xcom's event handler setup, but I find that most of the time the hit event handlers is not accurate as to which weapon was used. the debrief.log does have this information. This may be because the script is run on the client side on the server, and it may be more accurate when it is getting data on the server side, but I do not know if the event handlers exist on the server side.

It appears that in DCSW the debrief.log is only written at the end of the mission, when it is saved to Saved Games/DCS/Logs. In FC2 the debrief.log was written while events occured. Is there a setting in DCSW that controls this behaviour?

This turned out to be the problem. Thanks for the instructions.

On my system I have trouble getting Aries 1.970 Beta to work on W7 64bit. The first problem was that the installer (setup.exe as admin) required msvcr100.dll. Placing this file in the in directory that had setup.exe fixed this. The second problem was that the DCS configurator would not run until I put msvcr100.dll in windows/system32 (though the OS is 64bit). With these issues fixed the problem is with TS3, where it says the Aries plugin cannot be loaded. Any help to fix this last issue would be greatly appreciated.

Though I haven't flown since the release of FC3 I'd like to share some observations from the FC1.12 and FC2/BS eras. The majority of players is looking for some quick action and easy kills. They'll pick their favourate aircraft regardless of how lopsided this makes the coalitions at that time. Players will leave a server if they can't fly their aircraft. Hence, to make a popular server where the sides have balanced numbers of players the best way is to place the same aircraft on both coalitions. During FC1.12 and FC2/BS we had to work really hard to make the 51st server popular with assymetric missions. By integrating the stats page with the missions (I think) we were able to get players to accept some of these assymetric missions, and some of them, like Exorcet, seemed to like them.

Mission building is a lot of hard work, hard work which doesn't get appreciated by the typical pilot flying them. Kudos to anyone building complex missions!

But a coincidence none the less. Some videos show the meteor towards the rising sun, which means it moved approximately North to South, which is different from the orbit of 2012DA14. Still, it is amazing that this is caught on video. Not just the entry but also the sonic boom! If you want a reasoned analysis, check out the Bad Astronomer.

Hi Speed, Great to see that you are working on this! Back in FC1.12 and FC2 this is the approach I used for the 51st stats page. The obvious reason was that I had no (easy) access to the in game tables. Instead I used the mplog for FC1.12 and the debrief.log/mission file in FC2 which both had a time ordered list of events. The steps I used to go from this list of events to an online stats page were the following: a logger program ran on the game server. This checked the mplog/debrief.log every second and added UTC timestamps in front of each new line and copied them into a new file the game server had an FTP server running which allowed outside access to the timestamped files my linux machine pulled over new files from the FTP server and it ran a parser program over them. This program did two things; it parsed the logs to connect events to players (just like your table does) and it returned MySQL queries the MySQL queries were uploaded to a MySQL database a webserver accessed the MySQL database to form the stats page The main advantage to this is that the game server only runs the logger program and the FTP server, which don't require many CPU cycles. The linux machine then does most of the hard work, but only once every 5 minutes to process the events from those last 5 minutes. When I did the global stats page, where the stats from the 51st, 4c, 3Sqn and 104th were all uploaded to the same page, all that needed to change was on my linux machine, pulling logs from 4 servers instead of one. I'd use this approach for DCSW again, mainly to minimize the load on the game server. Your in game stats would work as well, but it depends what you want to do with the results. I know that Mugatu from 3Sqn uploaded the events to a database directly from LUA, so that is still possible. The only downside to that is that stats can not be reparsed and may get lost on server crashes.

As a reference, look at our historic log of the FC1.12 stats at http://www.51st.org/fc1stats/. The FC2 stats are down at the moment, but they are generally similar. The FC1.12 stats got all their information from the mp_log, which only really stored a limited number of events (enter, exit, land, crash, kill, eject) that were linked to a player. I wrote software to parse that log and link events to players to compute flight time statistics and keep track of kills, deaths etc. These numbers were then uploaded to an SQL database from where they could be accessed through a browser. For FC2 it was broadly similar but a lot harder. I used the information from the debrief.log but had to reference it against the mission file to extract aircraft, airbase and other information. If you can get Slmod to dump game events into a file then it is quite easy for me to adapt the parser with little or no changes to the SQL database or the php scripts running on the webserver. Ideally the events should be logged with a UTC timestamp, an ingame timestamp, player name, player coalition, player aircraft, and then assorted information about the event (land at airbase, fire certain missile, get hit by certain missile, etc).

Excellent idea! I've not had much time to play with DCSW, but does such a feature already exist in the ME?

No, it wasn't necessary and it wasn't helpful. This is me being grumpy in the morning, and I apologize. Nothing. This is not what I am inferring. I do not think this is wrong. This is where I think the crux of the problem lies. Our community is small and as the original poster mentioned in the opening thread, new players are put off by seeing lots of empty but passworded servers in the master server list. These new players may have all sorts of interests, and it will take them some time to figure out what it is they want from the multiplayer environment. That process of figuring out largely depends on the interaction with other players, players of whom some will belong to squadrons that do things their way. I think the great benefit of open servers, be it A-10C only, Black Shark only, FC3 only or mixes of the different DCS titles, is that new players can try them out and figure out what they want. How else are they going to figure out that they want to do things the way your squad does? I think closing servers to keep new players out is wrong for the reasons I outlined in this post and the post before. Educate new players instead. I think closing servers to force people on comms is dubious; I'd prefer to ask them to join comms when they join the server and if they don't join comms, ask them to leave (or kick them). I think closing servers to fly with your friends is fine, but please, take it offline or open them up once you and your friends are done playing. Why keep an empty server passworded?

You're more than welcome. Yep; http://www.tsviewer.com/index.php?page=ts_viewer&ID=61407

I've flown DCS:BS in an FC2 environment on countless occasions and, at least on the 51st server, this has never been a problem. Your argument about being airborne in 2 minutes and not caring about getting shot down are wrong. First off, you should design smart missions; obviously you're going to get shot down if you put the ground targets for Ka-50's and A-10's below the air-to-air arena. In most of the missions we run on the 51st, the target areas for strikers are offset from the main air-to-air battle. Second, we put the airbases where fighters spawn from a long way away from the battle. They may be back airborne in two minutes, but it'll take them 10 minutes to get back into the fight. Equally, we try to use forward airbases where both fighters and strikers can rearm and refuel (but not spawn), to encourage them to value their life. Thirdly, the missions are designed to promote teamwork, both between fighters and strikers. Finally, and this has been crucial for the success of the 51st server, we run a stats page where all actions, both air-to-air and air-to-ground are logged. As such, repeat offenders, either teamkillers, or base bombers, will stand out and can be dealt with if ServMan hadn't already. Furthermore, we find that the stats page works as an incentive for new players to improve their flying skills. Besides counting kills and deaths, we use a point based system where players are rewarded for good behaviour and punished for bad behaviour. If you manage to return to your airbase your points will be doubled (to get people to value their life). Kills on fighters are awarded more points than on strikers (to get fighters to focus on fighting fighters). (see 51st stats rules). Honestly, all your points are moot if you care to think about mission design and educating the people that fly on your server. If you do both there is absolutely no need to password servers to 'keep the noobs out'.

Go back under the rock you crawled from please. The 51st (Frostie, myself and others) and 104th (Crunch and others) have ran open FC2/BS1 servers since these games were published. We've never seen the need to password them because someone doesn't stick to our rules. Sure, people teamkill (be it accidental or on purpose), but in an open server there are always people that are willing to help the noobs, or report repeat offenders to the server admins. This is how a community works. Passwording servers to keep them out doesn't help; education does. It is funny that you may feel your precious DCS server is getting invaded by arcadish FC3 pilots. In fact it is the opposite; most Flaming Cliffs servers have been around before there even was DCS, and now with FC3 we are going to welcome you into ours with open arms!

Wow, this is excellent stuff!