Moa

100ft is high when engaging a Buk. Fly at 200 ft (as the real A-10 pilots are trained to). When you are this low Buks will not launch on you at 32 nm but much closer (closer to your AGM-65D launch range around 6 nm). Drop to 30 or lower as you get close to the Buk, although you might temporarily pop up a tiny bit when launching missiles before diving back down again. As I said before, you have to practice to operate naturally at this altitude using sight alone to gauge you altitude. Avoid getting too close (don't get closer than your launch range unless there is cover lyou can use eading to the target!), engage each Buk seperately, making sure only one is close enough to launch.

If you are in an A-10 then you can use the terrain-masked approach that EtherealN suggests. Any little gully and fold in the ground is your friend. On a flat plain you could approach them in LockOn 1.12 by going very very low since the radar horizon decreases with altitude and you can fly low on flat terrain (there is historical precedent for this, eg. Operation Opera). Unfortunately at very low altitude you throw up a dust trail that fighters are drawn to. It takes practice to fly this low while watching for fighters and IR SAM launches. In LockOn 2 you can still do this. Crawl at very low altitude into Maverick D launch range, launch (two missiles in case one is hit) and break perpendicular to the target. You must keep the target visible so you can see any launches. If you are launched on wait until the missile is close and then pull into the vertical. The high-speed of the missile and g-limit means it cannot turn with you and should pass underneath you. Dive down again once the missile is defeated. For this you must get very good at judging missile closure and also you altitude so you know exactly when to pull up so you don't hit the ground but don't balloon either. Don't fly high, you will die. If there are any fighters about you cannot safely engage the Buk. Run away and let a Toad deal with it. Most importantly, a SA-11 kill is not worth the loss of your (or any) aircraft. If you can't beat it then bring your aircraft home or find easier targets to kill. Suicide is for the n00b.

FYI: the correct term is "angular velocity" not "angular momentum" (although they are related). The apparent angular veloicty is not a constant for a target crossing the flightpath of the shooter. For constant target velocity the angular rate is a maximum when dead ahead of the shooter and decreases as the target moves away from the shooter's longitudinal axis. The angular crossing rate also depends on range. All of this makes manual deflection shooting tricky (and that's not accounting for height differential, projectile drop, wind, air density variation etc). It's amazing we hit anything at all when we ignore the gunsight.

Thanks for keeping us informed Wags.

I'm working on a mission generation tool for dynamic campaign software (which I've posted about on these threads before). Part of this is reading an writing mission files. I also have existing (Java) code that can parse Tacviews. Given a mission and a Tacview I can generate a new mission which reflects the mission state at a point in time covered by the TacView. Unfortunately, completion of this software is a couple of months away (it is a lot of work and will take a while despite me working on it nearly every night [which is why I fly rarely these days]). This is probably not soon enough for re-starting the 51st's excellent Crimean Incident, Breakshot - but might help later on. incidentally, I intend releasing the source code to this software under the GNU General Public License v3. This will allow anyone to modify the code for whatever purpose they see fit - I'm a bit tired of people having to invent the wheel from scratch because many of the talented folk in this community hold on to their source material as if it would bring them millions of revenue. While that is their right, it is very inefficient in terms of the overall community. The source code matters more than any finished product! In summary: I'm already working on a (dynamic campaign) tool that can generate a new mission based on an old mission + TacView log (+ reinforcement schedule + order of battle, although that part is not being asked for here). However, the fact that I'm already working on such software should not discourage someone else from making a 'quick and dirty' solution to this problem if they feel motivated.

Flak is not much used these days. It is ok for point defence of fixed targets but is hopeless against the stand-off capabilities of modern weaponry. The speed of modern attack aircraft renders optical tracking ineffective and radar tracking is relatively expensive for limited capabilties. That's why everyone has switched to SAM based defenses except for very short range radar-guided AAA defence against low flying aircraft. Flak would look pretty, so I don't want to discourage you. It's just not really a big part of a 'modern era' simulation. Perhaps you could put your obvious talent to use creating some other objects.There is a whole heap that could be done - the Spanish Airforce or Navy, or older Warsaw Pact or Western aircraft that would be activated in the event of a big conflict? For example, some people would love to see a decent F-4 Phantom in the game (not me, I'll stick to Hornets thanks :) ).

Panzertard is correct. The User Interface uses a libraries that are based on OpenGL (check out the bin directory, there is the 'OpenGL Extension Wranger' library glew, and it looks like the OpenGL version of the freetype font rendering library ftgl, IIRC). The game itself uses DirectX. You need both OpenGL and DirectX drivers installed. If you have an ATI or NVidia graphics card then re-installing your driver should ensure both are installed. It is not uncommon for OpenGL to be used in games and graphics libraries, so you ought to install it on your computer. Check out anything from Id (the Quake engine and its descendants) and IL-2.

would be nice to see weapon launches as well. Allows you to calculate launch/kill effiiciency. Don't forget that launches and landings should include the carrier too!

True. We could discuss ad-infinitum over the full differential equations of compressible fluid flow the effect that any particular variable has on roll-rate. I agree with your point that the roll rate is a function of a lot of parameters. My point was that the higher roll rate in LO2 is more realistic than the slow rates in LO1.12. Hence, some 'fidgetiness' is to be expected - although it sounds like the original poster had some hardware issues and adding a bit of control dampening in the software also helped.

The roll rate of most modern combat aircraft is around 360 degrees per second. The A4 Skyhawk was known for being able to roll at around 720 degrees per second. It is a great improvement in LockOn 2 that the roll rate has been increased to more realistic levels. If you think that the aircraft feel 'fidgety' then I'm guessing you may never have flown a real aircraft. To me it always feels like 'skating on ice'. The wind and all sorts of factors can all perturb your travel slightly, even when you're all nicely trimmed. To me, most flight sims feel like you're driving a tractor that ploughs straight-ahead. It is the lack of 'fidgetiness' that lighter aircraft have I find noticeable in sims.

No need to download a GUID generation program. There are a heap of online GUID generators, for example: http://www.guidgenerator.com/online-guid-generator.aspx http://www.guidgen.com/index.aspx The trick is getting everyone to agree on the same GUID for the same thing. That's why using 'slots' can work, but there is no real reason to re-use slots. LUA allocates values dynamically so can handle as many values as are needed.

Nice screenies. Thanks for posting. Always looks good having folks in action together.

Also, don't fly very high. If you are below 1000 feet you can simply dive down below the radar horizon of the SAM battery. You will have to keep extra watch out for AAA and manpad SAMs though - but they are far less of a threat than larger SAMs. Don't fly straight at a launching unit once it has engaged you. Try and work your way to launch range (around 6 nm with a Maverick D), fire one or two missiles (since the first can be shot down) and extend or 'beam' (run perpendicular to a straight-in apparoach) to the SAM. If you can target the radar rather than launchers you can then go an clean up the launchers (integrated SAM vehicles don't have separate radar though). ps. Of course, in the real world you'd simply retreat and wait for one of the USN/USAF SAM-busting units to sort it out for you, such as: F-18 C/E, F-16G (Wild Weasel), F-15E, EA-6, EB-52, F-117, F-22, F-35, any of the cruise missiles especially the newer stealthy ones, and even MLRS. They are all equiped and tasked to kill SAMs, and the A-10 is not.

Use a Vikhr instead. Plus, you can stand-off since the engagement range of the Vikhr is usually longer than the engagement range of the Shilka. Save your Anti-radiation missiles for nastier targets (SAMs) who can engage you outside the range of your Vikhrs.

DirectX11 multithreading? FC2 & BS make DirectX9 calls, dunno whether that path will be multi-threaded. Even if it were it was the experience of Sun's OpenGL programmers that it was *slower* to render graphics in a multi-threaded manner because the locking for thread-safety dominated any speed-up of the rendering path. Where you might get a win is not in rendering, but in loading textures and moving them between main memory and GPU memory, but then there can still be some contention. I'm sure specialised benchmarks might show a speed up but real-world applications don't get much faster rendering from a multi-threaded rendering pipeline. They do get a benefit if the rendering thread isn't used to do other stuff (physics, AI, texture/IO loading). Distiler, the original poster stated that XP was only marginally slower than Windows 7, so your statement that W7 "run this sim so fast compared to XP" is not correct. A difference of 3 fps is not statistically significant compared to normal frame rate variability (don't worry, it's an easy mistake to make and you're not alone, it's a sad fact that most game reviewers are completely clueless about statistics). Since this doesn't warrant the cost of upgrading for most people I would suggest that people don't upgrade their operating system specifically for this game (neither Windows 7 nor 64-bit will speed the game up significantly) - upgrading hardware would make much more of a difference. I hope that is a bit more informative for people considering whether to upgrade their hardware or software.

Borchi, this is off-topic but you might be interested in the following since your signature repeats a myth. Please see the following for more information about the space pen: http://www.snopes.com/business/genius/spacepen.asp

Stalls are scripted. Perhaps the minimum stall speed is in this script, since the Simple Flight Model probably doesn't account for VTOL/STOL and 60 kts is a very low speed for regular flight (unless ultralights are to be simulated :) ). Also don't forget that the Harrier cannot do VTOL with full fuel or heavy weapon load, you you need to test an nearly empty aircraft.

The conversion between polar coordinates (lat/long) and Cartesian (x,y) doesn't use a 'scalefactor' since ED use a Gnomonic projection. See the following topic for a discussion and some working Java code (there are earlier examples in C++ but they don't do the reverse projection). http://forums.eagle.ru/showthread.php?t=44427&highlight=gnomonic Yoda made a sign change to make it work in FC2. You can find the equivalent working code (Yoda's port to Lua can also be found in the LEAVU2 project) at: http://kenai.com/projects/leavu2/sources/subversion/content/LeavuGeneralClasses/src/nav/MapProjection.java?rev=703 It uses some related classes (eg. the LatLong class) in the directory: http://kenai.com/projects/leavu2/sources/subversion/show/LeavuGeneralClasses/src/nav

I have a Microsoft X6 keyboard that has removable keypad (so can be attached either left or right) but I don't use it (it is not attached to the keyboard proper) and I get this problem. I don't use Yoda's ERI mod at the moment either. I did have missile firing problems when in windowed mode, even when the window was fullscreen size. Most of my keyboard/missile launch problems went away when I ensured that the window was full size *and* the "fullscreen" option was checked. It appears focus in LockOn would be lost and then would come back after a few minutes (also meant I couldn't change nav mode etc). I've also found that re-mapping the chat commands to the FC1.12 bindings would also periodically cause strange keyboard behaviour - but I have not investigated this thoroughly to ensure it wasn't me making a mistake. Anyway, my point is you ought to have the "fullscreen" option ticked or other applications can steal keyboard input "focus" (looks like TeamSpeak 3 likes to do this).

Need slow closure with probe out, around 10kts overtake. Training vids for FC1.12 on FlankerTraining.

Huh? As we all know the M61 has a rate of 6000-6600 rpm (100 rounds/sec) of 20 mm HE shells. If one of them touches your aircraft it should be 'curtains'. Yes it makes dogfights short and nasty, this is as it should be. The change is far more realistic. Speaking of realism, my understanding is while US pilots are trained in BFM they try *not* to close to this range, prefering instead to use the advantage of superior radar and missiles at an extended distance. Once in close the US advantages disappear and the engagement becomes more of a lottery. I have seen a pilot describe this as "running away like the girls they are" once the bandits get to the BVR/WVR boundary.

You don't need any edition "Windows Server" to run the game, so don't waste money getting it (and don't use a pirated edition either :)). A regular desktop edition of Windows is fine - you don't even need to waste money on a "Pro" version since your machine is unlikely to be part of an Active Directory domain (yeah?). As Crunch said, you need a 3d video card installed, and your LockOn instance needs direct access to it. Therefore, a virtualized server instance will not work very well (although 3D acceleration is getting better and better these days).

Great stuff Grimes. You've set the bar a lot higher for those running multi-player servers. It is awesome to see the new features of FC2 getting used.

Halcyon, could you please give me the the names of the texture file/s (although a Mediafire rar would be better - since I can't access CDDS at the moment). It would take about 100 lines of Java to stitch an arbitrary number maps together, using the wonderful Java2D API (designed by Sun and Adobe, the latter certainly knew what they were doing). That said, the plain map still wouldn't look as wonderful as igormk's map, with its grid and legends.

It is sad to hear of this tragedy. Get well Striker, we've got our fingers crossed you make a full recovery. Hope you are up chasing nurses soon.