darkman222

I am no programmer. But I think the real struggle is to add something without breaking another thing. Thats what this early access thing is all about. On the one hand , cool for us customers that we can be a part of the process and maybe point issues out to ED before the final release. On the other hand the end user is suddenly involved in a process only a few years ago no customer ever had any insight before. To communicate this by ED to the customers is a struggle itself. It makes kind of sense that the "lock" tone comes just when almost all of the radar modes are finally modelled. I imagine it as a railroad track that was already there but the switch to it was only missing. And that goes for all the development involved in every DLC.

Exactly. But it was even worse a few updates before Kudos to ED working on it.

...why do I have the sneaking suspicion that it was a perfect clever move by ED letting GS relase a teaser video and see what the upcoming discussions about the new FM are gonna be.... I really dont know if you can call it complaining about the F16s FM when the outcome of dogfights in the F16 differ drastically from the expectations you'd have from the real world. Sure we are no pilots without real world experience. But this is a simulator based on real world data and not star wars squadrons with fictive aircraft with much room to argue about what to expect from a specific aircraft.

I did not follow the entire conversation but what I think is that the virtual DCS pilot should be able to sustain 9G or what ever Gs as long as necessary for certain aircraft specific tactics to work. You can look up the caveat manouver for the Viper. It consists of multiple lead turns and slowly gaining angles merge after merge. This only works if the virtual pilot allows for it and what real pilots train for.

Dont forget: You wont be able to join a lot of servers with the Tucano or the A4. FC3 aircraft are really cheap and official DCS aircraft.

They have not talked about that, but I was expecting that this needed to be tuned as well. Aparently they did and had to do it too.

GS does these videos for entertainment, sensation and clicks. What more do you expect? Maybe the Grim Reapers will do a more in depth comparison when the fix is rolled out. Anyway. That fix is a long awaited thing and if we finally get a viper that can be flown, and fights can be won, like it is taught in public available documents, I will be more than happy. Looking forward to finally outrate aircraft the F16 should be able to outrate and not ending up running away, extending and resetting the fight just 5 turns after merge.

Growling Sidewinder likes to have G effects off...

@BIGNEWY I watched the track @Das Feuerposted earlier in this thread and it looks pretty much like the issue I am facing in my track files, but he managed to reproduce it in SP too.

Here are 3 trackfiles of the network radar lag / misalignment bug. The target designator box lagging behind the bandit and dropping lock. Tracks are from the latest DCS Version DCS 2.7.10.19473 Open Beta - 07.02.2022 - no mods (except tacview) installed. Download: https://www.dropbox.com/s/xewovmzsbv8zopv/20220301_radar_lag.zip?dl=0 radar_lag_01.trk - happens already in less then 2 minutes since joining the server. I have never encountered this issue that early. radar_lag_02.trk - although at longer range, but interesting how the target designator box keeps jumping and trying to stay on a already correctly locked target. ( 12 mins in track file) - you need to have labels enabled and use high quality settings in the video to see the bandit radar_lag_03.trk - just another ACM lock failed due to the issue. ( 12 mins in track file) For easier reference, see this video too: Sorry for double posting on this issue @BIGNEWYBut I really wanted to make sure you are not missing this. Because it takes a lot of time and nerves to collect those track files. And I think I cant do any better than this. Please note "radar_lag_01.trk" shows the issue after 1:50 min in the track file. It wont get any better than this. Final thoughts: It seems to happen less on the "justdogfight_caucasus_v2.7c" server which is located in greece, compared to the "mobettameta's dogfight arena v1.33" server which is located in the US. I am located in Germany. Maybe that latency comes into play here too. Thanks again for looking into this issue.

This is not very helpful. You play a lot MP and SP like all of us, okay . But do you play a lot of close air combat dogfighting or long range BVR? Chances you run into it in BVR (more than 12 nm) is very low, and to run into in close air combat ( less than 2 nm) is very high. Can you jump in on, for example, the "DCS dogfighters" server, go to guns only area for 30 minutes and NEVER run into that radar locking issue?! The idea that this is a network related issue might explain a lot of the nature of the issue. Thats why Wags renamed this thread accordingly I guess. I suspect the issue to happen as follows: There is a lag in transmitting the position of the bandit aircrafts position to the client F16 radar (= my PC). In BVR in a distance of 12 or more nm distance the radar of my client F16 has the chance to compensate for the wrong transmitted position because the offset in time does not reflect a big change in angle off of the bandit to my client F16s nose. Maybe 1 - 2 degrees. So that is what I happen to see sometimes that the target designatior box makes quick correctional jumps. From behind the aircraft that I am about to lock, forward to its actual position. When it fails, it always tries to lock on a position the aircraft was in the past first, which is behind, then corrects jumping forward. If the lag happens in close air combat and the client F16 radar wants to compensate for it, the angle off the nose the bandit aircraft has travelled in the mean time is maybe 5 or even 15 degrees. So the compensation algorithm just does not not find the aircraft it should lock on. So the relation seems to be: The closer the bandit I want to lock on is, the highter the amount of distance he travels angle wise in front of my aircraft in a shorter amount of time. So the higher the probability that my client F16 radar just does not find the bandit I want it to lock any more, because the information it has of it is later in the past and the real position too much off, that it cant compensate for. Dos this make sense @BIGNEWY? I dont want to bring up old stuff, especially because this is from Aug. 2021. But as the issue persists, this was a video where I pointed out the target designator box correctional jumps I encountered. Maybe it is obsolete, please ignore it then.

Okay. Thanks. Good that its not flagged as "correct as is" again. It might be a MP issue, or it just might be on some servers or just for some people. But as long ED realizes that this actually is an issue (happening for what reason ever) its a good step forward for people frequently encountering it. If I run into a good example, on a MP session I'll post it. Thanks @BIGNEWY

JHCMS should be aligned as long as I dont miss anything that needs to be done when spawning mid air. This is not about how to align the JHMCS. That jet is hot, spawning mid air and should operate as expected. And really nobody needs a tutorial how to switch on ACM boresight mode point the cross on another jet in front. I am not using mods. I would love to reproduce it in SP but this involves a lot of setup in the mission editor, which I clearly dont have the time and competence for. This is why I posted the videos together with the tracks, that you can see the pattern how it happens and when. Understand that if I just posted one event when it happened it would have been flagged as "correct as is" quickly. Nobody would doubt the radar is not fail safe. But under real circumstances (MP gaming) it fails too often (compared to other jets). Thats the point here. If you are like me or @SCPandadoing a lot of dogfights, you can run into that situation the first dogfight in the first minute, but you sure will run into it the following next 10 minutes (see the time stamp in the video) I can spend 3 hours or more now to try to reproduce it in a set up SP mission and fail, or I can just join the server and have that issue almost instantly. I dont play SP btw. But I remember there was another user who had it happen in SP too. But maybe its a MP only thing. I dont know, its a valid question. Maybe MP is throwing something off. So ACM modes might be working well in a clinical text book situation (AI bandit flying in front) or even if you want to reproduce it when an aircraft is crossing the nose, it might work in a set up mission and situation with an AI aircraft flying perfectly. But where it simply does not work is where it should. In a MP dogfight with aircraft just not flying testing parameters which other DCS aircraft manage to lock but not the F16.

This is my last attempt posting about ACM modes lock behavior, because I still have collected those track files and I still believe that this unreliable behavior cant be correct to this amount in the real F16. If it is correct, then my question is, why dont the other aircraft show this behavior (Plausibility question) in that pronounced manner, which gives a big disadvantage only to the F16 right now. Especially because you need to rely on pulling the bandit in the HUD, while locking him before, and get a guns solution running on him. That also takes a while to calculate compared to other jets, which in combination, again gives the F16 a disadvantage that I still cant believe is so severe in the real jet. Also because the F16 is designed to use that technique in guns dogfighting. But at the moment youre too often just chasing the bandit to get a lock instead of a guns kill. This is really frustrating because in the first 2 video clips you see the bandit was not moving much in relation to where my jet was pointing. But instead of locking the bandit the radar chooses to lock the air and drop the lock and wont give a guns solution. In the following 3 video clips you see at least the pattern, when the lock is lagging seems to be the same, that the closer the bandit gets to the HUD the chances of a lock is getting better. But the time for the FCR to calculate a guns solution is too little. But I still want to point out in the first 2 video clips, that I cant believe a modern F16 radar would have issues locking that target almost stationary in front of the F16. Trackfiles as ZIP: https://www.dropbox.com/s/3aplmwjhlavn2ex/F16_ACM_Lock.zip?dl=0

You're welcome Yeah.. the "efforts". Just to find out, either W10 or W11. Its not changing a lot.

Genau. Also aktuell schenkt es sich nichts und man kann sich auch vieles einbilden. Man kann auf jeden Fall in W11 spielen ohne Nachteile. Also wenn man den Umstieg wagt, es geht. Wenn man auf W10 bleibt, verpasst man nichts, bzw laut FPS VR hat man da sogar aktuell noch den smootheren ride.

I dont want to hijack that thread, so I created a separate one. Just testing W10 vs W11 with my current hardware.

As there is already a thread about it in the german subforum, I wanted to post my testing results here as well. Might be interesting for some of the english speaking users too. My Hardware: Gigabyte Z690 GamingX DDR4, Intel i9 12900 KF, 32 GB DDR Ram, RXT 3090. Pimax 8KX @ 60 Hz - Steam VR @ 100 % (native Pimax 8KX resolution) The new Intel should be able to make use of the W11 new architecture. I recorded two short replays on the DCS dogfighters sever. They play back indentical, but of course I am moving my head a little bit different in each video although I was trying to look forward most of the time. Windows 11 above and Windows 10 below. As you can see CPU frame times look better in W10 although it does not feel worse in W11, when in VR. I will stay on W11 for now. As soon as Microsoft starts to roll out more and more updates I hope that the support of the new Intel processor architecture will outperform W10 at some point...hopefully. I also ran a cinebench benchmark and both operating systems performed similar. Conclusion: W10 still seems to be the OS to go for DCS.

Also das ep_setup aka explorer patcher ist schon mal der Tipp des Monats gewesen. Die Hardware ist: Gigabyte Z690 GamingX DDR4, Intel i9 12900 KF, 32 GB DDR Ram, RXT 3090. Der Intel sollte Gebrauch von der neuen W11 Architektur machen können. VR: Pimax 8KX (60 Hz) Steam VR: 100% Ich bin jetzt mal zwischen W10 und W11 hin und her gewechselt. Im Spiel selber in VR hatte ich das Gefühl W11 performt besser. Wenn man jetzt aber die Videocaptures schaut sieht die CPU time bei W10 besser aus. Ich bleibe aber trotzdem erst mal auf W11 und schaue was noch so kommt. Aber die CPU frame time scheint gerne mal bei W11 hoch zu gehen, wo sie bei W10 unten bleibt. Wie gesagt, man merkt es aber nicht in VR. Oben im Video ist immer W11 und drunter W10. Sieht man am tiefblauen Desktop. Das sind zwei replays vom DCS Dogfighter Server. Die spielen zeitgleich das selbe ab. Nur meine Kopfbewegung in VR ist natürlich nicht immer gleich. Ich habe aber versucht mich nicht ablenken zu lassen und nach vorne zu schauen

The interface has been fixed for VR in this update. At least for the vehicles I tested it in. Just like in 2D the images are layered on top of the VR view. Does not look very pretty, but totally sufficient to play in VR. Works for me! Thank you ED! Now we only need a crosshair (to see where to lock targets) and the aiming reticle (pipper) in first person view. It already works in isometric view (which is just the external view in VR) but only with mouse input. If we get this too, it'll be totally playable in VR. ...and yes. ED is secretly working on it apparently, but they dont tell anybody about it

I'll post here for sure when I have set up the Ryzen PC with the new returned CPU and compared it to my Intel 12900 PC. But that wont be before the end of the month, when my current animation project I work on, is over. Because I'd have to replace my current work PCs peripherals with the Ryzen. And as it is known, never change a running system during a project Until then I am happy with my new setup and that I can finally enjoy DCS with smooth frame rates in VR. Thanks for all the useful hints and tips guys. Expect a good comparison between Ryzen9 and i9 at the end of the month

Danke! Werde ich defintiv ausprobieren. Make W11 great again and the taskbar small.

Vielleicht... ABer kann ich dir nächste Woche sagen, wenn ich noch mal auf W10 zurück war. Die neuen Intels profitieren ja auch anscheinend von W11.

Well thanks for the heads up Maxsin. I did not know about the upgraded Ryzen processors. I think I will keep the Ryzen9 5900 as working PC anyways, when my reseller sends a new CPU. Good single core processor speeds are valueable for my work as 3D Computer-Animator. Before that system becomes my new work PC I will set it up for a quick test in DCS again. At least we know then. So long story short: ( probably defective) Ryzen9 on MP servers had CPU frame times of 20-22 ms. Now the new Intel 12900 under Windows 11 has CPU frame times of between 9 -12 ms. Which is most of the time an absolutely smooth ride. Further investigations will be done. I also will revert to Windows 10 and see how performance is.

Also, ganz schnelles Testurteil. Der sehr wahrscheinliche defekte Ryzen9 ist auf dem Weg in den Umtausch. Jetzt steht der PC mit Intel Core i9-12900KF und Z690 mainboard von Gigabyte. Bislang nur W11 und DCS drauf. Läuft super in VR. CPU frame time von 20ms auf 12 ms auf gut besuchten Servern gesunken. Ist aber natürlich nicht aussagefähig weil CPU und Board ein Jahr jünger und absolut aktuell sind. Nächste Woche kommt noch mal W10 zum Vergleichen drauf. Wenn das schlechter performt, dann mach ich das upgrade auf W11 und eine fresh install. Randnotiz: Dass man in der Taskleiste gezwungen wird alle offenen Fenster gruppiert anzuzeigen, ohne das wie in W10 einzeln anzeigen lassen zu können, ohne in der Registry was umzustellen ist eine Frechheit, wenn man einen Monitor hat, der horizontal 3440 Pixel Auflösung kann. Super, da kann ich 3000 pixel schöne leere Taskleiste schauen. Hoffe die "ungrouped view" wird wieder seitens MS aktiviert.