Scaley

Yes indeed - a lot of these systems have real world performance that falls somewhat short of what they can deliver under ideal conditions, and what the manufacturer quotes!

The era of system we have modelled in the DCS Hornet would be picking up anything moving that's above the filter speed. In an urban area with civilian traffic it would be totally useless. There are other systems around that have a library of radar signatures and could attempt some filtering for specific contact types. The Longbow radar on the Apache, for example, will attempt to categorize things as wheeled, armour, tracked, artillery, etc based on radar signature. That, however, is a millimetre wave system (higher frequency than our radar) so has better spatial resolution to be able to pick out details on the targets and then match that against it's database.

Well it's been moved here, but not marked as reported, so I guess not formally acknowledged yet. The Hornet display export code has been "different" from release, so I don't know if ED will call it a bug or simply work in progress...

Phil, The Hornet DDI code is a mess at the moment. Sometimes this can be fixed by making sure your total rendered DCS output does not exceed 1440px vertically (so telling windows your export monitors are to to the side of the main one) and then laying out the export viewport to match that. Could you by any chance post your monitor setup lua file from saved games? I ask because your DCS is rendering out it's export viewports using different code to my DCS, and I am trying to research how DCS decides which set of lua code to use to describe the exported viewports.

So just a note for ED - this has been moved to multi-monitor, but the bug ONLY affects the Hornet as far as we know.

I'm getting the same bug. The problem isn't that the bloom at night is rendered twice, but seems to be down to the rendering intent (or purpose, as the DCS lua calls it). When you export a DDI it changes the "purpose" of both the exported display AND the one in the cockpit. What is supposed to happen is that only the exported display has different settings applied. You can verify this by changing the brightness settings in: mods/aircraft/FA-18C/Scripts/Multipurpose_Display_Group/common/indicator/BAKE/MPD_common_bake_init.lua and see which set of values are being use by each display. Edit: Added Also of note - the way the DDIs are rendered changes based on the width and height of the DCS main view window. By modifying "vewiportHandling.lua" and removing rendering purposes it's possible to get correctly rendered DDIs on EITHER your exports OR your in cockpit displays. However, if you then swap from a vertical screen layout (one above the other) to a horizontal (side by side one) then all the displays (both in cockpit and exported) disappear. Having spent about 14 hours now over 2 days trying yo chase this I can't make any sense of large parts of the lua that you can remove/edit and seemingly have no effect. The best current workaround I can find is to change lines 81 - 84 of ViewportHandling.lua to: purposes = {--render_purpose.GENERAL, --render_purpose.HUD_ONLY_VIEW, --render_purpose.SCREENSPACE_OUTSIDE_COCKPIT} render_purpose.SCREENSPACE_INSIDE_COCKPIT} such that you only get your displays on you exported screen and not in the cockpit at all.

DCS's logic functions (AI, mission editor, etc) all use "true" altitude. That is, the vertical distance from sea level to the object in question, measured from the sim engine directly. This is a number that has no real-life equivalent in aviation because it's normally impossible to measure. This is the altitude shown in external views in the bottom info bar. It is also the altitude reported by DCS to external tools like TacView. What you see in the aircraft depends on altimeter pressure setting, air pressure, air temp and anything else the aircraft module designers have modelled (so may or may not include instrument lag, compression effects, etc). In addition, since you can only correct most aircraft altimeters for pressure and not temperate gradient, your displayed altitude in the cockpit and DCS' "true" altitude will diverge more at higher altitudes and when the air temp is further from ISA standard (15°C) This is a known thing (bug?) and causes lots of odd effects such as AI tankers reporting slightly not-right altitudes, HUD altitudes not matching TacView, etc If you want to see the effects start at an airfield on a day with temperature far from 15°. Set you altimeter to exactly match the F2 view reported altitude, then climb to high altitude and observe the difference between what's in the aircraft instruments and the F2 view. Compare with Tacview and see what was reported during the climb.

If you are trying to make sharp turns in HI a little asymmetric brakes (on the inside wheel obviously) also helps reduce side-load on the nosewheel and reduces the chance of it just slipping sideways.

I'm using a 21.5 16:9 touchscreen for Helios. It's got all 3 displays, the RWR, UFC and some other stuff. Fits comfortably. You would probably get away with a 17' widescreen if all you wanted was DDIs and MPCD.

Radius fight, minimise time to first shot and take a high PK shot as soon as possible. Against a single bandit I'd take a 2nd shot even with the first missile still in flight. As Mike says you get one chance since you are pretty unlikely to be able to win any sustained fight against a Tomcat. You should, however, EASILY be able to be the first to be in a position to shoot, even without 9X. You have so much more available instantaneous rate, and a much smaller radius, that you can use it to your advantage. Make sure you enter the fight in an efficient instant rate band (350-400kts)

There are loads of threads reporting this, some have been previously marked as reported, and some threads not. The fix I'm currently using is here: https://forums.eagle.ru/showpost.php?p=4425284&postcount=46 It would be good to get one of the current threads marked as reported though...

This is known problem in DCS. As you close in on the aircraft the LODs change and the high-contrast shadow rendering at distance (that makes things visible) disappears. Unfortunately this happens further away than the high detail shadows start rendering. This leave you with a range band in which the aircraft is rendered with no shading and thus is essentially contrast-free. If the background is a similar colour it will appear to have suddenly disappeared. One trick solution (which sounds totally mad but...) is to zoom you view OUT a lot. This changes the LOD rendering and will give you the shading back on the aircraft and thus enable you to regain tally. I know this sounds silly, but if you try it a few times you'll probably work out how to get it to work.

As to the original question - my understanding of the RL Hornet docs is that you shouldn't be able to sideslip by cross-controlling the aircraft since the FCS logic will override either the stick or pedal input. It's interpreting the control inputs as a pilot commanded roll and yaw in opposite directions. The larger magnitude input should essentially "win" and you just get one effect, either the roll (stick) or roll+yaw (pedal)

Anyone wanting to correct the HMD independently it's definitions are in the main fonts.lua in the scripts root.

Not sure this is intended. As Swift has said once you designate a target using WPDSG then any TOO JDAM you select should take this as the TOO Target. Whether you have the MSN page displayed or not should not make any difference, but it may do in DCS. As like Swift says - they are not all getting the target at that time, but as you drop each one the next one is selected, and if there is a target designated (via WPDSG in this case) then it gets theses coordinate. This is the correct behaviour. Either that, or you need to use WPDSG after the last bomb has left the aircraft.

Could you elaborate on this? Is there a way to get it to work currently?

For exported displays I use the ReShade application: https://reshade.me/ You can set up a mask so the post-processing effects of reshade only affect certain areas. Using that I have MASSIVE brightness boost set to affect the monitor with the exported DDIs on (Gamma 7 from memory). That makes them readable again.

Still broken in 2.5.6.50979 Single Player Multi Player No Mods. No other triggers or objects in the mission. It would be good to get an idea if this is likely to be fixed, or even if a fix is possible with the current MP code.

Is anyone aware of a way of getting this thread moved to the main bugs forum so someone from ED might see it.

This seems like the current version of the "going on forever" debate about how easy/hard it is, and should be, to visually acquire and track aircraft in DCS. I'm purely in this thread because I've been wrestling with this problem (as I know many others have) for years, and today I think I have come across a work-around. It's not an especially good one, and not especially pretty, but for me this has enabled me to fly BFM effectively, without constantly losing visual on things less than a mile away. Before I go into details a few statements to describe exactly what I'm talking about: 1) I'm not interested in fixing how easy it is to see things very far away at the visibility limit. DCS does some funny things here, but for me they aren't sim-breaking problems. 2) I am VERY interested in fixing the problem I have (on a 34" 3440x1440 monitor downscaled to 2560x1080) that there are intermediate ranges at which air targets seem to "disappear". By this I mean that object may be visible far away, then suddenly become much less visible as they get closer, then become gradually more visible. This effect is well described, and has been fixed before with a community mod (back around 1.3x) that no longer works. This effect also happens differently, and in different range bands, depending on monitor resolution, and to a smaller extent zoom/FOV setting. Annoyingly on my monitor this range band is about 0.9 - 1.8nm, in other words exactly the range band that a loose BFM fight would be happening in... 3)This small lua edit I'm proposing is NOT intended as an ideal solution to the current problem, but it may function as a temporary work around for some people, as well as allowing people to experiment with settings, and hopefully provide feedback back to the ED team as they work on improving this area, which they clearly are based on previous posts and improvements we are seeing coming into the sim. So, the fix.... What seems to be happening to cause the "range band" of low visibility is that DCS swaps from rendering a very low level-of-detail (LOD) model of an aircraft to a proper 3D model at too high a range. The low LOD models are high contrast, and also maybe appear to have some form of dynamic/smart scaling built in. The 3D models do not... If this swap occurs too far away there may be sudden drop in aircraft visibility, and then a gradual increase as the 3D model gets closer and thus bigger, more detailed, and contains more contrast. This swap logic seems to be based on when the model (not clear which) is bigger than some threshold value, and this threshold value has a pixel dependence. This leads to the swapping distance being much further away on high-res monitors, leading to the aforementioned problem. In order to fix this we need to be able to adjust this LOD swap to occur when the visibility of the low LOD model is matched or exceeded by the visibility of the high LOD model, thus preserving the natural laws of physics and biology that as an object gets closer it generally gets bigger and easier to see. This ideal swap distance is resolution dependent at present in DCS due to the way the current rendering works. To do this: In graphics.lua (DCS World/Config/) You will find block of code for each visibility setting, currently line 147 - 244 Each setting has a block such as: High = { near_clip = 0.02; far_clip = 150000; --structures = {80, 16000}; trees = {1000, 12000}; -- looks to be obsolete --dynamic = {300, 16000}; dynamic2 = {300, 16000,0.5}; objects = {5000, 80000}; mirage = {3000, 20000}; surface = {20000, 80000}; lights = {200, 80000}; districtobjects = {300, 300}; districts = {12000, 12000}; lodMult = 1.0; lodAdd = 0; The two settings at the bottom: lodMult and lodAdd appear to change (each by addition or multiplication!) the ranges at which models transition from one LOD to another. Higher values of lodMult will give more detailed LODs at a given range. Inversely higher lodAdd appears to give LOWER lods at a given range. I am unclear if lodAdd is truly linear, since at some settings it can drop the LOD of your own aircraft model. By editing these settings one can adjust the range at which DCS switches from a wireframe/low LOD model to an aircraft 3D model. By tinkering with the settings one may arrive at a setting where the swap occurs as the visibility of the two models is equal, and thus there is no sudden change in visibility. Below is a video with the default settings (1.0 and 0) and then my updated settings (0.6 and 500). There are 3 runs at slightly different zoom levels (the 2nd run being my default) before the mod and 3 runs after. In all cases you can clearly see the sudden "disappearance" when the LOD changes, but with this mod you can control when this happens. I really hope this is of use to some people, and that we can maybe test and adjust this to help the DCS team improve this area of the sim. If anyone has any thought or comes up with any additional ideas it would be great to hear them. DISCLAIMER: This is not tested extensively. Back up your files and use at your own risk! For the avoidance of doubt - I will not be interacting in any way with the two well known posters who will no doubt shortly arrive to tell me that everything is fine because DCS renders objects 1:1 all the time and that provides perfect realism, or that my "technique" is somehow bad. Numerous well educated people have posted in these threads before with a multitude of data and resources describing various methods used, or proposed, to accurately simulate human visual perception on a computer monitor. One well posted method is in current and highly effective use in another PC flight sim near you... It should be clear to anyone who has ever tried to follow a flying object visually that the current DCS implementation does a very poor (although incrementally improving, especially recently) job of this simulation aspect. I have flown computer sims since 1988 in the commodore 64, and was taught my visual scanning technique by RAF instructors in RAF aircraft (at 150kts mind, not fast jet speeds). I also have a degree in bioengineering and have been taught and examined on human-computer visual interface and modelling characteristics. Sensible discussion and feedback is very welcome.

There was a bug thread on this that was marked as "Reported" but I now can't find it. The last patch did make some changes that appeared to slightly improve things but there is still a significant difference between the main viewport DDIs and the exported ones. At least now the brightness doesn't appear to change when the main view is switched between internal and external views. It looks to me like the core of the issue is that some post-processing happens to the main viewport images, such as to make them appear relatively very bright at night, and this post-processing is not applied to the exported images. Because of this sometimes the brightness matches quite well, but sometimes it doesn't, and that depends on the ambient light level in the sim. Two possible fixes would be: 1 - independent brightness control for exported DDIs/AMPCD, AND make them not affected by the cockpit brightness controls OR 2 - make them affected by the post processing the same way the cockpit ones are. Given that the old bug thread appears to have disappeared I'ma bit concerned that ED think they have fixed this with the last update.

I've had the same problem quite a few times but never found a fix. Thanks for the tip!

Well the cockpit floods on the A-10 seem to be fixed now, but we are still getting outside lights spilling over into the interior of the cockpit. Formation lights, some ground lights and other aircraft taxi and landing lights. I don't fly any other modules so don't know if it's been fixed elsewhere, but definitely not in the A-10

Just like people are saying above the key is often to get your head out of the cockpit and look around more. If you have spent a little time studying the maps and the area the mission will take place in you should know where the primary landmarks are like town, conspicuous hill and forests, etc As you enter a target area where you'll working try to identify those landmarks you have picked out from your map study and work out you orientation on the ground.

Anyone encountered any problems with this in 2.5?