Moa

Well, I use 'ace points' to represent that for a2a. Killing anything flying with an attack aircraft is an ace point. Using a heater is an ace point. Using a cannon or R-60 gets you two ace points. Being in a fighter and getting killed by an attack aircraft gets you the comment "Owned". Self-kills get a "Duh!" remark. Teamkills are commented on and marked in red. The point is to reward excellence, highlight stupidity, and to liven up what would otherwise be an endless series of indistinguishable kills. Would be cool if the Common Stats did something similar. ps. All your castles are in our possession. I suppose that pretty close to the notorious "your all your base are belong to us" - including the language marmalization. Is 3 Sqn considering branching into "Zero Wing" :)?

I found it worthwhile thinking in terms of air-to-air and air-to-surface (which is A2G and naval) for fighters/multirole and attack aircraft (the USAF does not call aircraft 'bombers' unless they're Big Iron like B-1, B-2, B-52).

Very very cool

SOAP is so other people can read your stats without necessarily having to use the 51st web interface. Also, you could read other people's stats and use for your own purposes without having to screen-scape their web page interface. It's all about sharing the data and allowing squadrons to use data in the common pool for their own ends (removing the barriers that result in silo-ing of data). Yes, if you don't want processed data and only want SOAP for data transfer then you could use a SOAP interface that gives any events that occured within a time interval. Saves you from ftping the entire mp_log each time you want to do an update (which I'd imagine prevents updates from being in near real-time). Typically a client might request the mp_log and AsyncNet log entries more recent than 10 seconds ago (which will keep stats up to date in near real-time). Or you could go and get historical data from times when the 51st server was used for other purposes (eg. Crimean Incident) while other squadron's servers were busy generating events. FYI: PHP & SOAP http://php.net/manual/en/book.soap.php http://developer.apple.com/internet/webservices/soapphp.html (for the Mac)

Try and use the terrain. This is where the agility of the A-10 shines, Before I fire I decide how I'm gonna get out of there and where I can hide, well before launch range for either of us. Usually they get first launch so I fire and then turn into the cover I pre-selected (usually only a 90 turn, which is much faster to do than a 180 turn). Often there will be a gully you can go into. You can still be well above the gully floor while the sides of the gully block line-of-sight form the launcher. I usually fly at the gully ridgeline height to drag the missile a bit and then drop 20 feet lower (again, can still be well above the valley floor) when the missile gets close (this helps the Maverick get through). On flat terrain I fly low, climb to engage and then drop low again. Except on the flattest terrain they usually launch at long range and when you pull a 90 turn and drop down very low you'll be below the radar horizon. I don't like turning 180 degrees as I lose visual on the incoming missile, which can be fatal, so it is why I try limiting my turns so that I can still see the launcher and inbound missile. In an A-10 terrain is your friend. For real life A-10 folk it seems 100 feet is cruise altitude in bandit country, above 200 is stratospheric. You need to get comfortable doing a fast dive and pulling out at 20 feet. If you can't do this without looking at your instruments then you still need practice. Once you can fly visually at 50-100 feet over all terrain without ever crashing while still looking for bandits and keeping a constant eye on the RWR you'll be in good shape. I never use Maverick K anymore. Maverick Ds are for killing IR missile launchers and AAA. Anything else can be beaten by terrain masking, flying below the radar floor, Mk-20s and gun. Taking less Mk-20s will help you. If you are carrying too many your maneuverability will suck and you might as well be flying the brick-like Frogfoot (which is effective if you use different 'slash' tactics instead).

Doesn't matter how many layers you have (known as 'N-tier architecture'). Since it sounds like your web layer does some work (summation etc) then a SOAP webservice would be placed there. Just think of it as exporting XML over HTTP instead of HTML over HTTP. Nothing special really. Nemesis: Hope the travels are still going well. Good idea about the conference call but I find it hard to catch Case on HL/TS. He's in timezone +1 and I'm currently in +13. You'd think the morning/evening overlap would work but it does get tricky. So I'm afraid these forums are the best I can do for now. Plus, it allows others to get a glimpse at all the hard work that goes into making Case's global stats work - something all the naysayers don't really appreciate when they come to these forums and complain about work done by the LO community.

Lovely. Thanks EvilBivol-1.

SOAP Webservices should be used rather than re-inventing a solution in LUA or whatever. Webservices allow the client to be written in the language of the user's choice and there are a huge number of tools already out there (for Java JAX-WS/Metro/Axis2 etc for .NET WCF). Plus, this is the way that industry solves the exact same problem - it is good for your IT career if you know how to use SOAP Webservices. The advantage of such a system is that neither a common backend or common frontend is needed. Each squadron can customise as much as they want. They only thing they need to agree on is the format to exchange data on (eg. the joint SOAP Webservice specification to be agreed upon). Again, this is how businesses do it since they've already tried and dismissed ad-hoc client-server models. On the VNAO statistics board I mentioned earlier the scores software I gave a link to earlier makes player information available (well, pretty much all the statistics are available) via a SOAP Webservice. Yes, this show the online players that connected from Hyperlobby as well as direct IP connections (the reason I did this feature). The webservice has been running on: http://stallturn.com/dynamicscoreweb/DynamicScoreWebService?wsdl If you go to the link it won't make sense to you (unless you're an expert) since it is designed so that tools can automatically generate connection code for you. Instead, point a tool such as SoapUI at that link and you'll be able to submit requests: http://www.soapui.org

Actually, there is a way of clicking on a server link and starting LockOn which would allow Case's website to work without an applet. If the server described a Content-Type type for the link and the user's browser was set up to call an installed program with the correct server name and port then that would start LockOn just fine. Would require: a) A little program be installed on the user's machine (as Hyperlobby is now) b) That program is registered as the handler for the "application/lockon" Content-Type (or whatever name the server gives for that resources), and c) Case's webservice to be modified to return the correct Content-Type for the hyperlinks to online servers. In this case the applet is actually simpler (nothing extra to install) to start LockOn, but the webpage is much simpler for viewing stats.

I've mentioned on these forums before. The raison d'etre for my applet is to be part of a dynamic campaign system. The stats are just the post-battle analysis part. Don't get too excited though, the dynamic mission generation part will take a while to finish. So yes, T-Bone, people are working on this. But it is not related to Common Stats so is a little of-topic (I don't want to hijack this thread, ok?).

Yes, it is possible to do start LockOn from an applet provided the Java applet is signed with a security certificate (which is for your protection - can't have stuff on the Net randomly invoking programs on your computer). Whether self-signed is good enough to run exec() I don't know. Purchasing a CA certificate might solve it but is quite expensive (although I'm considering it for my Java applet stats running at http://stallturn.com/scores/). Some of the technology in that page will hopefully be useful to Case. Nb. The page http://stallturn.com/scores/ is in development so some pages (like the monthly team stats page) are not yet complete. Also, I don't intend for this page to replace Case's wonderful work, just to show what can be accomplished with a Java applet (eg. dynamic behaviour like table sorting etc). Running LockOn by clicking on a server is not implemented but should be possible from such an applet (which is why I abandonded an initial web-style scoring program [using Google Web Toolkit] and moved to an applet-based one, applets can do so much more). Incidentally, the Players Online tab shows who is currently on the VNAO LockOn server (will be put on HL this weekend). Usually no-one is online so the page is often blank but it does work. It is trivial to extend this to other servers and I suggested Case does this for his Common stats.

Case, besides and exit log entry being missed I've also seen game entry events also being missed (that is, double exits being reported) under tournament loads. Might be worth making sure the code can handle it.

Very nice Case! The great thing about common stats it is then very easy to make a page to show who is currently flying on what server. Which serves as a Hyperlobby replacement.

A dynamic campaign involves two major parts: 1) mission generation, and 2) battle scoring/analysis. As many others have done, I've done part 2 for LockOn. Am working on extending for BS (while hoping LO:FC 2.0 has the same debriefing structure). The work in part 1 is a lot but certainly not impossible. I don't think I'll be complete by the time LO:FC 2.0 is out but should be by the time DCS:Warthog is. The RAMGEN program for LockOn is pretty good but has very simple mission analysis. I'm not soliciting help at the moment as I want to get my battle stats released, operating, and set up an open-source repository before I ask for help (which needs Java, JAX-WS and Postgresql skills). Anyway, the point is some of us are not waiting for a dynamic campaign from ED since we know ED have limited resources and are focussed on making the sim better. It takes a long time to develop such software so unfortunately you'll be waiting a while before it is delivered.

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

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

Actually, proportional pursuit is more efficient/easier for the missile to compute than lead pursuit, if I remember the discussion in Robert L Shaw's Fighter Combat correctly (I read it a long time ago and I'm rusty on it). That book is such a great reference for the mechanics of fighter combat. If you haven't read it and you are serious about simming then buy it now. http://www.sci.fi/~fta/fighter_combat.htm We do know some things about the AIM-9X, for example it has an imaging seeker (thermal 'video camera') that is far better at discriminating between the target and flares. I think the R-73 may also have such a seeker, but I'm fuzzy again on that. We have some idea of field-of-vision, seeker slew rate, gimbal limits. Even inaccurate values for these would be better than not modelling at all.

There is another G-pulling problem I don't think is modeled (perhaps I'm wrong). Most missiles cannot be launched at the maximum G of the launching aircraft. Many missiles have launch envelopes that are a few G lower than the aircraft's maximum dogfighting G. Yet plenty of people take Shlem shots at 9 G. Hope DCS has that among other fixes.

I get what you are trying to say (your joke). Extending on that idea though I have some FYI. These not exact figures, but close enough High-value A2A Number of F-15 produced: around 1500 (shown as ~1500) Number of Su-27 produced: ~700 Low-value A2A Number of F-16 produced: ~4500 Number of MiG-29 produced: ~1600 Naval Number of F-18 produced: 1480 Number of Su-33 produced: 24 Attack Helo: Number of AH-64 produced: 1158 Number of Ka-50/52 produced: 26 Ok, the exact numbers of variants and sub-variants will change these figures, but certainly not enough to appreciably change the balance (and aircraft of US and Russian allies of other types are also excluded). So, the realistic scenario is actually to have more F-15s and F-16s with better electronics, weaponry and logistics against fewer Su-27 and MiG-29 with fewer advanced weapons (and with likely lower reliability in use). The games we have now are balanced by scenario designers (which is a good thing so everyone can enjoy it!) in terms of numbers of platforms. In real life this is not a likely scenario at all. Please accept this so we can move on. So, my point is, folks here are complaining about minor variations in engine thrust or missile seekers for their various favourite platforms while deliberately ignoring "The Elephant in the Room" - the fact that the colossal economy of the USA not only produced arguably better stuff for its specialised purpose (USAF has more aircraft specialised for particular tasks), but also a significantly larger quantity of it. You all accept this unrealistic aspect of the game without thinking much about it - which makes sense since the game is much more fun that way - but then why do you all insist on bickering over small aspects that ED have recognised as being incorrect and been moved to be more slightly more realistic ? (without being really 'real' which would give the crushing dominance you would expect in real life). I for one am looking forward to missiles with more restricted parameters. That way we have to get closer for a kill which is much more exciting. Shame we won't get seeker slew rate limitations and a whole bunch of other stuff that I guess is too much of a pain to model, but as a developer I understand the trade-offs completely (not everyone can afford the latest and greatest hardware). I feel sorry for the ED developers who get bad (and badly informed) comments no matter what they try to do - the upside is, at least they make products with passionate users.

Nice to hear of another squadron forming. It was nice to see you guys playing on the (in-test) VNAO server the other day. You are always welcome there.

That's my understanding. In fact I've heard it quoted as "when they get close we run away like the girls they are". It is not as if Eagle drivers aren't taught to fight in close. It's just they know that their estimated effective kill ratio as officially published by the Pentagon (7:1 vs Su-27) will plummet once the Flankers get close (yes, Flankers are on-par close in, calm down already). Probably Indian Flanker pilots might do better than that ratio, but that number is what was estimated by the Pentagon after flying both aircraft. A lot of it will be electronics and training hours rather than simple performance envelopes.

Yes, just make it as realistic as you can with the information (and CPU power) you have available. ps. F15 should be better than Flanker considering the amount of money spent on it, its missiles, radar, avionics, service infrastructure, training. The amazing thing is that the Flanker is nearly on parity despite being considerably cheaper.

Lol. Too bad your "military intelligence" didn't tell you that it was "extra" aircraft for the F-22 program was canceled and there there are 187 F-22s *already* built or planned to waste taxpayer dollars. Incidentally, the most powerful aircraft out there in terms of killability is the actually the 747 Anti-Ballistic Missile platform which can kill any aircraft/missile optically or thermally visible within around 200 km. Its no fighter but can waste anything else in the air. For the Russian fans of their stealth fighter. Mega yawn. Considering your prototype is taking its first flights only recently you are quite behind the technological times and your government can't afford very many (certainly not 187). Stop being gimps about this on these forums. You are a significant regional power now not a global one. Britain, France, Germany, Spain, etc ... had to make the transition from global power to regional ones. It is inevitable that this will happen to you given your relatively poor economy and Rule of Law etc. (which discourages global investors). So please stop wasting money on weapons as is not particularly clever. Spend money on social programs, infrastructure, fighting corruption and also play to your awesome strengths in science and culture. Then the world will sit up and take more notice of you - not with unsophisticated Cro Magnon knob-swinging braggadocio. With regards to the UFO debate etc. Amusing but pretty off-topic. I guess we're all tired of other silliness in these threads with people coming out with daft comments based on an incomplete understanding of relative flight envelopes and aerodynamics of real aircraft (possibly from listening to breathless propaganda from governments, aerospace companies, and the barely-informed mass media). However, ED forums and software have always been striving for improving the fidelity of simulations and the understanding of their users. Perhaps we shouldn't go too far with the tongue-in-cheek stuff as it cheapens the other good stuff in this thread. It's ok to be wrong as heaps of people on these forums will post and correct your understanding, provided the debate doesn't get skewed too far off-topic.

The BS format is more powerful and open for sure, not easier to deal with. With XML there are a lot of libraries you can use to parse the structure. With the LUA code it requires a lot more work. I'm not saying the LUA mission format is worse, because I like the new openness, it is just that it is more work to deal with. ps. Nice to see someone from sunny Sochi.