Nedum

Is there y reason for that you are not sharing any screenshots? 1. There is no need anymore to force anything for DCS. 2. Did you ever uninstall every old VR stuff? 3. What's your OS? After several years of using old stuff, people forget that sometimes there are hidden settings which will even stay, after a software was uninstalled. Looks like you are running in a conflict with the setting of your old VR-System. Without a screenshot, it didn't happen!

Why is this thread still marked with "cannot produce"? All what's necessary, it's in the first posting. 1. English Cockpit. 2. Cannot set min. Radar alt. 3. After latest update. After 1 minute of "testing" with the above conditions, in any mission, I could clearly see, without the need of a trk file, that there is a bug.

Please, please, PLEASE explain to me why the pilot is not allowed to see which target is a system target when DL is switched on! Why has the army installed a system that prevents the pilot from getting an overview of the situation that he already had without DL on? All the funny pictures, and to this day no one can explain to me why the pilot sees less, has less of an overview, cannot see at a glance on the radar display which targets are actually system targets and how many there are? What is the reason for expecting the pilot to do more work and increasing the risk, thereby increasing the danger of errors by the pilot? What is the reason why, with DL on, it is not possible in any situation to see a “hollow” “yellow” square to identify which track is a system track? Which ROE prevents the pilot from seeing which track is a system track with DL switched on? I really want to understand the system, but no one can explain to me why, with DL switched on, the situational overview is restricted and deteriorates. If possible, explain what I have to do to see which target has become a system target, or isn't a system target anymore. Currently, there is no way to get this and no logic behind all this behavior! Actual behavior: With DL on, "help" the pilot with disabling parts of the situational awareness and adding some button smashing. Really? I hardly believe DL should work this way! Edit: And just as an aside, some of the image descriptions are incorrect! In the image with DL off, you can clearly see that one target is not a system target (third and fourth images from the top). There are a total of 10 targets, 9 system targets, one of which is bugged and one is just a tracked target! However, the next image explains that all 10 targets are system targets. How exactly can you tell? Assuming that while DL is on, additional targets are added that are tracked by the radar, how does the pilot now recognize which targets are not yet system targets? What happens if 3 of the previous system targets are not detected by the radar at the same time, and the targets visible to the pilot on the display are still 10? If all this happens while the pilot briefly looks at the HUD, how does the pilot recognize this change with DL on? How can the pilot recognize this important difference when both the tracked and system targets look the same, thick filled yellow squares? I have the feeling ED is unable to understand the issue! Edit 2: It's not a procedure issue! It's a bug!

Don't bother. You point out errors, such as the fact that with DL ON you can only set a single target as the system target, and you get the response that this is supposed to be a ROE problem that will be fixed with the implementation of DTC. The only problem is that the two have nothing to do with each other. If I turn DL OFF, I can suddenly make all 4 of the 4 detected targets to system targets at the same track timestamp with one TMS right short. For years, people have been trying to tell me that a function of the radar, not the display, is linked to the ROE system. Nice... no! If you look at the current function in the manual, you can't even begin to replicate what is shown there in DCS. To this day, no one can tell me why the ROE system should prevent you from seeing system targets with DL ON, or from distinguishing whether a target with DL ON was even detected by your own radar. I have rarely seen a more illogical system than the one offered by DCS. The entire system is unreliable and creates even more workload for the pilot. I would wager all the money in the world that the current DL and ROE system in DCS has nothing to do with the one in real life. A system (DL) that prevents the pilot to see all necessary Information on one blink and gives him less situation awareness as without? A dream must come true. Come on. Wanne see which Target is tracked? Hit a Button (IFF left, ones), and after that, switch back (IFF right, ones). Oh, you have lost the track, but can't see this? Guess it. We all know, guessing is the best way to rule the battlefield. And if you don't want to guess, switch every second DL on and off. Which pilot wouldn't love a heavy Button workout? Yeah....

I would suggest that you take a close look at the Task Manager to see which cores DCS is using and how high the GPU usage is in VR. In my experience, the GPU in VR is severely limited by the CPU. The maximum utilization of my GPU in VR is 86%, with an average of 78%. That's pretty low. You can clearly see that DCS only uses 3 cores, and at least one of them is at almost 100% utilization. Sometimes, but more by chance, I manage to distribute the load differently using the Process Lasso tool, so that no core is fully utilized anymore. Suddenly, instead of 56 FPS, I have 78 FPS (F16, Instant Action, Afghanistan, Cold and Dark). Unfortunately, I haven't been able to figure out exactly what I need to change to achieve this. It's pure coincidence every time. The fact is that the FPS changes dramatically with the CPU load, completely independent of how high the CPU clocks. In 2D, with only the CCD1 (without cache), at 200 MHz more base clock, I get 30% less FPS than when both CCDs or only the one with the cache (CCD0) are running. I'm pretty sure my observations show that the problem lies in how the DCS EDGE engine manages the cores. This behavior has only become more apparent since a few updates, as if something in the core engine has been changed and the CPU core, which is also responsible for the GPU, has to deal with much more than just GPU communication. Perhaps in preparation for the dynamic campaign?

The CCD without the cache (disable CCD1, not CCD0). If you use Process Lasso, there is an option for this ("without CCD"). If you disable the one with the Cache, you will get the slowest FPS ever, even so the CPU is running with a 100+ Hz higher frequency. It's all about how the EDGE engine can handle the Cores. The 9950X3D alone, without any changes is faster in VR as the 9800X3D but 5-10 % slower in 2D (Monitor). Most maps are 99,99 % CPU limited in VR. I am always talking about near ground game play. I am always testing it with the F16, Germany Cold War Map and the Afghanistan Map, Cold and Dark.

I've tested everything again. F16 + Instant Action + Germany Cold War Map + Bombing Test. The mission starts with an F16, hot on the ramp. All systems are ready for takeoff. No system needs to be touched by the pilot anymore. Flight time to the target, including taxiing and takeoff, is less than 3 minutes. Nevertheless, all bombs fall about 100–200 feet short. When I perform an A-CAL (RALT, WP 3) after takeoff, all bombs hit the target! Anyone can see that something is completely wrong. Mission temperature 40° C / 104° F, no GPS is active. The Trk file is the mission itself!

Oh, sorry. I meant feet, not meters. The Jet is hot on the ramp at mission start. I think that mean SALT input shouldn't be needed anymore, but I will test it. Flight time less than 2 minutes. So no A-CAL needed too. Thank you, that make sense.

So the navigation coordinates would always shift with the flight direction? I don't think that INS and GPS work this way. If so, that would mean, depending on the flight direction, the coordinates would move. Never saw this behavior. If so, then if you fly a circle around an STP, the STP would have to circle too. Na, I don't think that this work this way.

The interesting thing is that the impact point itself is quite precise, regardless of the map. The only problem is that it ranges from right on target to several hundred meters too short, but >>never<< too far to the right, too long, or too far to the left. If this were actually due to GPS or INS errors, then the impact point would have to shift depending on the direction from which the target is approached. But the impact zone itself would always be in the same area. And that is not the case! CCIP already worked when such good INS and GPS did not even exist. As far as I know, the impact point with CCIP is calculated completely independently of INS and CCIP. Oh? And I thought dump Bombs are called so, because they have no intelligent systems on board. Never heard that has something to do with how smart the plane is. The question is, why did it work until six months ago and now it doesn't? Suddenly CCIP is dependent on INS and GPS drift? I would believe that if the point of impact also shifted depending on the approach direction. Then, regardless of the direction I'm approaching from, I would have to set all impacts in the same area. So sometimes too short or too long, or too far to the right or left, but the center of impact would have to be close together. Only then could one assume a dependency on one or both systems. Yes, that can help, but it doesn't explain, why it's always too short and never too long or too far left or right. Everyone with the F16 and the Germany map can test it. There is NO Track needed. TOT < 2 minutes! If we get any relevant INS drift in this short amount of time, we have a bigger problem than CCIP bombs falling always too short.

Is the issue with the CCIP "Dump Bombing" known? Since half a year, all "Dump Bombs" hitting a way too short if I am using the CCIP Mode. How far to short depends slightly on the dive Angle. The interesting part is, it differs from map to map. Caucasus: I can hit spot on (Instant Action, Caucasus, Free Flight). Germany: always 100+ feet too short. (Instant Action, Germany, Training Bomb drop).

For me, the biggest issue with DCS and VR is the EDGE Engine and the poor Core utilization. In VR, 99 % of my time in DCS I am CPU limited. The EDGE Engine is unable to switch the workload, even if some of the Cores are idling. I was switching from a 9800X3D to a 9950X3D 5 days ago. I was testing all the setting with Process Lasso. At first, the 9950X3D was slower if I was only playing 2D. In VR, the 9950X3D was surprisingly as fast as the 9800X3D. The CPU frame times were lower. It felt smoother. The reason why was, DCS was using both CCD of the 9950X3D. So I disabled the CCD1 without the 3D-Cache. And at this point, both CPUs are equal fast in 2D, but the 9950X3D was even faster in VR as before. At the end, I've raised the FPS (or lowered the frame time), with disabling the CCD1 with the 3D-cache by 10% in 2D and 10+ % in VR. But that's not the interesting part. The interesting part is the CPU frame time is now 50% lower! The whole Gameplay is much smoother. How the DCS World Engine is interacting with the Cores of each CPU is totally different. On the 9800X3D DCS is using the 3., 5., 14. and 15. (15 is a virtual Core) Core. On the 9950X3D DCS (@standard) is using the Core 1., 8. (CCD0) and Core 30 and 31 (CCD1, Core 31 is a virtual Core). If I am disabling CCD1 (without 3D-Cache), DCS is using Core 2 (virtual core) 14 and 15 (virtual core) the most. Core 1 is used a little bit by DCS. @ the end, it's all about the EDGE Engine, which is unable to use the Cores of "modern" CPU in a good way. It's not PIMAX, it's not us, it's all about the DCS World Engine! As long as a 5090 is limited 99 % of her time by a 16 core CPU, there is something strange going on with the Game-engine! I hope we will get Vulcan support soon.

The questions that arise are solely the following: 1. Do the displays in the HUD actually work differently? If so: 2. Why should there be a different mode of operation depending on the orientation (vertical or horizontal)? I would like to have these questions answered, because these are the questions that are really important! What is the logic behind the RADAR alignment indicator being displayed in horizontal alignment with the nose of the aircraft, while the vertical alignment is displayed level with the altitude? What could be the reason for this? If the RADAR antenna indicator is actually supposed to show the alignment of the antenna with the object, the current vertical display would of course be incorrect. It doesn't make sense for that reason alone, as the pilot needs to be able to see when the RADAR will lose contact due to the angle to the object. This is currently not possible vertically. So what is the purpose of this cursor? If the answer is: “To be able to recognize in time when the tracked object will leave the maximum gimbal range!”, then the current display in the vertical range is >>incorrect<<! To recognize this, all it takes is simple logic, and nothing else!

He was writing one can start the engines without a running APU and without ground power. How does that work?

Would you please explain, why the DCS MIG 29 is the only DCS 4th gen fighter with such a weak Landing Gear? Why does the "weak" DCS F16 Landing Gear not suffer from the same "weakness" as the Landing Gear of the MiG 29? If we compare, then please in the right way! If a DCS F16 Landing Gear doesn't break if I ride several hundred meters over the grass, why does a DCS MiG 29 get a broken leg from only touching the grass with its toe? One is for sure! The current Landing Gear of the DCS MiG 29 is much, much, much too weak in comparison to the Landing Gear of the DCS F16. A blind man should see this! If the behavior, the weakness of the Landing Gear from the MiG 29 should be ok, and so be the new reference, I would really like to see how all the other Landing Gears would behave in relation to this new reference!