Moa

To summarize, the workarounds suggested are: For the missile seeker slew issue, manifested as the missile seeker slewing in a direction other than that commanded: * use a mouse for AGM-65D seeker slew. Of course, this is completely unrealistic and will break using the mouse to change your view. * don't use zoom. Of course, this is also completely unrealistic. Real Mavericks have no such limitation. For the missile lock bug, manifested as the missile seeker refusing to lock on to air defenses and locking to terrain randomly around the selected target: * There is no work-around. This appears to be done to deliberately to increase the 'challenge' for the A-10A in patch 1.2.1 and disregards the capability of the real Maverick to discriminate and destroy *all* targets at medium range (that is, what they were designed to do). This seeker 'feature' discriminates between air defenses and all other vehicles (which can be locked at longer range). Of course, this is completely unrealistic, and was probably done for the same reason as the AIM-120 is continually hobbled in the game (yes, despite the promises, it is still not as the performance numbers state even after patch 1.2.1) rather than perform as published. I did not mean to bait, it was a result of being incensed by your responses negating the problems users were reporting - which is not what I expect from an ED tester, or any 'professional' tester for that matter. I'm just disappointed that ED just don't come out and say, "yeah we adjusted the AMRAAM and Mavericks to maintain play balance" since that is clearly what was done. Then this argument would be moot and we wouldn't be stuck about arguing whether the observed behaviour was a 'bug' or not. If it is undocumented then it is a bug in my book - document it and it is not a bug. Whether or not it is a 'bug' it is certainly not what is possible with the missile in real life (except perhaps in the most disadvantageous situations imaginable). Thanks at least for pointing out some of the information about the seeker degradation for SHORAD. Without it the situation would be even more confusing. ps. The Mk-20 is also borked in game. I have supplied ED with a Naval Institute Press (Annapolis) publication (linked below) that says the minimum safe release altitude is 250 feet AGL in level flight or 100 feet in a toss delivery (of course release for optimum dispersion pattern is much higher). Unfortunately ED ignored this information (despite asking on the fora) so we get another weapon not simulated correctly. If you release a Mk-20 from below about 1000 feet in-game the canister will not disperse at all - yet the aforementioned document specifies the real-life dispersal pattern at 500 feet. http://books.google.co.nz/books?id=l-DzknmTgDUC&pg=PA265&lpg=PA265&dq=minimum+release+altitude+for+Mk-20&source=bl&ots=2riLD0p9Lj&sig=hnvJKx4pgEcfkUj2fH0SNmFXAH8&hl=en&ei=QaFvTJmhBIjksQOn1Y26Cw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBQQ6AEwAA#v=onepage&q=minimum%20release%20altitude%20for%20Mk-20&f=false No this is not classified material, but it is clearly a reasonable source given the specific detail it is able to provide (and it is the Naval Institute Press in Annapolis - won't publish classified but if you publish bollox their naval readers will know straight away). If anyone has a publication refuting these figures I'd really like to hear about it. nb. dropping unguided weapons from 10000 feet or 8000 feet (as suggested in this thread: http://forums.eagle.ru/showthread.php?t=53418) is neither what the Hog is designed to do or what the pilots of the 1980s were trained for (at that time the NATO European Central Front meant you operated low or you were dead, whole systems were designed or redesigned to operate low [as I've stated before the B52 was redesigned to be low and it is the principal factor in the B1 design]). This (unverified) source lists 500 feet AGL or 400 feet with pull up: http://electrosphere.info/index.php?showtopic=861 According to this the Mk-20 fuze time (release height) is selectable (pilot can choose release altitude in flight). http://www.ordnance.org/cluster_bombs.htm So the in-game 1000 foot limit seems erroneous.

Hi Sven, next time you are required to do a re-install please make a full-directory copy of the newly installed 'pristine' patched LockOn installation directory and rename it. I call mine "LockOn Flaming Cliffs 2 pristine". Whenever you suffer the same problem you simply delete the problematic 'working' directory and copy over your 'pristine' directory (after renaming it to the original directory name). But never ever mod or use that pristine directory (although you can set up your callsign and key preferences etc when you create that pristine directory). Doing a directory copy and rename from backup is far easier and faster than re-installing and doesn't use activations. Now back to the original problem. I have started the game in server mode and noticed that the server callsign changes from time to time. I believe this could be some kind of 'race condition' where there are multiple overriding config files (eg. for networking) and the value used depends on which order they are loaded in. Such non-deterministic loading could be the cause of your problems, but I think that is unlikely. Have you tried doing a disk-check on the drive you use for LockOn? a SMART drive will mask faults unless you are looking for them - so make sure your drive isn't on the way out. Are you overclocking your system and putting too much strain on your power supply (which could cause problems with RAM, which is then later written to disk). Umm, can't think of anything else at the moment. Sorry I can't help more with a definitive answer. Perhaps other contributors have more and better ideas ...

My point being, have you used an IIR system in real life? Maybe, maybe not. But here is someone who has used one telling you how it was for them. Shame you are again appear unwilling to listen. It's the same technology. I know, I've designed and built multi-wavelength imaging systems for scientific purposes. I know a huge amount about EO and CCD internals and operation (including specialist non-visible low and high wavelength operation) so if you think you know more than me, you don't. Sorry to be so blunt, I'm not here for a pissing contest I just want to head off any arguments about what you think you might know about advanced imaging technology. So please don't bother arguing this point. I really hope this was tongue-in-cheek, otherwise this appears to be one of the most arrogant insinuations I've seem on these boards - I hope I'm very mistaken. Yes. Can I say it any more simply than that. If I say it twice will that make any difference or will your mind remain closed to the possibility. I have watched cows and horses kilometers away through IIR from several thousand feet and they have a far lower signature than vehicles. IIR is so good you can see differential cooling through metal at closer ranges. Blame? Who gives a damn about blame? I became a much better developer when I learned to take my ego out of my development and not worrying about blame. Sure I am proud of my work but I realized being defensive doesn't help - an open mind is far more valuable. So, from this I surmise that you acknowledge the possibility of a problem but don't want it to be made your fault. Absolutely cool with me - it is not your fault. Can we move on now please to addressing the issue at hand? I simply would like the problem looked at and a work-around determined if possible. Again, you are not listening. Earlier posters mentioned they cannot achieve a lock even at close range. Ignoring the fact that guiding the seeker it 'doglegs' (one fault), you can ground stabilize over your target with little clutter but when you lock the seeker it jumps to a random location off the target (second fault). In some situations amount of retries will put it back on target. Naturally, sometimes you can lock after a couple of attempts - which is why you haven't had riots so far. Artificially degrading weapon systems is something we saw with the AMRAAM but I didn't know it was done to the AGM-65D as well. Isn't it bad enough that there is no player flyable Western aircraft that can launch HARMs (meanwhile the pet Su-25T can kill all manner of stuff from 60 km away) and the A-10 has to do SEAD with a Maverick. The Maverick is a devastating weapon against all targets, witness Gulf War I where it was indeed a 'Turkey Shoot' after the first few days. Big picture, at that time (80's - 90's) there were four thousand F-16s and F4 Wild Weasels to do the job for the Hog. It's bad enough to make the Hog do SEAD but to degrade the weapon system further is totally misguided. IMHO no product aspiring to be a 'simulation' should be doing this. To show you the fault as it appears for us. To show you that the seeker will not lock up a Tunguska at 2 nm when there are no other viable heat sources in the seeker's field of view. Clearly you think all of EDs customers are wrong and are unwilling to read and re-read the posts on this thread until to understand what they are trying to communicate to ED. Perhaps a video of the problem might help show you the issue, or give you an opportunity to state what you believe we're doing wrong (although I think even you finally might become convinced of the former). [reply to another poster] BMPs are nothing. The ground fire from BTRs in this game is far worse. I fear BTRs far more than Shilka - there is something very wrong with that picture.

Bvioash is looking at extending ERI - although it doesn't seem like any major server will support it as it requires a mod to be installed and most servers want to allow "plain vanilla" LockOn to connect. I have done an Angle-of-Attack control for Leavu2 but have not released it (have not put on bitmap skins yet). This is useful for carrier landings in VNAO aircraft. Some of the limitations of LockOn (eg. HSD not updating if not in primary nav mode) could/are easily overcome by Leavu2. Yoda did a fantastic piece of work.

I have not used or fired a Maverick. However I have used an Imaging Infrared system on a real life P3 Orion during flight. It was *very* easy to spot features and discriminate objects, especially at night. Please do not imply your users are clueless n00bs, although we may sometimes seem that way. We are trying to point out a flaw in the game that exists for us and it doesn't seem clear you want to hear it. In analogy, is as if this problem only affected ATI video card users but because you are using an Nvidia you think everything is fine. Denying we have a problem helps no-one - and certainly doesn't help the product get any better. In my years as a developer I've learnt (although it took a while) that while the problem often exists between the chair and the keyboard often there will be real faults that you cannot reproduce in your development environment. So, to help you we need to provide you with evidence of what we are seeing. Despite me writing the lottu software for FC2 I've never converted a track to video - I'll try and do this this weekend for you.

"Works for me" is a classic tester response. The fact is a large number of people *are* affected by the issue and find it unsatisfactory. Of course, this makes it hard for you to diagnose what you are lucky enough to be unable to reproduce. No matter. Even if the fault was acknowledged we are well conditioned that ED's current position is that there will be no more patches for LockOn.

Very well known bug introduced in FC2. It affects everyone. See this following threads: http://forums.eagle.ru/showthread.php?t=54534 http://forums.eagle.ru/showthread.php?t=53930 The IIR seeker locking random stuff used to be a minor problem in FC1 but is a major one in FC2. Note this is a problem of the missile not the A-10A, since I see the same effect when flying the EFA Harrier. Edit: And this one (has a comment from, Wags about the model, but doesn't mention SHORAD specifically being degraded) ... http://forums.eagle.ru/showthread.php?t=53750

That's 400kts indicated. Surely you realise at high altitudes your groundspeed is much higher (look at the indicator on your radar display) and the apparent 'low speed' is because the low atmospheric pressure reduces the absolute lift at any angle of attack compared to lower altitudes. One of the best fixes in FC2 is that you can cruise at medium and high altitudes at Mil power rather than Max power when in the Eagle.

Don't hold your breath while you wait Bob.

Hallo Shnowman, You may be interested in this work in progress at VNAO. The VNAO members pooled together to buy base models that we can modify and release to the LockOn community (not in source form, but in LOM is ok). Here's a work-in-progress of the A6 Intruder by MadMax. http://www.virtualnavairops.com/forum/general-discussion-ready-room/1884-what-your-donations-paid.html#post10641

In the RNZAF when I was there (early nineties) it was 2000 candidates apply to the recruiters for pilot training every four months and around 16 would be accepted for the officer's course, lose a couple on the officer course then some would be commissioned (ground officers), some would go to university first, and the rest to flight school. Maybe 4 would graduate flight school. Everyone was trained to fighter pilot ability and got some A4 time (hence the very high standard) - it is a shame our F-16s were cancelled (change of government to a more 'dovish' one at the time) since we could have fielded a lot of good pilots for them. All our best pilots went to the helos and strike squadrons if they chose to (and the squadron accepted them). Others went to transport and maritime (P3 Orions). We might have have amateur gear but the pilots were very good. The Aussies have similar high standards and they now have the SuperBug. RAF is also quality. Israel's standards are also very high, and they have a pilot relegation system so only the best performers stay in the best squadrons (if you snooze you lose). Point is, every country has different standards. So be careful sneering at the rotorheads as "not good enough to make fighters". I know of some guys who flunked the RNZAF pilot training but ended up flying Tornados in the RAF. This doesn't mean the RAF is worse, just that different air forces empahsise different things and having the best or most gear doesn't automatically mean all your pilots are better. As always, each air force has a distribution of proficiency levels, with some distributions being shifted higher than others.

What can happen is that if the CPU cannot feed pixels to the dual cards fast enough one will go to low power mode. The other card will do a lot of work and then once in a while the slow card will be tasked with drawing a frame, but since it takes a little bit to power up from power saving the frames take a little while to render. This means that things run a quite smooth and then the frame rate drops a for a second before climbing back up. This mostly affects dual ATI cards with recent version of the powersaving software in their drivers. Not likely to be your problem but something to keep at the back of your mind (just in case Nvidia has the same problem in SLI). Progressive loading of a scene causes some stutter and initially low-res tectures etc when you're first in the cockpit. After a few seconds it should be ok though. Is your disk drive fast enough to stream the high-res textures when needed? Again, maybe not your problem but something to test and eliminate as a possible source of problems. Are you rendering a lot of frames in advance? I forget the setting but some drivers anticipate scenes. At high frame rates humans perceive the smoothness more than any slight positional accuracy so this technique can be useful. However, it means you multiply the number of frames rendered by the card by a factor of 3 or 4. Also, have you tried turning your anti-aliasing and anisotropic filtering down to the minimal level. These re-render the scene several times (although the real effort is usually determining which polygons in the world are visible scene and projecting them, while converting the polygons to pixels and lighting them is not usually as expensive, so this may not make much of a difference). Note that LockOn can only use 1 core for the game and an additional core for sound. So having four cores only helps in that any other processes your have can run on cores 3 & 4 (maybe). Otherwise the quad core doesn't make any different to LockOn compared to a dual core. Arma2, however, will love all your cores (and hopefully DCS:A-10C might find some way of using another core, but then, maybe not). This means your CPU upgrade is going from 2.4 GHz to 2.66 GHz, an 11% increase in clockspeed if we disregard any CPU architecture effects (which might bump it up a bit more). That might not be enough to fully utilize your pair of graphics cards with LockOn (although your other games will go faster). Clearly something else is going on as even if you don't expect to get very much faster you certainly don't expect to get a lot slower (although perhaps you now have everything at 'max', which is expensive for clouds, water, and viewing distance). What speed is your RAM running at? This can make a big difference to LockOn.

Here's the Microsoft flight home page. Just some marketing spiel at the moment. http://www.microsoft.com/games/flight/ The video looks like it was a non-realtime demo (as is often done for games these days - especially console games). Eagle Dynamics is one of the few companies honest enough where the real game is used for the demos.

It is good you use that procedure Krebs20. In real-life checks a pilot checks for "full and free" movement of the control surfaces before they take the runway (since a stone could have got lodged while taxiing, for example). When flying dual we'd call "knees and balls!" so our second officer/flight instructor knew to give the dual stick plenty of room.

Hi Ali, Unfortunately it won't work on regular servers that require 'pristine' installs of LockOn eg. 104th. I've got it scheduled to document step-by-step how to have multiple side-by-side LockOn installs that can be used to run incompatible mods (for example EFA will not work with VNAO). Unfortunately such clashes are inevitable due to the design of some of the LockOn LUA files that use running indexes for table item identifiers rather than order-independent identitifiers (although some of the Lua files do it properly). This is a well known-problem when dealing with databases (albiet in Lua files in this instance). Long term I'd like to merge the EFA and VNAO mods (including the country mod etc) so that a single mega-mod install would sort it out painlessly for everyone - but don't know yet when I'll get time to do that. So, the VNAO mod can only be used on the VNAO Dedicated Server in the USA and on stallturn when it is running the VNAO mod (it occasionally runs the EFA mod too). Cheers, Moa

> That's before we start on logistics modelling supply line management etc. A very simple system is all that is needed in the first version. This is where you cut corners to get something out. > Or - make it easy for you clever guys out there to create one. There has been some improvement in FC2, as well as some regression. Fortunately ED are very receptive to suggestions. I'm putting something together for public comment in the hope we can send a coherent and comprehensive list of suggestions for ED to consider. > Dynamic Campaigns are massively under rated. Its the only thing lacking in my opinion. Dynamic Campaign and the ability to add new cockpits (allowing true multi-role) I'd say are the biggest things at the moment. These are clearly non-trivial to do.

CAT_101st, I apologise unreservedly. I did not know you had dyslexia. > You should see Cat's missions, we have to fly backwards! Extended 6DOF mod is required just so you accurately fire flying in reverse! LOL! I did not mean to cause offense and I'm very relieved that CAT_101st is philosophical about it. > J/K Cats a good guy and great company real or virtual. Its just not cool to go after grammar on a board anyways! If bad grammar bothers anyone that much the last place they need to be on is a BOARD LOL! I have no doubt Cat's great, and I did not mean to imply otherwise. However, it is a common courtesy to attempt to spell well (unless you have extenuating circumstances like Cat) and the defect density in Cat's post was so high it seemed something wasn't right (usually it is sloth but in Cat's case it is a perfectly legitimate reason). Sometimes a bit of prompting can cause the willing to progressively improve their writing (heaven knows it has helped me), and my intent was for a positive outcome. So, apologies to all for being uncool (honestly, you wouldn't have heard a peep from me if I'd known about Cat's condition). Again, no offence was intended to anyone so I regret any was taken. If you re-read my original post it was meant to be a gentle correction in the hope of improving someone's standards, but clearly I misjudged it as it was mis-interpreted by all who read it. The lesson learnt was by me :) All the best, Moa

The VNAO Flaming Cliffs 2.0 mods are now publicly released. You can download them from the VNAO recruiting page: http://www.virtualnavairops.com/forum/vf-101-grim-reapers-join-vnao-here/1879-welcome-new-pilots-heres-what-you-need-get-started.html Please remember to make a backup of your LockOn installation (copy your LockOn install directory) before installing these mods - just in case it conflicts with any other mods you may have installed. Further enhancements to this mod are being planned (new aircraft, possibly A6 for example), there is more to come. Meanwhile, credit to the VNAO mod team: VF-84_MadMax skins, coordination VF-143_Wraith flight models 59th_Jack skins VP_Blaze aircraft meshes VBA_Racer aircraft meshes SkyPat ModMan 7.3 installer Enjoy a change of pace with navy operations!

Blaze, I'v always find the ED team to be exceedingly helpful. Is there any chance you misconstrued their message? For example, the fact that the variables have complex interactions that are not simple to predict rather than them having no effect? I used to think changing the variables had little to no effect but found out I had to be careful to always re-load the game or cached values would be used. I'm not saying you are wrong at all, just that it is easy to think adjustments don't work if the old values are cached at program start-up (this didn't used to be required in FC1). nb. The encyclopedia information (with weights) is located at: BlackShark\data\scripts\Enc\Plane/<aircraft.txt>

The trick for the dynamic campaign is to leverage technologies that make it easier: * XML, since XML to object conversion is far easier (eg. JAXB) than parsing LUA tables (I did this in lottu) * Relational databases, * Java, much easier than C++ (and more portable than C#, which is derived from Java anyway), plus the compiler helps you a lot (unlike LUA where it is all trial-and-error to get things to work properly, painfully slow to develop in). Using these the 'war' can easily keep track of the ammunition expended and objects destroyed since most of the heavy lifting is done for you. The stats program I'm halfway through parses the results of battles (debrief.log) and already puts this in the database. It is one more step to modify the model of the world and another step for a mission generator based on that. A lot of work certainly, but not years (the bulk of my stats work for FC1 was dealing with missing/unreliable entries in logs which is now mostly fixed in FC2, but the FC2 work is correlating events since the log information is scattered between the network log, debrief log, and mission).

Here are some tips for future reference: "desiners" is actually spelt "designers" "disapering" is actually spelt "disappearing" "aquire" is actually spelt "acquire" "Iron fist" is usually "Iron Fist", since it is a proper noun "Pic." should be "pic." since it is not a proper noun (its a pro-noun in this case) "groop" is actually spelt "group" "Ocrap" is usually spelt "tension" (maybe "oh crap!" in crass company) "diffrent" is usually spelt different "waist" is usually spelt "waste" for the case you are using it in "Vickers" is an English aircraft weapon manufacturer, the Russian weapon is rendered "Vihkr" in English. Everyone makes spelling mistakes, so no problem, but you might want to consider re-reading your posts to check for errors - particularly if you don't want your post to look like a drunk lolcat wrote it. Native english speakers can translate but poor spelling makes it unnecessarily hard for people from other countries where english is their second (or third, or fourth...) language. Apologies for being a 'grammar nazi', but real pilots can read well, spell well (write an ambiguous order and people die), and do a lot of (basic) maths in their head (while flying). Something worth working at in the real world for everyone.

Hi EvilBivol, In my earlier post I said the logs were inadequate as they were not self contained. Consider the following log from stallturn, that I've been working hard to make into a real-time stats system (and thence to dynamic campaign): {t=27217.660, type='takeoff', initiatorID=16863745, initiator="Pilot #41", initiator_country=2, place="Batumi", place_id=5000023,}, So, we have: 1) time since midnight. Useful so we know daylight conditions, but no reference to absolute time (required for coordinating stats from multiple servers, and correlating events in the network and debrief logs). Would be nice if we had an ISO 8601 timestamp *as well* (and UTC is best). 2) initiatorID: some non-deterministic number depending on when you entered the mission. Slightly useful to determine when a player joined an aircraft for a particular sortie (that is, distinguish between uses of "Pilot #41" by different pilots that occupy the aircraft at different times). 3) initiator: Pilot #41. Hopefully unique within a mission (I think this is enforced). However, is isn't the useful value, which is a player's callsign, although it is useful if bot stats are tracked (good for simulation statistics where bots fight bots). You can determine the callsign by either modifying LockOn (the net scripts) which means you now must parse the debrief and network logs and correlate entries) or by parsing the complex mission file. Breaks if a mission is altered and then saved with the same name (quite common for small adjustments). 4) place="Batumi". Just what is needed. But where is the information about whether Batumi is a friendly or hostile airbase relative to the player? The side of the player is known (by parsing the complex mission file as well as the debrief log) but the side of places can change due to triggers. If a player lands at an enemy airbase they should be considered captured and penalised for giving the enemy a working aircraft. This case can only be determined by modifying the net LUA to place a marker in the debrief log. So, stuff can be fixed, but only by correlating three files (even though by default there is no correlation timestamp common to all) and modifying LockOn scripts. This is not a good situation IMHO. This is only the tip of the iceberg of the problems I've found while parsing the logs. I have a lot more I'm willing to share if you would like to hear. Is this a problem? well, consider a lot of players independently made stats systems for FC1.12 yet there is only a single very simple system in use for FC2 (by RAF I think, which probably counts events as they come in), and there are only very simple ones for BlackShark. My own system adapted from FC1.12 is taking a lot longer solely because of the problems introduced into the logs in DCS. Proper statistics requires being able to correlate multiple events to determine the order things happened in to distinguish between cases - but as I've said, that correlation value is not in the unmodified logs. However, the FC2 logs do have better information than FC1, it just requires parsing the network file, debrief log, and mission and modifying LockOn to try piece the missing information together (even though the debrief log and network log use different time stamps; one relative to midnight, the other to mission start, which can be arbitrarily different). As I said, if you would like a PM stating what could be improved in the logs from an integrators point-of-view please just say the word. Otherwise, "begin with the end in mind" would go a long way - try using the logs yourself to get statistics (without modifying LockOn/DCS in any way since integrators should not be required to do that!) and you'll quickly see what I mean.

> ed could skyrocket their sales by introducing a dynamic campaign. and dont tell me about complexity. I am a software developer myself. and though its complex and needs some work its far from impossible. Not impossible, but very hard to do except in LUA. I've trying to build stats and a dynamic campaign in Java (I want strong typing to catch bugs, good free tools, and to use all the cores of my CPU - LUA is a dog in this regard) but the logs produced by ED are not self-contained enough to do this without a significant amount of extra (and IMHO, unnecessary) work to correlate events in different logs and the mission file. In the end you must modify LockOn itself to achieve this (I just had a big rant about how poorly thought out the DCS/LockOn logs are on the 104th forums where my work will be used for a real-time player stats page). So, not impossible, but made unnecessarily complex by information (or lack thereof) being placed in the logs. Once you can do stats you use that to modify the database of units in theater as the mission progresses. Then you need a mission generator to determine the progress of the war and create the next mission for players. Straightforward (once you're out of the Lua quagmire) but still a large amount of work. The 'campaign' system in LockOn at the moment is a very low fidelity war simulator and very labor intensive (all mission variants must be generated manually - which is exceedingly time consuming). Machine generated campaigns with realistic scenarios are what is needed.

You're incorrect. I wrote some software that did real-time histogram equalization of video images for scientific work. Even at very low light levels you still got essentially the same picture apart from being slightly 'grainy'. Then all of a sudden, the light was so low you got no signal at all. Without the equalization it looked very dim (nearly black). Same goes with saturated signal, you can't tell a difference in the picture until, wham, whole image was saturated. In fact, the histogram equalization worked so well I had to enable users to turn it off so they could visually judge the amount of light illuminating their subject (for best signal/noise) - they just couldn't tell with the image processing applied. I won't even get started on when we used image intensifiers that could count individual photons (although we were using it for microsecond shuttering). Early LLTV might suck but recent stuff (and the computing power for additional real-time processing [this was 2005]) is amazing. One time (1991) when I was in the RNZAF we got a flight on a P-3 Orion and I mucked around with the thermal imaging. It was pretty spacey, you could see clouds in the dark, see metal ribs of the aircraft through the wing skin (different cooling), see cows easily from 10000 feet, and even see the vapour of the air flowing over the wing (it changes temperature with the pressure) that is otherwise invisible to your eye. You've all seen YouTube of Op Iraqi Freedom an Afghanistan sensors, well they were pretty good two decades ago as well.

Very unfortunate - sob :(