Moa

The mapping from Lat/Long to in-game x,y is complicated. This is because an Gnomonic projection is used to project the spherical surface onto a flat plane. The formulae for the projection (and its inverse) can be found in the following thread: http://forums.eagle.ru/showthread.php?t=44427 For the working Java code I wrote for LEAVU2 (including a bugfix by Yoda) see the MapProjection class in the LEAVU2 source code at: http://kenai.com/projects/leavu2/sources/subversion/content/LeavuGeneralClasses/src/nav/MapProjection.java

You don't like the external views on stallturn? I left them on so you could easily admire your EFA aircraft (since not much fighting goes on on that server).

Track playback will show differently to the real mission as it actually runs the mission and some things can change. The playback is mathematically 'chaotic' in the sense that if the initial conditions and subsequent playback have small errors these propagate non-linearly over time and increase until they are noticeable. The playback can have you shot-down when you survived in a real mission. This is a well known bug and was also in Flaming Cliffs 1.0.

Raleigh and Mie scattering can be done in real-time for the atmosphere using shaders. Please see the paper by R S Nielsen (and references) where he compares the sky from ground and from high altitude (he's got a mate who flys F-16s for Denmark) at: http://www.aj-productions.de/fsdeveloper/category.php5?category=Sky I've posted this link before in a different ED thread which talks about the same problem, and since it answers the same questions I've posted again. Apologies if you already read my earlier post. So, the sky background can be physcially modelled in real-time. The problem is only in the clouds. All flight sims I've seem seem to use billboarded textures for the clouds. The cloud texture is generated using a 'plasma-like' fractal map. You can see this is so if you've ever had graphics glitches and seen the texture rendered incorrectly. Using 'texture particles' to render cloud might work, but the framerate cost might be too high unless you had a second GPU. Using particles directly wouldn't work as it is too expensive at the moment.

Oh cool, you can change it with a vertex shader. Thanks for providing the source.

The best models of the sky are physically based models. For example, R.S. Neilsen's paper considers Rayleigh and Mie scattering and compares to observations from an F-16 at altitude: http://www.aj-productions.de/fsdeveloper/category.php5?category=Sky Such physically-based sky models can easily be rendered in real-time on today's GPUs using shaders. Then we have physicists such as Yoda, Case and myself (plus I'm sure there are others in the community) who can understand and use the source code in the paper. The problem is, even if you came up with such a rendered sky how would you get it into LockOn? (since it is not a texture). Regrettably it is not something that is open to modders.

Exporting a texture from graphics VRAM to main memory is always slow. The entire system is optimised to do it the other way around (it is far more usual for textures are deleted in VRAM rather than copied back, so graphics systems are not optimized to copy back in an efficient manner). Yeah, the multi-monitor capability sounds like the best bet. I wonder whether you can embed the multi-monitor window in an existing window? That way the rendering is controlled by BlackShark, you simply control the position of where it renders and the z-order.

REX looks awesome. Thanks for posting the pics. It's also just been me made available for X-Plane (which will go nicely with the MBK-117 helo you can also get for it). I'd suggest ED could use SundogSoft's (http://sundog-soft.com/sds/) cloud rendering library but REX looks even better.

Also remember that radar altitude increases with roll angle of the aircraft (by a factor of 1/cos(roll angle) for those mathematically inclined). A radar altimeter will read 41% more than the actual altitude at a 45 degree angle of bank (that is, your altitude is 70% of the value indicated on your display). At 90 degree angle of bank your radar reports max altitude yet your actual altitude could be any value (including zero). Barometric altitude is not affected by this effect, but has less precise measurements and is affected by changes in atmospheric conditions.

Thanks Vyrtuoz. I especially appreciate your effort in compacting the logs. The stallturn.com server produces around 2GB of logs per day even if very few people join in (the bots are busy killing each other - especially the tanks). Making smaller logs saves me a great deal of disk space.

I don't expect you to do the work - you have more than enough to do. I was going to do it sometime this week :)

Carry the Imaging Infrared Mavericks (AGM-65D). They are heavy (so you carry fewer than Maverick Ks) but they have better range and are great for spotting targets. I save the Mavericks for known SAMs and try leave one on the rail to spot further targets - only firing when I'm done with the target area. Smoky's point 8 is excellent. Generally you don't overfly your target. Sometimes you can if you've reconnoitered very thoroughly (with Maverick D) and know there's nothing nasty there (usually you don't spot everything though). All it takes is one lowly punk with an Igla you didn't spot and your war is over. Best to use standoff weaponry if you can.

Flying at 10,000 might have been used in the Gulf Wars once the ground and air threats were dispensed with. It is indeed a good tactic as it protects you from AAA and shorter-ranged SAMS. In a Cold War scenario (eg. LockOn) flying at such an altitude is tantamount to suicide on multiplayer servers (IMHO). You must stay low. This is what was done in real life by Hogs training for The Next Big One. They learnt to read maps and spot targets while dodging obstacles at 100 feet (which is extremely low in real life on anything other than pancake terrain). High = advantage for fighters; Low = survival for attack and bombers (which is why B1B was designed to operate so low; and B-52 adapted from high to low role). Keep a close eye on your RWR. If a fighter makes it to the middle ring (getting close) you ought to turn and run for base or a friendly SAM. You can lure fighters into your SAMs if you remember where the are (I've done it a couple of times and am always amazed by the stupidity of the fighter pilots looking for an 'easy' kill). There is no way you can duke it out with a fighter unless you have no stores left (Maverick Ds and Mk-20s are heavy so your famous turning ability is useless with them on). If the fighter gets low for a gun shot you can kill them (they often forget about your Sidewinders in their bloodlust). If the fighter remains high then you must get away from it - as that pilot knows what they are doing. In all cases you need to read and use the terrain to your advantage. Once a fighter gets with active missile turn-and-run range (R_tr) and has a clear shot you are toast - so bug out before they get that close (you need to bug out early since they have twice your speed). Fortunately with the Hogs miserly turbofans if you run away you can loiter for a bit before continuing with your mission (a MiG-29 would long have run out of gas chasing you before then - although not every fighter pilot flies with the intent of making it back to base). Best defense in mp is to join TeamSpeak and ask a friendly fighter to cover you. Many fighter pilots take great pleasure in helping you (plus, you are wonderful 'bait' to which the dumber enemy fighters are drawn which makes for easy kills :) ).

Up until the mid-1990s we did (which is the time period covered by LockOn). We even bought a bunch of F-16s cheap (originally destined for Pakistan but their nuclear test resulted in the sale being canceled by the US). A change of NZ government resulted in the ordering being cancelled before delivery so it is not too far fetched for NZ to have F-16s (plus, the A4-Ks we had were upgraded with F-16 electronics and weaponry, eg. Maverick and GBU). Anyway, having identifiers for all nations is the goal - irrespective of their particular order-of-battle.

Even a properly trimmed aircraft can oscillate in a motion called a 'damped phugoid' if the attitude is moved from trimmed position and the pilot then puts in no further input. The trim dampens the motion so it eventually settles back to the trimmed attitude. Have tried it personally in a real aircraft (RNZAF CT4B).

Michelange. If I gave you a flag for New Zealand would you be able to add the ripple? or tell me what program you used to do it. What pixel size would you like for the flag, officer rank stripes (which are actually the same as the RAF), and medals? Excellent project by the way. I was thinking the community should at least agree on country GUIDS for all countries. That way countries_db would be set an all mods would agree on them (no chance of a mod overwriting the values). Lulac: perhaps you collect the same for Serbia, since there are so many Serbian guys flying - I'm sure they'd appreciate it.

Could you please confirm GG, altitude hold? Wouldn't attitude hold be a better trim (eg. can maintain climb or bank)?

Access violation means a bad pointer (pointing to an invalid or protected memory location). Only possible through a program fault (bug) or bad data that wasn't validated on input. Theoretically can also be caused by a cosmic ray impacting the RAM chip (which ECC RAM is designed to correct for), but this is not likely.

Yes. There's one of everything flyable in EFA on stallturn.com. Mission ain't flash but externals are on so you can do some nice movies (using lottu of course :)). Landing a B-52 "Buff" nicely is a lot different to an Eagle. Thanks for pointing that out jalebru/Wraith.

Yeah, already got it for the Mac. Apparently, "The Cake is a Lie". Thanks for pointing out the link.

As I've mentioned enough times on these forums I'm working on a mission generator/dynamic campaign. This is of course not something that can be done overnight. I don't think a mission editor will ever be able to live up to all of coolts' wishes. This is because in part because a human operates so much slower than a machine there are limitations on the complexity of inter-relations a human can make between mission elements. Being able to re-use 'templates' would go a large way to speeding things up compared to always operating at an 'atomic level'. Your example was for escorts that should follow their protected asset. My favourite example is that you should be able to tell AWACS 'where' to patrol rather than mucking around with loop beginnings and endings. I think the mission design should still have the existing 'atomic' elements of setting individual waypoints. This gives wonderful flexibility and is a strength of the editor. I just think it should also have some kind of macro elements that can be used to simplify common situations (eg. AWACS orbit, etc). The biggest enhancement would be to define and duplicate such macros. That is, if you defined waypoints for an F-15 you should be able to label that 'macro' action and then clone it so that you can quickly add 5 more F-15s with the same waypoints. From there you might want to 'disable' the cloning to customise each aicraft (eg. payload, skin and tail number) slightly - but at least the bulk of the work would be done for you. Being able to introduce external 'macro' elements would allow the excellent 'merge' functionality of the LO 1 editor. This merging was used to great effect where mission plans developed independently by BLUE and RED teams were merged into a final mission. Like I said, I'm working on a mission generator. I don't intend adapting this to be a mission editor at the moment as there is too much else to do getting the feedback between missions going for a dynamic campaign. The biggest issue I have is not the Mission editor per-se. Instead it is the inconsistency in the mission formats (LockOn 2.0 has some misison options using the BlackShark format, and some using using the new format [which unfortunately has *less* options, eg. engine volume control - which I dearly miss]). I also notice some variables that seem to have integer values (eg. 2) sometimes have floating-point values (eg. 2.0) or string values (eg. "") which means I have to code taking into account all these variations. This is a consequence of the loose-typing of Lua which appears to allow rapid-development but actually lets lots of bugs slip through (the compiler can't help you catch them) and hard to keep the mission format consistent (which makes it hard for integrators like me). Anyway, a published 'rigid' mission format would be handy, and ease adding third-party tools to make up all those little niches where ED can't get to.

"too much to drink" - that's not possible!

you want that kind of realism you need X-Plane. There, fixed that for ya (X-Plane was invented so a real pilot, Austin Meyer, could practice his instrument flying - unlike FSX, which was originally designed as a game by SubLogic).

Hi little-dog. FYI: The VNAO F/A-18F (currently in a closed beta) used a MiG-29 cockpit (for multi-role stuff) and you can land on the Nimitz (Eisenhower actually) ok. VNAO F-14D uses F15 cockpit. Dunno what VNAO's Wraith did to get it to work (besides his usual 'magic').

The fact the A-10 works by itself probably means you have set AI control of it. For single-player missions you want to set the "Skill" field to "Player". This will allow you to fly the aircraft. For multi-player missions you want to set the Skill to "Client". AI levels are anything other Skill values: Random, Regular, Good, Excellent etc.