ravenzino

Point taken. This thread is about the other part of the problem though...

This short video explains in a simple way of how AV works. It's just the result of a quick search, so might not be ideal, but could help to get everyone one the same page.

Thanks for the info. I did that as well, and also got a bit confused by the result to be honest. But again, we don't own the source code of the AV software or its databse, neither that of DCS. So either ED come back and say "we've checked, nothing wrong here" and push for Kaspersky to update its database, or ED change that line of code to avoid the triggering. Or we just submit the file and wait, hope this is just a stupid mistake at Kaspersky side and they fix it by themselves... and risk our system security by excluding DCS from AV for the time being. But remember, if there's a unintended backdoor left open, people outside of ED could exploit it too. That's why excluding a file from AV is really not the best idea.

You don't kill the barking dog who's trying to do its job and keep the quiet dogs, unless you want your house eventually left unguarded... Well, a mad dog that keeps on barking for no reason is a different story, but I don't think that is the case here. Mods are entirely different thing as they live on DCS, while you don't want your system security to live on ED. Having said that, it is still of ED's interest to at least provide some best effort to allow a good ecosystem around ED/DCS. But that's another topic, so I'll stop here.

See my reply here in another thread of the same problem. https://forums.eagle.ru/showpost.php?p=4343816&postcount=18 Also, Kaspersky has been working for me for years without any problem. It is the first time in at least two years it reports me of an issue. This doesn't necessarily mean ED did something wrong, but certainly worth a check before we call it a "false alarm". We don't have visibility of the source code, so only ED can tell.

What you said is basically pack up a bag of air around the smoke detector and send it to the manufacturer to investigate. For the sake of discussion here, people surely can do that. But normally people would do it after checking around or asking the wife "hey honey, you did turn off the stove, didn't you?" The kids might help defending the wife out of pure love by saying like "how dare you questioning my mother!" But you know the question has to be asked... So the point here is, a not so insignificant AV software flagged a potential issue of ED's software. Since we don't have visibility of its source code, we don't know it for sure if a potential risk has been brought into the game file, and therefore we ask ED to look into it. Another thing to bear in mind is, it's not just virus that could trigger av software. Some software behaviours like unnecessary system authorisation, unclosed ports, etc, could also be used by hackers to penetrate your system, and therefore some comprehensive av softwares could detect and flag that as well. While it is relatively clear to tell after analysis whether a virus is there or not, it is not so black-and-white for the av software company to conclude on the nature of a game file other than its unusual behaviour. A similar example could be an email client software on your iPhone requesting to use the camera. It's unusual and suspicious, but you can't tell it for sure whether or not it will cause a problem or be used to cause a problem. That's why usually av software will quarantine the suspicious file instead of deleting it, so you still can restore it if you are sure it is alright. This again leads to asking ED to double check its software at least at source code level, to see whether the latest changes are all good and risk free. While the op asking ED to fix it straight away could be a bit blunt and “jump the gun", it is actually indeed the developer's job and Due Diligence, and of its best interest, to make sure it's software is virus free and backdoor free. What ED could do? 1. Consider Kaspersky AV's detection result, check the source code of the latest changes to make sure what it does is absolutely correct and necessary. 2. Remove those unnecessary software behaviours if identified, or change it to a safer way. 3. If confirmed nothing is wrong and nothing can be changed, the best way is to work with Kaspersky to resolve it. ED might not like it, and could be very much so for people who loves ED and everything ED does... 4. so, alternatively, ED can just say "f* it, we don't care", and simply mark it as a known issue and leave it there. In this case, we can only exclude ED's file or the entire directory from AV software, submitting the file to Kaspersky and hope they can one day update its database. But be careful what we wish for. Excluding a file or directory is exactly what hackers like you to do... And hackers have automation tools to hunt you without necessarily specifically targeting you. I'm a telecommunication professional and ex software engineer. No one need to take my word for it, but please do think about it.

You've missed the entire point mate. But I can sense your passion with DCS and ED. So, all good.

Like I said in another post, if your smoke detector triggered, you check your house making sure everything is alright before accusing the detector for false alarm. I trust ED would not intentionally do harm to it's clients, but given the current circumstance where a lot of people/devs have to work remotely from their own devices, this in turn rises the risk profile of software development and its associated security. There was a case not long ago that a well reputation developer unknowingly introduced virus/backdoor into its software because one of its core dev used a tempered compiler that he thought was legit. Not necessarily suggesting the above as the case here, but there're indeed various ways to temper a software and most of them are unintentional. Safest approach is thoroughly check it before any conclusion. Yes, it could be just a false alarm, but we don't know it for sure unless someone with the right expertise looked into it. Until then, I'd rather be safe than sorry.

nah, not the best approach. If your smoke detector triggered, you would check your house before accusing the smoke detector for a false alarm. Same situation here. I trust ED would not intentionally do harm to it's clients, but given the current circumstance where a lot of people/devs have to work remotely from their own devices, this in turn rises the risk profile of software development and its associated security. There was a case not long ago that a well reputation developer unknowingly introduced virus/backdoor into its software because one of its core dev used a tempered compiler that he thought was legit.

Experiencing the same issue here as well.

1. If you are complaining about the inbalance, well this is more of a simulator rather than an air quake game, so balance probably is not the priority. Most of the jets in game are not matching peers in many cases even in real world scenario. If you are designing and managing an MP server, you can always easily balance both sides by mixing eastern and western jets, as a lot of MP servers do. 2. If you are complaining that the simulation of Su27/Mig29 and its missiles are not accurate, present your evidence if you have any to help ED. ED has been working on this all the time, not saying what they've done is good enough, but they are working on it, and your yelling isn't really helping... The J-11 is actually not bad at all on some of the servers, and also the new JF-17.

Very well said sir! Especially the potential similarity between the current EA practice and Ponzi Scheme. Guess we'll see over time, if more modules entering into EA and less modules exiting EA (reach its Final Release)...... If you really want to do something, you'll find a way; if you don't, you'll find an excuse... Anyway, for A-G radar, it is clearly out of planned EA feature, so it probably will take quite a while, maybe years before we can see it, if ED ever put the needed resources into its development...

@BIGNEWY @Nineline It has been occurring for multiple times both on this forum and community groups that some may find that certain keys doesn't work in game although those bindings look and work alright in the CONTROLS setup page. It was later on confirmed that all such issues are due to the key bindings in UI Layer override those module specific ones. https://forums.eagle.ru/showthread.php?t=251744 https://forums.eagle.ru/showthread.php?t=254805 Once such conflict happens, DCS provides no mechanism to notify its user. Some poor guys might have to either not be able to use that key or end up reinstalling the entire DCS World, causing a lot of frustrations. Now, can ED extend DCS' existing key binding conflict detection mechanism to include those under UI Layer as well? Or if it is too hard, can ED at least put some static text on the CONTROL settings page to remind users of manually checking for such potential conflict?

检查下UI Layer里面是不是绑定了这个按键。 你的问题有可能和这个帖子里讨论的情况类似：https://forums.eagle.ru/showthread.php?t=251744

New INS? (Never mind)