Moa

Also have to remember what conditions the A-10 was designed for. In the Central Front the weather was usually pretty bad, which means you *have* to be 1000 feet or below. No point putting a radar on your ship to spot targets when you are low enough to reach out and touch them anyway. Also, where exactly would you put a SAR? there just happens to be a hulking great GAU-8 just where you'd usually mount a radar. Plus there is a question of cost. Turning a relatively cheap aircraft into an expensive one (since you would need more than just the radar dish and mount itself, such as the signal processors, a change to the in-cockpit displays etc etc). With regard to aircraft vs SAM discussion - unless the aircraft is surprised (can happen, but not that usual if you have proper intelligence assets) the aircraft should always win. Why? because the aircraft always has the *initiative* it can chose when, where and how it will fight the SAM. The SAM can't force the aircraft to engage - that is, it does not have the initiative. So, if there is a surprise SAM that no-one knows about they can be deadly (on the small scale), but if they are known about then Western aircraft pack a lot of anti-radiation missiles which are enough to scare most SAMs silent (which is why on a tactical level the suppression of SEAD is nearly as good as good as the destruction of DEAD).

@Speed: I don't think LUA has anything in its standard library to do this. I was thinking it could be done fairly easily in C++ using custom code. The nice thing is that the Integrity Check is does not have a per-frame requirement, so can be relatively expensive in computational terms if needed. Doing a simple parse to find the LUA keywords and separators is not that hard - I had to do something similar (although simpler) to convert LUA tables to XML (and thence to objects via JAXB) for my lottu tool. IMHO the benefits of having Integrity Checking work even when whitespace, comments, and formatting is changed would be well worth it. The motivation for this (that is, the current situation) is the fact that Config/Export/Export.lua has a single space on the last line and if that space is removed (accidentally, such as enabling or disabling TacView so you can join various FC2 servers) then you'll fail the Integrity Check. Worse, when you compare the files visually you'll have to notice that the (non-displayed) space has changed. Alternatively, you also can't simply comment out the TacView include line, since changed comments also currently causes an IC fail too. This is why I suggest a normalization of the files to be compared before computing the bit signature (SHA-1, MD5 or whatever) of the file. Having the comparison resistant to changes in formatting or comments would prevent a lot of re-installations, since lots of people find it hard to work out what has changed in their modded installs and simply re-install to pass the Integrity Checks for various servers. This ought to be done if ED is heading toward more modding of aircraft (which their changes to the aircraft description database files [eg. P-51 files in BlackShark 2] seem to allude to).

By normalize I mean all comments removed, all whitespace compressed, and all tokens get exactly one space between them. Then it you can still validate the Lua no matter where your line breaks, spaces, tabs, comments, non-space (in your example) etc occur. Otherwise you are still stuck with the problem were Integrity Checking will fail due to trivial (that is, make no difference to the Lua) changes to the file.

Please check out pages 142-143 of this book. http://books.google.co.nz/books?id=C8ZUBjtLXjEC&pg=PA143&lpg=PA143&ots=x0EMf8eS3v&dq=stall+on+touchdown#v=onepage I guess I'm just an old timer in non-transport aircraft (was two decades years ago I used to fly regularly), hence my 'old fashioned' view on slowing before touchdown. We used to make relatively steep approaches assuming we'd have power off or battle damage. That references also points out the current technique and training is to land faster, as BlueRidgeDx says. Sweet.

So, we're talking of a difference between touching down at 120 kias and 112 kias after the flare? I almost never get down to the lower speed on touchdown but when I do it is after a good approach and a well-judged flare and hold off, IMHO.

> But how does one distinguish between significant and non-signficant spaces? Not required. Simply compact all sequences of whitespace (space, tab, carriage return etc etc) into a single space charatecter. Also replace all Lua comments with a single space before this. Once 'normalized' in this way you can then do a bitwise comparison. This is the kind of thing compilers do (normalize space).

Thanks for making DCS better Dmitry. Is it possible for the Integrity Check to ignore whitespace and Lua comments? Rather than a bit-for-bit exact match normalize the server and client side Lua (compact whitespace and remove comments) before doing the comparison. If it is too hard then that is ok, but if it is easy then that means we can leave as comments the include for TacView etc even on servers where TacView is not permitted. Then you can just comment and uncomment stuff. With regard to the protocol level stuff. Would it be too expensive for the server to validate the inputs from clients, or is that what you are doing now?

Thanks for the info from the -1 manual. Maybe A-10C is different (I haven't read its -1). Stall warning is a few knots pre-stall, yes? Can't remember now whether it was the F-16 or F-18 -1 manual where you get different types of stall warning depending on how many knots above stall you are. Intermittent warning is a couple of knots off, IIRC. Continuous warning is 1 knot off. In that case if you hear a peep just before weight on wheels you're not doing too bad (better than slamming it down fully laden at 120 kias - but perhaps the Hog's gear is strengthened for such things, I don't know).

Try this: 1) Start by getting your speed approximately right. 140-150 kias (knots indicated airspeed) at outer part of approach. If you are faster than this then everything will happen too quickly. Get slow early! 2) Get your approach height right. You want to be around 1000 feet in circuit. If you are doing a straight in then at 150 kias you travel 2.5 nm/minute. At a 2000 feet/minute descent rate you will need to be at or below 4000 feet at 5 miles. For a 1000 fpm descent you'll need to be at 2000 feet at 5 miles. If you are too high when you start your approach you'll be too fast coming in. Don't start too high! 3) Use the Angle-of-Attack indexer on your approach to get your speed and attitude (nose pitch) correct. Practice using this. But until you are used to this consider your approach speed should be slowly decreasing to 120-125 kias with 40% speedbrake deployed. Use small nose pitch adjustments to ensure you don't get much faster or slower than this, then trim. Control your speed! 4) Set your flight path marker at the near end of the runway. If it moves up the runway then decrease throttle a little and let the marker come back to the near end. If the marker moves in short of the runway then add a little throttle and wait until the marker moves to the runway. Try not adjust your nose pitch during your descent once it is set correctly and trimmed (that is, don't dive for the runway). Many people learning to land run out of runway because they don't flare until well down the runway. While learning, you should be beginning your flare at the point you cross the runway threshold. 5) Once your cross the runway, close the throttle to idle and gently raise your nose so that the flight path marker rises to the far end of the runway. Hold this attitude until you touch down. As you hold this your speed will bleed off and you will descend gently to the runway. If judged correctly you will be flying level a few feet off the runway with a slightly nose-up pitch attitude while your airspeed bleeds off. Note: if you are descending a little too fast then a little throttle before touchdown can soften the landing - at the expense of greater roll-out distance. 6) If you have timed your flare correctly you will touch down just as the stall warning sounds. If this happens then you can be pleased with yourself. 7) As soon as you touch down deploy the speed brakes to 100% (full open, maximum braking). 8) Hold the nose wheel off the runway with the same attitude you touched down with. Don't pull back or you will hit your tail. 9) As your airspeed decreases allow the nose to settle on the ground. 10) At 80 kias enable nose wheel steering (INSERT key; right pinkie on TM Warthog HOTAS Stick). 11) Unless you need to stop in a hurry wait for your speed to decrease further before applying wheelbrakes. If you are out of balance while braking you may start to slip/skid sideways, so it is better to wait until you get slower than 80 kias before you brake (as you will be less likely to skid sideways). 12) Once you are below 15 kias you may begin turning. Turning faster than this can lead to skids or blowing a tire. That's the specifics. In general you need to: A) descend from the correct height and at the correct rate B) control your airspeed (keep your nose pitch positive, don't dive). C) aim for the runway threshold while descending and not down the runway (use throttle to control aimpoint). D) open speedbrakes to full on touchdown. E) hold the nose wheel off the ground for a little bit before allowing it to settle. F) wait until you are slow before applying nose wheel steering and braking.

Sorry mate if it is driving you to distraction :( we're just hanging out for it so much - that's all. Like little kids dreaming just what Santa will leave under the tree. Falcon, Hornet or Eagle. If it is any of these we'll be delighted.

EtherealN, the interesting thing is that "Android" is in fact Linux. Whenever you hear "Android" the techie part of your brain should translate as "Java on Linux" - because that is exactly what the marketing term "Android" means. Java on Linux is the best cross-platform development language on arguably the best (most robust, cheapest on commercial scales, easy to develop for) operating system. While Linux has a low desktop share, and it makes little sense to develop a client specifically for Linux, the mobile and server shares of Linux are substantial. While it makes no sense to make a Linux-only client (or dedicated server, whenever that happens) it actually doesn't make much sense anymore to make Windows-only software anymore either. With the right development tools , (eg. languages, IDEs) and techniques (test driven development) you can make portable software that works on many platform that is actually not really any harder than making a single-platform client (with the right approach cross-platform can be pretty easy, I have to do this in my day job). Making cross-platform software makes business sense. Everyone who makes Windows only software is now locked in to that market. That market is big, but they have chosen only to have a 'slice of the pie'. Those who have chosen cross-platform can get revenue from the 'whole pie' instead - no matter what the future holds (how many people five years ago would have predicted the rise of the phones and how much revenue people could generate from them). I've posted this article before, but for those that missed it here is a case study from the X-Plane developer where he shows the $US 3.5 million dollar financial payoff from him choosing cross-platform from the start (and ignoring all the Windows-only naysayers): http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/ It is too late to make the core DCS software cross-platform. However *new* projects can be designed to be cross-platform (eg. Java) from the beginning.

Just as well FC2 only uses one-and-a-bit cores then eh? :) Realistically, you'd do the filtering on another (Linux) box you use as your gateway.

Ah. So if you proxy and do a deep packet inspection you could block that packet and let everything else through - and you could log against MAC address. Do you know the specific contents of that packet? If the packet content was fixed a little proxy program running on each game server would solve the problem.

Actually, the real fun the lame script kiddy gets is thinking he's smarter than the rest of us. He's not. If we actually gave a damn we'd write programs to capture his signature and proxy our servers with that. But most of us don't give a damn anymore so we are not doing all in our power to stop him. Otherwise he'd shortly be getting a visit from the police (his attacks will last a short time until ED patch their software, but the recordings of his 'fingerprints' will be around for a lot longer than that). It is a shame such maladjusted folks are about. I guess he doesn't fit in anywhere so scripting is what he does. He won't be smart enough to actually *create* anything worthwhile (which takes much more skill than some simple hacks). This is why it takes teams of skilled engineers to make something useful, and only one lonely lamer to do some basic hacks - the latter is the much, much simpler task. The problem with this turkey is that he's so dumb he thinks his little scripts are so l33t, when in fact they're so basic most of the capable devs see how easy it is and quickly move on to far more interesting things. Only n00bs still fresh-of-the-boat think such things are cool. Note though that just because the attacking scripts are elementary stuff doesn't mean it just as easy to defend against - the Internet just isn't built in a way to make it easy for the defender.

Good luck with your project DetroitDiesel. Depending on whether you have much of a development budget or not you can get a lot of models at reasonable prices from Turbosquid eg: http://www.turbosquid.com/FullPreview/Index.cfm/ID/223875 The terms from Turbosquid (my interpretation of them, please double-check yourself) are basically you can re-distribute models royalty free provided you put the models in a proprietary format (similar to what ED have done with their assets). If you have the cash you can either buy models so your sim has a lot more variety, or buy models you were going to make yourself but now don't have to (saves a huge amount of time). I'm doing this (buying models) this for a jet combat flight sim I'm working on, eg: http://www.turbosquid.com/3d-models/3d-navy-fa18f-fighter-black-aces/220146 I'd actually rather like to make the models myself so I could distribute them in an open format but I don't have the time (and fortunately have the money, through blood, sweat and electrons). Personally, it seems ridiculous everyone re-inventing the same models over and over rather than having an open source approach. But if you personally don't intend placing your models in an open-source format (I will with some of the things I'll have to make) then buying models under those terms is not too bad. Please keep us posted with your progress.

This is what has happened to Battlefield 3. It is an awful solution IMHO. The BF3 world is pretty sterile compared to the vibrancy of ED's products. This also wouldn't stop some kinds of attack (DOS, DDOS). The fix for this particular attack should be simple. No client can connect more than some times (eg. 3) from the same IP at once. No client can provide Lua that can run on the server. In short, the game clients can never be trusted. This does not mean that game servers need to be centralized (which would give horrific ping, and crappy reliability), just that they need to be secure (again: never trusting the client connecting to them).

Kind of. As you well know pretty much all projects take longer and are more troublesome than initially anticipated. This means that to make a deadline resources are often borrowed temporarily from other projects to get something past the finish line. If DCS:Jet is not intended to be the first cab off the rank then it will have the lowest priority when it comes to stealing .. er .. reassigning .. resources temporarily. I think Eagle Dynamics have been very canny in not promising anything early, they are free to change their priorities around and we are none the wiser (just as well, since the howls of indignation would be deafening if any date slipped). There are inefficiencies of working in parallel. Quite often there are specialised resources (eg. certain people) who are needed on multiple projects. Yes, some tasks can be done happily in parallel - but some cannot if they rely on a single person (there is but one Yo-Yo; alas he cannot yet be cloned). If they spend longer getting one project done then the reality is that it either pushes back other projects, or corners get cut (usually in testing, anything late gives testers less time to work with). I'm sure you have seen this yourself. The sad fact is we're so desperate to get a modern fighter or multi-role jet that we'd rather not see those other projects until that project is delivered. So, you are right in that we don't know the specifics of Eagle Dynamics' development process, but we do now the broad outline of how all projects generally pan out.

Openness Mate you hit it right on the head. Closed plugins and closed formats are good for no-one in the long term. The other thing that needs to happen (as a modder, now an ex-modder since I've given up modding DCS out of frustration) is that the modding interfaces need to be: * stable: no arbitrary changes from patch to patch. For example, when introducing event-based triggers in A-10C (around v1.0.0.7 or so, IIRC) the event logging was completely broken. * sensible: an example of the non-sensible, at the moment logging has a multitude of time units (eg. wallclock in some, date with no time, time since mission loaded, time since mission started). Initiator IDs are not unique within a game session and it is a PITA to convert from that into the unit type and associated callsign (not impossible, just a PITA). * accurate: example, things like the MiG-29 fuel flow from the export interface are not in any useful unit. The fuel unit reported seems to depend on the aircraft you fly. Game events callbacks often log incorrect or bogus data and can't be completely trusted. The get unit into calls were broken or inaccurate. All of these little things are easily testable and if automated and systematic unit testing is put in place they get caught and never regress. * interoperable: Lua tables for configuration might be convenient for the ED developers but it is awful for everyone who doesn't want to use Lua. XML would make more sense (it has much better interoperability). * documented: if you want modders then you have to document your interfaces, and maintain that documentation. Documentation that is incorrect is even worse than no documentation. The documentation has to be in English and written by a native english speaker. They also should be trained in a proper technical writing methodology (eg. Information Mapping, which is simply excellent IMHO). * open standards: choose open standards where you can. IEEE-1278 (DIS) over TCP or UDP for the multiplayer wire protocol; XML for configuration, with XSD schema for validation; OpenFlight for models with animation, damage states and level-of-detail; SOAP or REST webservices for non-time-critical information. Sometimes you can use open standards (eg. license restrictions on third-party models may require proprietary formats), but where you can, you should. In my opinion the more modders there are the greater the ecosystem around ED's products. The greater the ecosystem the more likely it is that players will stick around and buy ED's products. Being more open and having stable interfaces is the key to keeping modders on board. For me personally, after a sisyphean effort trying to mod EDs product in advanced ways (eg. moving map/flight computer; pilot stats; virtual controls etc) I got fed up because the things on the list above were only partially met, and each new product and release made it harder and more time-consuming, not easier, to integrate. From what I've seen the modders have been trying to communicate their needs to ED - it may seem like whinging but really the modders are trying to point out what would be most useful. We've received some support, and ED's devs have been very helpful where they can, but a more systematic approach would be wonderful. The reality is the recent restriction of Lua environments with no replacement interfaces has been a real pain (understandable for security reasons, but pretty much breaks more sophisticated mods, such as 16th_Speed's excellent slmod). More openness and stability would greatly facility modding and grow the resulting ecosystem. The resulting screenshots and tools attracts paying customers when they see a third party has adapted FC2/3/ DCS to match their own interests. This means a better experience for modders and players, and ED gets more players and more money.

Hiya Case. I don't know of any Windows-based firewalls that do this, but some must exist - the term to search for is "Deep Packet Inspection". Hope you find one that suits you.

A yeah, forgot it was DCS we were talking about rather than FC2 - you are perfectly right about this.

There is a 'who is online' function for the few servers covered by the 104th stats system. Please see http://stallturn.com/104th/ (requires the free Java Runtime Enviironment). In fact, it is easy to get who is in-game, although that is not a default part of the game.

Here's the thing. The SAM is much faster than you. You cannot outrub it - so don't try. The SAM can pull a lot more G's than you, so you can't out-turn it with a sustained turn. However the combination of these works to your advantage. It turn out (pun intended) that the high Gs of the missile can't compensate for it's excessive speed. This means that the turn radius of the missile is very large. What you can do on missile launch is turn perpendicular to the missile wait until the missile is a couple of seconds from impact and then pull up or down (better if you are inverted, since gravity is helping) as hard as you can. The missile will attempt to turn with you but since its speed is so high the resulting turn radius is much much larger than yours, so it can't get close enough for its proxmity fuse to activate (although only impact fuses are modelled in the game, AFAIK). Unfortunately such maneuvers deplete your energy severly so even with good timing (from practice) you usually can't defeat more than a couple of missiles. This means it is a good idea to do your pull in a spiral direction away from the SAM. Whatever you do, try not to lose sight of the missile, and once the missile is defeated try and re-acquire the launcher as you exit. Also don't get fixated on the launcher. Often evading one launcher can put you in the arms of another. The other things you can do is to hide behind prominent terrain such as a ridge or hill. You may be some height above terrain but from the launcher's point-of-view you are underground! Another thing to keep in mind is that the missile must fly an intercept course. It doesn't fly to where you are now (which would be 'pure pursuit') but to an intercept point ahead of you. That means for long-range missile launches (such as the lethal SA-10, but at least you get a RWR warning) if you dive toward the ground the missile will dive too and if you dive enough the intercept point me be below ground . The missile can be made to fly into the ground in this way (you have to be careful not to hit the ground either). For long-range launches where you are near the edge of the missile's engagement zone you can simply turn around and climb. The missile will climb too and lose a lot of its energy. Eventually the missile slows down so much it can't intercept you. For this you need to have understand what missile was fired and your approximate location within its engagement zone (only works when you are near max range). Note that the SA-15 is especially tricky. It waits until you are well within it's engagement zone before launching. If you see an SA-15 launch on your RWR then you won't be able to turn and run then climb, since it has lured you close. You have to use the last ditch high-G pull maneuver to defeat these and then get the hell out of there before it launches again. In the case of IR missiles you won't get a missile launch warning. Fortunately these missiles have shorter range and less maneuvering eneryg than the bigger SAMS. Without that launch warning you do need to keep your 'head on a swivel' though (look around!). Doing a pair attack where one A-10 is the 'shooter' while the other flies 'cover' to watch and calls SAM launches is *very* effective. Then when the first guy is winchester you swap roles.

104th has working moving map (centered around the player's aircraft) for FC2 in beta. I haven't had time to finish it for general use and was keeping it reasonably quiet, plus it uses a customised export script which currently fails the default Integrity Check (eg on major dedicated servers like 51st, 104th, =4c= etc). It uses the igormk TC-1 map that you show. nb. US/NATO Link-16 can share more than the 4 aircraft that Ka-50 is limited to, so this limit wouldn't need to be modelled.

Changing from color (eg RGB) to greyscale (intensity) is very easy and if you search on the net there are lots of ways of doing it. However since even camouflaged objects are distinct from their surroundings some other processing must also be happening. Either the in-game units are getting rendered brighter when in FLIR mode before conversion, or they have a 'vertext attribute' that gets rendered brighter in the shader (different techniques for the same effect). I too am guessing - but if I was gonna do FLIR quick n' dirty this is how I'd do it. Obviously a FLIR texture map would be even better, since anyone who has looked through an aircraft thermal system (I have :) ) or even a YouTube fan would notice that engines (and fired gun barrels) stand out from the rest of a vehicle. Cows, clouds and horses stand out amazingly too. From the brightness of the vehicle engine you can tell whether the vehicle is running, parked but run recently or not run for a while. In fact, the sensors are so good you can see the spars inside the skin of your aircraft, and even the change in air temperature caused by air passing over the wing during flight.

Hi Cali, So your TrackIR 5 and v5 software works ok stand-alone (sorry if you already posted elsewhere) ? It works ok for FC2 and A-10C for you, yes? You tried deleting the TrackIR profiles out of BlackShark2 so it could redetect the device on startup? I have had a TrackIR issue once (for FC2) I found and deleted (actually, just renamed, call me paranoid) the TrackIR configs inside FC2 and then restarted the game. TrackIR then worked for me again.