All Activity

Ordered 12 Feb, email advising of shipping estimated in May, followed by another email a week later estimating shipping in late June or early July. Email received on 14 July stating headset ready for shipment which would be advised in 7-14 days. Email sent from me requesting shipping update received a response this morning that shipping may happen in 2-3 weeks. If it was ready for shipping 2 weeks ago why will it take a further 5 weeks from then to ship . if I am lucky it might ship in late August so I guess I am looking at September for receipt as the earliest! Not happy - Sorry Pimax you are falling waaaay short on meeting customer expectations.

Sounds a lot like buying a car, then leaving it in the garage for 10 years and expecting it to work as it did on day one, then after 10 years of depreciation decide that because you never used it, expect to get the same value back...

I was on Cold War Contention yesterday, and still had the FPS loss looking north to northeast from Wittstock airbase

Broke the confidentiality clause that went along with the said agreement on at least 3 occasions since late 2024, on at least 2 occasions by Ron Zambrano himself.

I probably have under two hours, combined, in all Razbam modules. I did intend to get around to them some day but since they're being removed that will be difficult.

Yeah honestly would be too powerful for PVP (who cares about PVP). Especially combined with active defence. Also i hope those Additional MSI functions won't stop at "MSI track as an L&S and DT2" so proper ATFLIR MSI track contribution will be worked out as well, it is as important.

They shouldnt refund them anyways unless you've had them for 30 days or so; they've been "theoretically" released for the better part of the decade and out of EA (theoretically). It would be nice, yes...but if you know how to fly those aircraft, then you've flown them enough.

I like this idea! The other day I was landing a Chinook in a very remote area. The small dirt road had traffic that looked like an interstate highway. Would love to be able to reduce traffic in remote areas and increase it in urban areas.

Thank you

Hey, I don't know how to reproduce it, so I'm not going to post it in the Bugs section and I only flew Viper recently, that's why I'm posting it here. 3 times over last several days I got nothing on my RWR when SA-11 launched at me. But most of the times I did. In the last case today I got RWR notification about Patriot that was launching at me immediately, but nothing for SA-11 that launched and was tracking earlier(see screenshot from TacView). I specifically checked earlier that my RWR is turned on and I'm pretty sure it's not RWR blind spot at this angle. It's not easily reproducible though as I had no issues with RWR warnings for SA-11 locking and launching at me earlier during the same session on the same server. I remember there was an issue with SA-11 not giving RWR warnings recently, but it was fixed (in June). So, my question is: did anyone observed this too? Thanks null

You do realize a vast majority of that footage the pod is under 10nm when looking at stuff, right? Here is a better video for you skip the intro go to 0:10. They even talk about how they are only 13n aways. And when they are tracking the F16 they are about 14nm. Im getting pretty good image quality in DCS when using the Sniper and Im using MSAA 2x. Im sure msaa 4x would be even more clear. But I bet a lot of the people in here are using DLSS or FSR or something which just isnt that good and blurs the image a lot. I would stay away from DLSS/FSR usage imo but i know that isnt much of an option for most. Later I will post images of what I am seeing. All the way out to 40nm.

Please forgive me. There are two reasons why I posted this here... 1. I have been trying to solve the hand tracking problem in DCS for a long time. I can't buy Slugmouse because I live in Russia. PointCtrl is impossible to buy anywhere. 2. There are very few topics on hand tracking on the DCS forums. And this is the main one. I constantly look through the entire DCS forum, аnd I can't find an acceptable solution anywhere. I guess I'm not the only one. I just wanted the solution to be available to as many people as possible.

Lol, it doesn't end. "Hello! After checking with the logistics provider, we wanted to gently let you know that your 50PPD (Tracking Number: ***) couldn’t be delivered successfully and is currently being kept safely at the local logistics station. Please find the service station details below for your reference:" Apart from all the other tracking emails (three different links to three different sites) that say delivery is scheduled for tomorrow, not once in the nearly three years I've been here has any courier failed a delivery. The address is definitely correct. The missus happens to be in town shopping right now, so she's going to ring the provided number and see WTF is going on and maybe pick it up in person (last tracking update says it's at Yamato's in-town office, ready for delivery tomorrow).

I'm concerned about the long term viability of these products, and sadly it seems that ED will only offer F-15E refunds, and not for any of the other modules that are being killed off.

Some shots from MR.

A little question, is the left & right wheel brake pedals on the real tomcat, control the wheel brake on both side of the nose wheel seperatively, or one press on either side of the pedal, collectively stop both wheel brake left and right?

@jonsky7, @MadKreator, & @Deezle, Thanks for researching this display export for the Hook! I noticed the contents of the MFD_device_IDs.lua file identifies the MFDs as follows: "CO" - co-pilot outboard "CI" - co-pilot inboard "C" - center "PI" - pilot inboard "PO" - pilot outboard MFD_SELF_IDS = CO = 0, CI = 1, C = 2, PI = 3, PO = 4 My multi-monitor config includes the use of 3 CubeSim 600x800 monitors plus the primary 2160x1440 display. I played with the MFD_init_copilot_in/out.lua and MFD_init_pilot_in/out.lua files to see if they would alternate between positions. Foreshadow: it didn't work. Both pilot & copilot displays were overlaying on top of the other. I'm not a coder so break stuff but not confident to fix it. Here is what I modified for the copilot files: MFD_init_copilot_out.lua (lines 17 - 18): 17: update_screenspace_diplacement(0, true, 0) 18: try_find_assigned_viewport("CH47_Copilot_LEFT_MFCD") MFD_init_copilot_in.lua (lines 17 - 18): 17: update_screenspace_diplacement(1, true, 1) 18: try_find_assigned_viewport("CH47_Copilot_RIGHT_MFCD") I made a separate entry on my monitor config file to add the correct viewport for CH47_Copilot_LEFT/RIGHT_MFCD. I also used the "0, true, 0" and "1, true, 1" displacement values to aid in monitor identification. It did not help. I also changed the displacement values in the pilot position to "3, true, 3" and "4, true, 4" respectively. Again, this was no help in blanking the copilot displays while in the pilot seat and vise versa. The blanking of the displays when the player is not in the corresponding position is very similar to the AH-64 TEDAC blanking issue when switching from CPG to Pilot seats. @jonsky7, you initiated that TEDAC thread almost 2yrs ago too. The solution you guys provided is a good start! For now, the pilot displays are presented on my CubeSim monitors while in any other crew position. At lease they respond to input from the Copilot seat. Ultimately, I believe this problem should be resolved by ED. What do you guys think?

The laser only works under 8nm. If you fire it outside of that the range will not display the L. Read the manual.

Yes, as well as to missions 9 and 12 where the new and more realistic blast effects from bombs have changed the outcome. We are testing the fixes now then will submit to ED.

Have you tried logging in again? Sometime, you could get a server hiccup and that screws up the authentication.

Good to know and I have never done on the ground so I do not know that is the issue...