Rosly

You mean "known issue". Please refer to some source? You need to create shortcut with this param or the *.bat script.

@USAF-Falcon87If you have the Steam version, DCS will be restarted with command lines given by Steam while getting the license. In order to modify the parameters for Steam version of the game, you need to modify the params in Steam itself. This can be done for each title you have in Steam. BTW if the game exists when you close SteamVR, it means it used SteamVR. You can also check if StreamVR overlay can be called by controller menu button. null

@VR Flight Guy in PJ Pants@emibat

The probably didn't add the option as it is broken. You can add "--force_steam_VR" to the command line of DCS launched from Steam, in title properties. After checking, can you bump the thread I linked? @cfrag @twistking @dutchili @Gryzor

Same here. If I force OpenXr it works, but it crashes when runnik over SteamVR.

@Lordvader @NineLine Can you look at comment and create a bug entry? Also I cannot change the topic while the actual problem is jot SNR but simply bug in squelch implementation.

One more remark: It seems that some payloads change the behaviour of the radio initialization code. Usually this means that we have uninitialized variables in the code and they get different values based on memory layout. From time to time during the cold startup, I have the proper behaviour of the squelch. Means any squelch in off immediately produce radio noise sound. This would mean the constructor for cold start for radio need to be fixed.

I see the point. You are right! The current AH-64D has a nasty implementation BUG for squelch as I described in The current implementation for squelch is broken beyond sanity, as instead outputting static from each separate radio for which it is set to squelch OFF, it instead output static from those when any other radio get a transmission xD To overcome this, squelches need to be all ON This is not MAD campaign issue. The radio transmission are actually made by "RADIO TRANSMISSION" action from scripts. This method does not use frequencies set for units, but get the frequency as argument and play sound file for all units on that frequency in a given zone. So my initial assumption about wrong frequencies set for units is semi correct. They are not set to briefing frequencies so we will not hear reports from units getting to navigation points or engaging enemy, but those are totally separate from how audio narration is provided to user (for which I actually care). Ugh, spend quite a time to understand what is going on, so posting this a bit long explanation just in case anybody else got this problem. SOLUTION!!!!!!!!!!!!!!! After cold start in AH-64D switch ALL!!! squelches to "on" (forward). Due the nature of the bug you need to switch them all regardless of which radio you plan to use.

The squelch function in radio is not "noise cancelling"! It suppress the RX path or specific radio receiver if the received signal strength is below certain level (there is even a knob for that - though non functional in DCS). The squelch switch does not influence on the reception signal strength and the signal to noise ratio as common understanding of "noise canceling" might be. Those are two separate technologies quite far apart from each other. Squelch should just cut off the transmission if the signal is barely understandable or allow for a bypass. You can find a proper implementation of squelch in other aircrafts (beside some broken ones like A-10II, thinking the same guy had to implement this xD). Important is, squelches are separate for each radio. Those are separate analog radio paths which does not influence on one another. If UHF signal level gates (open up) the UHF squelch, it does not open nor influence on VHP, HF and any other squelch gates circuits. The point is each radio audio "opens up" if it detect usable radio signal for this specific radio. The current implementation seems to have three problems: - squelch in off state should normally produce static from given radio. This is not the case for AH-64D currently as opening the squelch sets the radio squelch in bypass mode (you hear all static that is currently in the air). - invalid audio mixing implementation. Currently any radio transmission opens up all squelches which cause total garbage sound (for instance UHF transmission are mixed with static noise from VHF, FM1, FM2 and ADF if there are no VHF, FM1, FM2 or ADF audio transmissions at the same time). This is almost like developers think that squelch is implemented at post audio mixer, not in the intermediate frequency amplifier and detector circuits of each radio (therefore they are separate things). - a initialization problem with squelch on/off. Those are off on cold start but no static noise is hearable, so user does not really know squelch is off. I know just in some recent patch squelch switches was changed from monostable to momentary. It might be true in real life but it is also true squelch in off should give radio static (which is missing as I already wrote). So the dev which done this was just lazy. @corbu1 You probably switched all squelch switches to "on" after a cold start. I think you missed a point in how to reproduce this problem.

Same with easy com. This is a bug report for a feature not actually looking for workaround. Video record from simple mission with two slots. One hot one cold. Can someone confirm?

Hi, The radio initialization code is simply broken. The static noise level on all radios depends if you do the hot or cold start. You can easily check this on any Caucasus mission while tray to talk to ATC. In cold start the static is far more noticeable than when you do the hot start. Not mentioning the squelch does not work at all (already mentioned in other post in this subforum). This actually cause the only AH-64D campaign to be unplayable as you need to modify it in order to play it.

Ok ... found out this is a 50/50 from bug in AH-64D cold startup and wrong freqs in a briefing. So in cold start the noise lvl for radio transmission is not calculated correctly. You can verify this by comparing hot and cold start with well defined mission and ATC frequencies (like on Caucasus map). Secondly the briefing for mission 1 is as I said wrong. The VHF frequency is 110.8 (not 115.8) I think the UHF is also wrongly set up for some coms 305 instead of 275.75 Just thinking how many audio I will miss in later missions The work around for now is to modify the mission and make yourself a hot start.

HI, In mission 1 (not sure if other as well) the radio communication is covered by huge amount of noise (white noise radio). I correctly set up the radio frequencies for UHF and VHF and moved volumes to correct levels if you ask. Everything on the video: Quick look over mission 01 miz file and the radios for units are all over the place. The ASS Setareh is on 200MHz in mission and Saber is 0n 110.8Mhz. Those are different frequencies than in a briefing and tablet materials. Guessing this is the root cause of the problem. Though I'm supposed nobody spotted that earlier. It might be the AH-64D finally started to support radios properly or something or my startup is totally wedged somehow. Any help?

As in the topic. Has anybody have and idea how to do such simple thing as going back to F1 view in replay without interrupting the stored head movement playback? I do not believe DCS is so broken that there is no solution for this for so long time.

Is seems that after some (not non recent) update, debugger.lua script start getti g issues with aviability of following lua function: "getregistry". For those who do not knkw what debugger.lus is: Have following error in dcs.log with debugger.lua script load error Scripts/Mission Scripting.lua:[string ".\debugger.lua"]:182: attempt to call field 'getregistry' (a nil value). Seems this function was sanitized or removed from lua interpreter for DCS. We track this also on mose github: https://github.com/FlightControl-Master/MOOSE/issues/1876 Any thoughts?

Hey. Thank you for tracking this. Just want to stress out how important this bug is for user experience. All A-G missions which base on spotting ground units that are stationary is almost impossible to complete. As example whole Enemy Within 3 for A-10 campaigning lose a lot of fun from fact you cannot spot units, even destroying them they are essential elements of the mission. For A-10 and F-16 both TGP and Maverick use is almost impossible. Especially if units are in urban areas with a lot of hot objects in the view. Those units are completely black which not only breaks immersion but makes targeting almost impossible. It is in fact required to use TV view to complete the mission objectives.

Just bought a Leap Motion, so unsure if this is new bug or known issue. My right hand is disappearing after few seconds of use of Leap Motion in DCS. Left hand works ok. I tried to show/hide hands with keyboard shortcuts (this is probably new commands in DCS I suppose) but the problem is not connected with those being mistakenly activated. I mean right hand truly disappear because of some bug not that I click or activate some setting by mistake. When I disable and reenable Leap Motion extension in DCS, right hand appears once again and work for some time. They it disappear again. It is also not the problem with my Leap Motion tracker nor any VR setup as the Leap Motion works perfectly ok with other apps. Also both hands are perfectly tracked in Leap Motion Control Panel app where you can look over the tracking when DCS is pulling the data. It is something within DCS itself. Not in driver, tracking, operating system or Leap Motion config level. I use official Gemini 5.7.2 driver from Ultra leap.

@jaylw314 @Yurgon @CageyLobster Thank! ILS and Tacan Morse audio codes works and it is indeed required to "pop up - enable" the volume knobs to enable sound from those - exactly as described.

Seems this problem persist back to 2013. I have no audio morse code's on Tacan and ILS. Anybody can confirm or suggest what I'm doing wrong of this is actually working for you?

Have the same effect, while playing Combined Arms. Didn't done anything special. Started playing first mission provided with CA.

@Wags any chance we could see improvements from AH-64 be merged into F-1/F-18/A-10 TGPs?

Maybe this could be improved now, to reflect the mechanics of reality instead of artificial limits

Not my fault. There is some DOS right now on the forum page if you didn't noticed. Got several 500 errors and multiple threads created by itself. Already removed those.

In the latest AH-64D update, a true image tracker was announced. I'm wondering when we will see this implementation be copied to F-16 (even on basic level) Not asking for something like auto-tracker (which works differently in F-16) but true implementation of contrast tracking. Currently both TGP and MAV are locking to nearest object which are in view. After TMS up, the view snaps to closest object in the view, or in case one is not available, TGP lock in point tracking to ground coordinates (sticks to them like a glue even without lasing and range finding) and refuse to lock in case of Mavericks. This is not how this actually works in reality. In reality a true contrast tracker (similar to how it will be implemented in AH-64D) is required to track a point or hot spot in thermal view. The drawbacks from current solution are quite obvious like: - tracking moving targets even they are occluded by building or terrain (without switching to INS mode) - occlusion by plane fuselage or terrain does not cause to lose a track - mavericks that lock up to something which is not visible on video feed (like cold objects in IR mode which does not produce any contrast) - artificial limits to Maverick range (~ 8 miles) to simulate some existing limitations that are actually related to range but not directly (like pixel count of the sensor and sensitivity) while at the same time: - locking to hot targets through the clouds and fog and keeping the tack even they are fully occluded by them - fog and clouds does not influence on tracking precision Basically all of this came from fact TGB and MAV are tacking game object (internal logic of a game), and not contrast of an image.

@FlappieThanks for explaining that this is on TODO list.