darkman222

If you fire your first Maverick using the ATP, Litening, GMT or even VIS mode, the seeker of the second Maverick is stuck in the middle of the HUD. Which obviously does not make any sense. As you probably want to do a follow up shot. You can bring it back to move to the target area using TMS Down. So it goes back to where ATP, Litening, Ground moving target radar GMT or even the VIS designator is looking. Tracks for each method attached. atp.trk GMT.trk litening.trk vis.trk

I did not think of that. But whats the difference if it loads your default.dtc on cold start, or if it loads none? If you will change your settings for that particular mission you would do it anyway, no matter what was loaded before.

In general it is questionable while you rearm with the engine running in a few minutes in DCS then need to wait for the old TGP to reboot is a realistic combination at all. If the rearming procedure was realistic ( 45 minutes incl engine shutdown and restart ) a TGP boot would be required anyway because ground power does not power any of the TGP. Considering DCS rearming being a game mechanic that way, the need to reboot the litening TGP is not a realistic logic or addition to realism anyway. So its good we dont need to with the ATP.

And thats the reason why I created this thread in Wishlists. Wouldnt it be awesome to create a custom DTC comfortably with the DTC Menus ED is working on, then just click for example "make default DTC" and it will be either loaded into the jet already or at least ready for you to start the loading process via the MFD buttons? Imagine to go to servers like DCS Dogfighters BVR arena, where you can practice many BVR engagements in very little time respawning in a short time and have your CMDS and MFDs already set up each time you spawn.

If you do a trackfile, try to do a short one with only the issue isolated. Airspawn for example. Then dont use Mods. There is the eurofighter mod needed to be installed. I went through it fast forward and saw in the first engagement the TGP was NOT SOI. That could be the issue. In the second engagement the Mavericks were set to Boresight aka BORE. They wont slave to the TGP in BORE. Switching to BORE happens when you accidentally press the cursor enable switch on the hotas, or when its bound with some other key you press together with it. Make sure to stay in PRE mode all the time and that the TGP is SOI before you press TMS up on it.

Thanks. Although I dont fly the F18 it seems to work the same in the F16. Well it does not to break IC. Thats basically the same way we had years ago, when we modified the old CMDS.lua ... before it started to break IC. I would not wonder if it starts breaking IC at some point again. It works for me, and just brings back what we already had, back then. I hope we get the functionality to set up MFD pages next. I dont mind to go through different LUA files to set stuff up. But thats clearly not desireable, and also not user friendly. Especially not because thats the reason we got the DTC. 99% of the time you want to have the same CMDS and MFD setup. That could be in the default DTC for a standard quick action public server sortie. I was quickly looking through the lua files if I could find something to change the default MFD setup- but that does not seem to be integrated yet. Not even in the LUA files. EDIT: It is the EXACT same thing like the old CMDS.lua trick. You edit it, but as soon as a DCS update is rolled out it is being overwritten. I think thats not the proper way to edit a default DTC.

As title says. It would be very helpful on servers where you respawn a lot to have it already loaded. So you'd only have to press the MFD buttons once in the jet instead of browsing through files on th HDD via the DTC menu. As soon as DCS sees a default.dtc file it loads it. If it does not find it the behavior stays as we already have it. For people who like to browse through menus

But what would you do then, if FIX is overridden by GPS. When the accuracy is really 300 ft only instead of 131 ft, which has not been answered yet? 300 ft of INS drift that GPS does not fully correct but that can not be corrected by FIX taking either?

From what I understand is that our (pre EGI) DCS F16 will always have an induced INS drift, that will be corrected via GPS within the limits, which is happening now after the patch has been released. So what was fixed is not that it does not drift anymore, because this is not realistic. What has been fixed is that the drift stays within the allowable realistic limits. Thats what I tested here, and which is the case. As long as we agree on a altitude drift of 30 ft ( 100ft is allowable) and the lat/ long drift is about 300 ft, the fix is on point. Although 300 ft should be the maximum drift where GPS should start correcting it. If you read through the entire thread discussion which is not too long, 300 ft is the maximum drift, when GPS should be activated to start to correct it to a nominal drift of 131 ft (40 meters) . Which is also the amount of drift that is talked about in the Viper Mini Updates white paper, dealing about Kalman filter. If we want to go on discussing something here then it would be the only thing that still stands out: If it is 300 ft or 131 ft we should be experiencing with GPS corrections active.

In general the F16 has had 2 radar updates. 3rd one is still missing. But this should address ACM modes as far as I know, which will not address RWS or TWS. Better do a bug report as it seems like the general F16 section here is seen more as a place for discussion.

Was fixed and mentioned in : en/news/changelog/release/2.9.17.11733/ ->Fixed: INS drift is not GPS corrected and INS drift adds up to more than 1000 ft over time. Which is the exact title of the bug report that I submitted about it in the bugs section. Its now in the allowable limits. Under some circumstances the drift seems higher though. But the reasons will remain a mystery, I guess... Thats why I did the additional test of the drifting in altitude. Which is also in the allowable limits.

Yeah in that case you are right. If the CGI or wingman gives you the bearing and distance from a waypoint to the target, the easiest way actually is to use offset aimpoints. I was just imagining the original poster to move the cross on the HSD around, trying to create a mark point, so I wanted to bring the option to use GM radar up too.

As a workaround you can use GM radar. You will see the cross on the HSD move accordingly. You can create a mark point from that. Works especially well when you have a thread ring of a SAM site you need for a mark point. Although I think thats a feature the F16 actually has. But selecting a thread ring center as a markpoint / waypoint could also be a feature our F16 does not have due to its time frame.

What do you mean? I tried it and it works. If you have lets say, 4 waypoints close to each other, you cursor slew one, all the others are moved accordingly. CZ and they are all moved back to the initial position. No issue here. If you use FIX, it does the same. But you can not CZ to the initial position any more obviously. So can you be more precise what you are referring to?

I also had "blackouts". But playing in VR. Especially when holding my head still for air to air refueling. I never figured out how to fix it. Could be a placebo, but I never had it again when Tacview was uninstalled. So every time I knew there was AAR involved I uninstalled Tacview. You might want to give it a try as well. At least if it helps it would have been an easy fix for now.

I did the same test again. This time for INS drift in altitude. Flew 600 nm in one direction and back. Total travel distance 1200 nm. I had a Bedford truck at the runway end with a waypoint co-located. When I came back and landed the INS drift in altitude was (considering the height of a Bedford Truck) in about 30 ft higher than the waypoint was when I took off. So the INS drift in altitude is also well in the allowable limits and negligible. What I still cant figure out is while the INS dift in all axis seems to be in the limits, how is it possible to create the impression that the waypoint is off more than in the limits of 300 ft on the ground plane when approaching in a shallow angle. As seen two posts earlier.

Yeah, that referred to my bug report I did on this topic in the bug section as no moderator was commenting here. I ran my test scenario again. Take off, 3 bags, fly in one direction for 600nm then come back. Center building and the barracks around with a distance of 250 feet. null In general the INS drift looks like in the mentioned allowable limits. 300 ft plus minus. When coming in from altitude. So the lat / long deviation is good. What I am wondering is if the INS drift is also the same amount in altitude. If I do the approach to the waypoint from a shallow angle it looks like a drift of 600 ft in the exact same session. But I am pretty sure if you would elimiate the INS drift in altitude you would end up again with the allowable drift of 300 ft. Whats happening now is that a drift of 300 feet in lat long + a drift in altitude of 300ft adds up to a perceived drift of 600 ft in total, when coming in low. If I would elimitate the drift in altitude here you would end up with a drift of 300 ft from the center building, is what I illustrate here. Instead of having an offset on the ground plane first and then in height too, it would make more sense if the 300 ft offset would be in a radius around the waypoint. But just wild guessing here on my end why we get that picture from a shallow angle. So one question remains, is the allowable drift of 300ft equally happening in all axis. Also in altitude?

As you can see the sniper pod and the DTC is still developed. If you track the progress between updates on the DTC you can estimate how long it will take. Also a big thing are the RWR Handoff PRF Tones. I cant wait until the F16s RWR does not sound like a gameboy any more. Enough stuff still about to come, I'd say.

Mainz Finthen Airfield was also a Helicopter airfield in CW. Located between Frankfurt and Spangahlem in west Germany. https://de.wikipedia.org/wiki/Flugplatz_Mainz-Finthen#/media/Datei:Aerial_image_of_the_Mainz-Finthen_airfield.jpg https://en.wikipedia.org/wiki/Flugplatz_Mainz-Finthen From the Wiki Article: As part of their commitment to NATO, US Armed forces returned to the Mainz area and took over the airfield, which was renamed Finthen Army Airfield. As a result of the establishment of the United States Air Force (USAF) in 1947, the Army could use the airfield for helicopters, light LSO and observation aircraft only.

Yes please!

Yeah I already tried it. Although I could use process lasso to improve performance with my previous Intel PC it does not help with my recent AMD PC. The best performance is without process lasso actually. What I am running into now is also the one core bumping up to 100% usage (Core 0) . Not sure how that affects performance too.

I have an Airfix model kit of it, the one with the hot shots paint scheme. if you need a blueprint of it, let me know. But your model is already past that stage, where you need blueprints. Good work so far!

Having switched to an AMD 9950X3D I had a perfect stutter free playback until the DCS 2.9.16.10523 terrain engine update came out. I have periodic stutters now. Not severe but immersion breaking in VR. Using fpsVR I realized that it might be related to the CPU frame usage graph showing periodic spikes on the cores that are non v-cache x3d cores. Aka the ones that are not meant DCS or games to be run on. This was not the case before DCS 2.9.16 came out. These high CPU usage spikes sometimes seem to transfer over to the x3d cores then disappear. I am experimenting with process lasso to tie DCS to the X3D cores only. Seems to help, but still investigating. In the image I marked the x3d processors where DCS should run on. System is a AMD Ryzen 9 9950X3D, MSI X870 Gaming Plus, RTX 4090 In the video on the left side of the comparison you see the recent DCS version and how the CPU spikes appear and disappear. DXdiag and log attached dcs.log DxDiag.txt

Yes. Technically it does not matter if I have 2.5 ms of CPU frame time now or much more. But having headroom is a good thing for sure, and you can see in the frame time Graph in the comparison that it just does not stay below 11 ms it goes above it. And its not only just a spike. Its like 2 seconds or sometimes even more of just immersion breaking stuttering. I think that the architecture of the AMD processor is much more suited for DCS. Also bad things like DCS processes being calculated by the slower non X3D part of the processor or core parking issues seem to be sorted out by the most recent generation of AMD processors. I can highly recommend to switch to AMD if someone considers a new PC or even if you are the lucky ones that have their decision already taken by a faulty i9 processor that killed itself. In my case its more likely that the mainboard killed itself, but lets see what Intel and Asus Tech Support will tell...

I could not use the same track because my previous Intel PC just died without a warning. But its from a recording from DCS dogfighters. From days with comparable amount of users online. But I can say for sure, with the intel it has been like around 8 ms CPU frame time occasionally breaking the 11 ms barrier, creating VR stutters. And with the AMD the CPU frame time NEVER goes higher than 4ms. Most of the time 2.5 ms. Same on other servers or huge SP missions. The difference is massive even without a technical perfect comparison.