sthompson

I do not normally fly helos but I decided to run the Huey startup training mission last night to check on this. I also found that VAICOM PRO was not identifying the Huey. I haven't had this problem with other modules.

I'm having trouble refining the CCRP aim point when preparing to drop CBU-97s from the A-10A. The lock button seems to ground stabilize the target point, but then I can't slew it or unlock it to set a new one. Any thoughts on how to proceed if you push the lock button a bit inaccurately?

I've found it happens about 1/2 the time on the anti-ship training mission. That's with the flight profile set to low. And when it occurs the missile does eventually return to its 50 m specified altitude before reaching the target, but then overflys the target without impacting it.

Training mission 9, Antiship Missile, all goes well until missile launch. The missile turns slowly about 35 degrees to the left to track towards the TP at DST 30, but after a while it abandons that course and turns towards the carrier, eventually getting shot down. I've verified (and you can verify in the track) that the target coordinates match those of the cargo ship, and not the carrier. This happens consistently, as seen in the two missile launches in the track. dcs.log Training-09-Anti-ship Missile.miz_01012022_17-23.trk

I take it you are saying this is confirmed as a false positive. Do you speak for the company? If so I will put in an exception for the file that triggers ESET. But it's not true that all known antivirus programs have a problem with DCS files. ESET does not normally complain about any other file in the distribution, including the two files you mention, and I've not needed exceptions previously. The OctopusG file is different somehow. May I suggest that if you have hundreds of testers that at least one might want to use ESET while testing. It's one of the top AV products by market share.

The problem is caused by the interaction of the ESET program and the I-16 module, not by ESET alone. You are entitled to your own opinion, but I would think that developers would want their software to install correctly in commonly used environments, and ESET is widely used. Hence a bug report on the beta update. It's up to ED to decide what to do with it, and whether to contact ESET. I'm not trying to dictate anything, or cast blame, but have only offered my own experience and opinion. Regarding reporting the problem to ESET myself, that's on my "to do list," provided I can figure out how. The ESET software deletes the file in question as soon as it appears in the download folder, which is why the ED updater can't find it to install, and so I have no file to submit for analysis. I'm sure that ED or OctopusG could provide it, however. I assume that false positives are relatively uncommon (they are on my system) and so I do not think it would be terribly burdensome for ED and/or OctopusG to communicate with ESET about a known compatibility issue once it's reported. So yes, I really believe that ED and/or OctopusG should contact ESET and other AV vendors whose software is flagging the I-16 module. (I never said "every Antivirus manufacturer." Those are your words, not mine, although I admit that "AV community" is somewhat vague and I'm trying to be more precise here.) Better still if OctopusG would learn (perhaps from talking to ESET) how to avoid false positives (assuming that's what it is), just like other developers. There is a repeated history of compatibility issues, as evidenced by older threads reporting the same problem with older builds of the I-16. Other developers seem to be able to avoid this, so it is possible.

An initial TX press is always needed to "wake up" VAICOM so that it checks the Hot Mic setting in the cockpit and then sets its own hot mic behavior to match. I've gotten in the habit of doing a quick TX press and release whenever I change something in the game that might be "of interest" to VAICOM. I do the same right after VAICOM loads, even before starting DCS. BTW, VAICOM syncs to the pilot's hot mic switch, even if you are flying as RIO. Or at least that was the case last time I checked a few months back.

Yes, ESET Internet Security. I spent an hour going through the advanced setup yesterday and couldn't find a way to force quarantine on files flagged by real time system protection. Looking at files already in quarantine, all I see from past scans are malicious attachments from SPAM emails.

Definitely a problem caused by the I-16 update triggering antivirus software. This seems to be a recurring problem with the OctopusG module. I don't have these problems with modules from any other developer. OctopusG really needs to change the way their software is distributed, or else work something out with the AV community so that their software doesn't trigger malware scans. And ED should update the updater so that a problem with a single module doesn't kill the entire update. See

Unfortunately, the ESET software deletes the DLL as soon as it is created so there is nothing to upload for analysis unless you first disable the scanning of that file. It doesn't seem to quarantine this file, and I haven't been able to find an option to ask it to do that.

I use TrackIR and I've found that with some contortion I can see all of them. However to avoid spraining my neck I created a few convenient Snap Views and bound some buttons to those. Some require moving the pilot head (As Flappie suggested) to view from a better position, and adjusting the Zoom so that the labels are readable.

Well my original post unfortunately seems to have triggered a bit of flaming. Some suggest that I should just exclude DCS from scanning. This seems to be based on an assumption rather than any evidence that any positive reading now or in the future is a false positive. Others have suggested I may just have to give up the module I paid for. Neither option is acceptable. Customers shouldn't be forced to chose between opening up their systems and using DCS. Even on open beta. For me, if forced, that's an easy decision: No way I'm going to just give ED a free pass on every file they send my way. In my view ED should work it out with ESET so that when the OB goes to stable the installation doesn't fail, as it did for me. The issue isn't just that the file is flagged as a problem, but also that this causes the entire update to fail. That's a bug in my book. Whether it's ESET's fault or ED's doesn't really interest me. They both look bad when there are false positives (as does I-16 developer Octopus). Assuming for the sake of argument that that is what it is. I hope they work it out. In the meantime I'd like to get some confirmation from ED that the information in the original post is a false positive before I exclude anything from virus scanning, and then I may temporarily exclude the individual file. @NineLine, @BIGNEWY, are you listening? Or perhaps there is a less risky workaround.

I suspect the higher disk requirements for VR are related to shader files and the like that are created on the fly by DCS, and not part of the download directly. But you might ask in the VR forums.

Both are pretty clearly described in the documentation. Instant Select will cause VAICOM to execute a Select command if one is needed based on the recipient named in your VAICOM command. For example, suppose you take off from Kobuleti after receiving ATC clearance. Kobuleti is thus your selected ATC. If "Instant Select" is off then you need to give the command "Batumi, Select" before trying to contact Batumi. But if Instant Select is on then this is unnecessary. Note that Instant Select does not tune the radio for you, even if you have "Select Tunes Radio" checked. (However if Easy Comms is on, then DCS will tune the radio for you when you use the Instant Select feature.) The "Dial" switch is for modules that have a single PTT for all radios and where you need to select a radio by turning a dial. In the MAN setting you need to turn the dial yourself, or else use Easy Comms (in which case DCS automatically sets the dial position). If you use the OPER setting then VAICOM will turn the dial for you when you select a radio via VAICOM's TX bindings. According to the documentation, in some modules the dial position shown in the cockpit view may not reflect the actual setting when you use the OPER mode. Disclaimer: I don't fly any modules where this is relevant and so haven't tested it.

Eset's real time file protection deletes the file before the updater even completes, so there is no file to submit. And "most likely" isn't exactly reassuring. Sounds like you are making an educated guess.

The title says it all. ESET is unhappy with today's OB update: DCS 2.7.9.17830. The file that triggers an issue is as follows: Time;Scanner;Object type;Object;Detection;Action;User;Information;Hash;First seen here 12/23/2021 7:31:18 PM;Real-time file system protection;file;D:\Program Files\Eagle Dynamics\DCS World OpenBeta\_downloads\Mods\aircraft\I-16\bin\I16FM.dll;a variant of Win64/Packed.VMProtect.J suspicious application;cleaned by deleting;CEZANNE\Maintenance;Event occurred on a new file created by the application: D:\Program Files\Eagle Dynamics\DCS World OpenBeta\bin\DCS_updater.exe (F0D2D7558B79F120183DDCF675D1164694DDB7FE).;90B70EDD562AEF2ECECD2F6839C60C3E6060D1CF;11/18/2021 6:28:33 PM The real-time deletion of this file causes the updater to quit with an error message, so I assume I have a non-functional installation now.

You didn't provide the "When I press button" detail. You can display that by pressing the button with three dots at the far right end of the "When I press button" line. For the TX6 Release command it should look like the attached screenshot. Note that only the first checkbox is checked. For the TX Press command none of the check boxes should be checked. Make sure that yours follow those rules. I suspect that you have one or both of them messed up.

We can't really diagnose the TX6 issue unless you show the details of your TX6 settings in VA. Are you certain that you have the TX6 press and release bindings exactly as specified in the VAICOM manual? It's not surprising that you get no response if listening is suspended before you give your command. Based on the VA screenshot your computer never heard that command.

In the spirit of providing help, after running a few experiments, I think I can explain what you are experiencing. You are almost certainly using the Dynamic Switching mode of VAICOM for SRS integration. When you use that mode VAICOM expects you to first give a VAICOM command, and then possibly follow up with a voice broadcast over SRS. It therefore mutes the SRS channel as soon as you push the PTT, so that your VAICOM command does not get broadcast. (SRS appears to open very briefly then close the channel because VAICOM apparently cannot mute the channel before it opens.) Once you successfully give a VAICOM command it will re-open the SRS channel automatically if you have "Auto Switch" selected. Or you can give a "Switch" command to reopen the SRS channel if "Use Switch Command" is selected. All of this assumes you are still holding the PTT key down. Experimenting, I found that if the VAICOM command fails then you might need to use the Switch command to open the SRS channel. And if you just want to talk on SRS without giving a VAICOM command first you need to say "Switch" at the start to reopen the SRS channel. Does it work as documented? Yes. I tested it myself this evening. Is that procedure awkward? I believe it is, so I don't use it. Instead I turn off SRS Integration in VAICOM (which is essentially the same as using Broadcast Parallel mode). If you do that then the trouble you are experiencing should go away, but you will then have your VAICOM commands going out over SRS due to using a common PTT, which actually is more realistic if you think about it. (Certain VAICOM commands such as Select are the exception.) Most of what I just wrote is well-documented in the VAICOM manual. The developers of SRS and VAICOM have worked together to provide a degree of integration, but they are still separate programs and this limits somewhat how realistically they can function together. But they can function together and many people are using both.

I have the same buttons bound for SRS and VAICOM (SRS radios 1, 2, 3, and Intercom bound the same as VAICOM TX1, TX2, TX3, and TX5 respectively) and have used them successfully together for years now. All I did was use the instructions that came with each. I use the Broadcast Parallel method in VAICOM since I found the other implementations in VAICOM to be awkward. A year or so ago I decided I did not like having my VAICOM commands going out over SRS and so I turned off the "radio switch works as PTT" in SRS and bound a separate button for SRS PTT. However before doing that, VAICOM and SRS would both happily transmit at the same time when their common radio button was pushed and held. If you are looking for help here then I'm sure you will find it. No one who helps here is paid. We are just enthusiasts. So some patience might be required. Your attitude in this thread seems to be about criticism rather than seeking help, however. It is not true that VAICOM and SRS require separate keybinds. But even if it were true, this would not make VAICOM "pointless." At best it would mean it is not the right tool for you, and it would not make it a "terrible program" as the title of your thread implies. If you want help you might start by providing a lot more precise detail about your setup and exactly what goes wrong. For example, when you say "the PTT opens briefly and closes itself" that is not precise. What exactly opens and closes by itself? Surely the button is not moving by itself! And which of the several VAICOM options for SRS integration are you using? BTW, it's vAIcom, as in voice AI communications, not vIAcom, which is a large telecommunications company.

Those aren't really notes to assist new users but rather a restatement of criticisms you've posted previously. If you don't like VAICOM then go right ahead and use your own VA profile. To each their own opinion. But I have to push back on the unfair criticism about "closing a plug in." VAICOM behaves just like any other VA plugin. It starts when VA starts and exits when VA exits. There is no such thing as "closing a plug in" except by killing VoiceAttack, and this is by design of VoiceAttack, not VAICOM. The VAICOM plugin does not "terminate its host program." So I do not understand what you are talking about in making that criticism. If you want to have the ability to terminate a plugin without killing VoiceAttack I suggest you take it up in the VoiceAttack forum. The VoiceAttack specs for plugin design includes a function for killing the plugin but (per VoiceAttack documentation) it is invoked only when VoiceAttack itself is shutting down, and this action is initiated by VoiceAttack, not by the plugin. You are perhaps restating your previous criticism of the VAICOM.EXE tray app, and not of the plugin itself. As was pointed out to you earlier, use of that exe is totally optional. If you don't like its behavior, then don't use it. I don't. VAICOM works fine without it, and it was provided only to provide a way to automatically restart VoiceAttack when it crashes. It otherwise has nothing to do with the plugin.

You should be getting static sounds on both push and release. A VAICOM error generates a "thud" sound if you have UI hints turned on (which is the default), and this may happen upon release for various reasons. Turn on debugging and check the log to see if this is happening. Another possibility is that the sound is coming from other software bound to the same button (e.g. SRS, Teamspeak, etc.).

Attached screenshot is from Hoggit Training server, which does not enforce Easy Comms. I have SRS running and connected to their server, and Easy Comms are reported OFF by VAICOM PRO.

Can you clarify what this means? In the screen shot the only selector dial I see is on the PTT page and it is set to NORM. The same screen shot shows Easy Comms ON.

So it appears that the "request taxi to runway" was sent by VAICOM to DCS. Did it appear as a player command in DCS? For example, did you hear the player voice echo the command or was it listed on the DCS screen? If so then DCS did receive the command. Otherwise something is failing in the communication between VAICOM and DCS and you might report it to the developer. Assuming DCS did receive the command, if Batumi did not respond the most likely cause is a mismatch of coalition. If you are in one coalition and Batumi is another coalition then it will not respond. EDIT: Looking at your log file again it does not appear that you had Batumi tuned on COM1. The frequencies for Batumi are 40.400 MHz, 131.000 MHz, 260.000 MHz, and 4.250 MHz. You had your radio tuned to 310.000 MHz. If you had Easy Comms on then this wouldn't matter, because DCS would change the tuning for you. Another problem is that you never specified Batumi as the recipient, but it was selected as the default ATC because it was closest at the start of the mission (or when you restarted VA if already in the mission). Instant Select will select Batumi, if you name Batumi in the command (which you did not). However it won't tune the radio for you. "Select Tunes Radio" will tune the radio for you only if you give an explicit Select command.