Thomas_GER

Thank you - very helpful

Ah ok - but that means that the moving map works without the GPS. I assumed that also the moving map should not work

Hi all, when I setup CW Germany in a time period for example in 1985 I see that the GPS of the KA50s does not work anymore….but not so for the Apache. Shouldn‘t the GPS as well as the FCR be inoperative in this time period?

Ok….good to know: In the 9800X3D enabling the X3D Turbo Mode DISABLES SMT, although SMT is set to Auto. I will test now with X3D Turbo Mode OFF Update: O - M - G……thank you for pointing me on that. Turning off the Turbo Mode shows now physical and logical cores and the balancing works buttersmooth.

I double checked - SMT is activated (or on AUTO, there are only 2 options either AUTO or DISABLED) I will have to dig into deeper cause there is also a X3D Turbo Mode where it is stated that the CCD function gets disabled….whatever this means.

No it is the opposit - at least for me: If I do NOT setup any affinity I see this behavior. Then I jump in and set affinity (where I leave 1 or 2 cores that I do not designate to DCS) and it works. Had exactly the same today in a MultiPlayer mission. Tried to slot and it took for eeeeeever. Then changed affinity and bam....I was in the slot. Please find the log here. I could re-produce this issue 3x now. It is usally one of the render Cores, according to process lasso it is Core 1 (so not "0" but "1") dcs.log

I can confirm that I have the same phenomenon with an AMD 9800X3D. But it does not occur everytime I start DCS. However if it occurs then it even shows up when I am just in the mission editor. And when start a mission and jump into a slot it takes forever to get into the cockpit. Usually when I change the Core Affinity in Process Lasso when this happens - it kind of "unblocks" or speeds up DCS and I find my self in the cockpit immediately.null dcs.20250308-094914.crash dcs.20250308-094914.dmp dcs.log.old

I got an update on this topic here. Did several tests and could narrow the issue down to 2 possible root causes: 1.) AV1 Codec I had a stable performance lately but I used mainly the HEVC 10-bit Codec. As soon as I switched to AV1 I got immediately a headset freeze - so there seems to be something causing the issue in combination with AV1 2.) Resolution and Frame Rate I got the impression that with too high graphics AND frame rates settings I get also a freeze. Therefore I had to realize that the labels of the graphics settings (High, Ultra, Godlike) in combination with the mentioned graphics cards in Virtual Desktop is misleading. In the VD discord I read that the graphic setting of "High" equals to 1.2 of the Quest3-Resolution, "Ultra" is 1.3 times the resolution and "Godlike" is 1.5 In the Quest Link app I never used more than 1.2 - so this is something to keep in mind when playing around with the graphic. And it is something that explains how much data has to be processed and streamed to the headset. This is the resolution per eye (!) produced by VD with the given graphic modes: Quest 2/Pico Neo 3/Quest Pro/Quest 3 Potato: 1440x1536 Low: 1728x1824 Medium: 2016x2112 High: 2496x2592 Ultra: 2688x2784 Godlike: 3072x3216 (Quest Pro/Quest 3)

Sound good. I can clearly produce massive stutters in the Apache when I look down right. This is really crazy as I get nowhere else those stutters. Seems to be the case that there is something (MFD with the Map on it?) that drags a lot of performance. So reducing Hz should help.

So my takeaway is to set the codec to NOT av1. will test this and give feedback here.

I am suffering exactly the same issue. Are you guys using Virtual Desktop with OpenXR or with SteamVR? I saw posts somewhere else where it was assumed that OpenXR might be a root cause for the freeze.

The multiplayer capability is a fair point. This is something I will also check out.

I was on Server 2 - that was the error - although I never changed any setting concerning the server. Nice work with the update - the error messages are gone now.

I purchased it and played the first mission. My first impression is both positive and negative. I like the voiceovers, the briefing material is very good and the mission itself is nicely structured. But what annoys me to no end is the fact that not a single radio frequency is preset, so that I as a pilot have to change all the frequencies. On the way to the AO, I first have to manually set the ground frequency, then the tower, then departure and then AWACS. This was solved much better in the “Four Horseman” campaign - just as it would be in reality, namely that certain frequencies are already preset and that the frequency changes are made by the CPG. The CPG also says “Fence In” - but does nothing. This is also done better in “The Four Horseman”. Perhaps this can be fixed with the next update.

My DCE Manager states that it has a new version available but just downloads an empty ZIP File. Where can I find the new version?

As mentioned before - to clarify - it is not the bug of the ASTI tool - it is a bug in the mission file due to several scripts running there and colliding. Without those the ASTI tool works great.

Thank you for your reply I‘ll send you a DM with the files. I have been using this version of DCE Manager already

I can't help but for me it seems that the installation of the DCE Manager is buggy as well as the afterwards usage of ASTI. After installing the DCS Manager I got the message that DCS Manager has no access to an options file that is in my documents folder cause another process is using it?! When I use the ASTI tool (which is great - really) I can process everything as described in the manual. But when I return back to ME and want to load the miz-File I get an error message. I can see also that the file seems not to get closed properly by the ASTI tool.

We have tested this several times in the squadron: We fly with 2 Apaches. 1 Apache has an FCR, the other one does not. Frontseater in the first Apache scans with the FCR, receives targets and makes an RF handover to the second Apache. In the second Apache, the backseater can take over the target - also sees it in the TSD and can lock on a Hellfire. The frontseater receives the message that a target has been transmitted, but after clicking on "REC" he cannot see the target. The target handover does not work with the frontseater either. He can see the targets in the TSD and FCR screen, but cannot lock on a Hellfire.

Understood - thank you. So I can leave it as it is.

I am using a so called dead stick (removed the springs from my Virpil CM3 base and tightened the cluctches that way that it can be moved easily but stays in position when I am hands off). Concerning the force trim release I have the option in the AH-64D to chose "stick without springs". In this case, if I press FTR the trim point centers on the current joystick position. My understanding of SCAS and FMC is this, that you should use the FTR in order to give the SCAS the new reference or center point where your stick is, from where the SCAS can dampen and hold the current position. But with the current options you cannot use the FTR with a dead stick. If for the SCAS it makes absolutely no difference if I use the FTR to give it the new position of the stick - then that is ok. But IF it makes a difference, it would be great to have an option for sticks without springs.

We did some more testing yesterday in our squadron. We were 6 pilots in different airframes, 4 of them in multicrew in 2 Apaches. Unfortunately I have to state that we were not able to get Voice Comm to work for all pilots despite the fact that we followed our internal setup guide properly. We faced the already known issues but could not find out any dependencies or root causes. + when joining the server we could not see all pilots in the chat rooms, only part of them + it took about 15 minutes then suddenly all pilots were visible in the chatrooms + some pilots heard the others over radio but could not transmit + the hotfixes (re-entering freqs) did not work

This was just a proposal for a possible quickfix. We had the same issue and this fixed the problem. Needs not to be the case but if you checked this out - at least with one or two team mates - and it would also solve the problem, you could report and ED would be able to dig into deeper.

Rongor, you need to have the Voice Chat enabled in the Audio setting. The server itself needs also to allow voice chat When you are inGame you need to activate the radios in the overlay (the radio symbol on the top left corner of the overlay needs to be clicked and needs to be green) Otherwise you won't hear anything. Could you do a test next time? I experienced something similar - was not yet able to test it with a larger group of people. But we experienced with 2 people the following: 1. Check in the settings of the overlay if the Mastervolume ist up - one team mate realized that it was at 0% for what reason ever 2. We realized (sitting in the Apache), that I could hear my teammate but when I sent a radio call he could not hear me. By random we realized that if I re-entered the pre-set freq it suddenly worked. Same if we both changed to another freq. It seemed as if Comms were not initialized or synced with the preset freq on my client. Maybe you can check this too. Would explain the strange behavior that some mates hear the others but cannot transmit.

We found out 2 issues: One team mate realized that the master volume in the settings in the VC overlay was set to 0% - for what reason ever. We had the finding that I could hear my teammate but he could not hear me. When I re-entered the freq or changed to another freq it worked. Maybe you want to check this out too that the transmitter that cannot be heard re-enters the freq.