Comrade Doge

While developing the new version,i have tried adding in keybinds to help with that, however that has proven hard to achieve, since DCS is the window in focus, and it does not allow to listen for keybinds outside of it. Adding global key listeners would also mean triggering anti virus softwares. So until a better method is found, I am not sure how VR users will be able to use it.

Hello, it is due to the fact that you moved the .exe away from the JRE folder (which contains Java). You can place them side by side and it will work. In the future version this will no longer be necessary

For the images above, try to spot which flight member has a PDLT on it. As you can see, it becomes impossible to discern, which breaks the purpose of the 33% enlargement of the flight member PPLI symbols - to aid the pilot in reading the symbol better.

Hello all, as always I will keep this report brief, as we know on the HSD the blue Link16 flight members symbols are 33% larger than the regular green donor symbols, but the PDLT octagon around them is not. This makes selecting a PDLT on flight members difficult, as you cannot see the octagon clearly and determine if the PDLT has been created. Here are some examples: No problems with green donor symbols, the PDLT is easily noticed: Visibility issues with blue flight members, the PDLT octagon is hard to spot, as it's not 33% enlarged as the rest of the blue symbol: As you can see, even fully zoomed in, the octagon is still hard to spot. Further zoomed out it's basically impossible to tell. This can be easily fixed if the octagon would be 33% larger than usual if it's being placed over a flight member. As a sidenote, I also noticed is that the TMS up action is not registered until you are well within the symbol area with the cursor, my guess is that the 33% enlargement of the blue symbol didn't also enlarge the TMS Up trigger zone for the PDLT, again, something easy to fix. Thanks and have an easy week. PDLT size.trk

I'll see what I can do, but at the moment the priority is releasing the V2 version with already existing modules

Please wait until I release the next version, I have already overhauled most of the modules until now.

I will consider adding support for them in the next version, assuming the systems are similar to the ones in existing modules

Hello, if I had a VR headset I'd probably try and make it work, but the issue is that I'm not familiar with developing VR applications at all... However, I am in the middle of rewriting the whole application to allow for keybinds to be used, and that hopefully can alleviate some of the VR issues. If they don't, you could load up a file which you have created in a 2D environment and import it when using VR, and just transfer them right away.

Thanks for the response. I have a few more questions regarding this behavior: What you said would apply if the target has not been previously decided to be hostile, and in that case indeed there need to be further analysis to make it so. (Absence of absolute ID) But in my case here, the ROE have already been met for a Hostile criteria, as a Hostile track is being shown by Link 16. This means that some donors on our net successfully met those ROE criteria, and marked it as a Hostile. The F16 has no reason to override such ROE with it's own, if it doesn't find conflicting information. But in this case, no such thing happened, the mere painting of the target with the FCR is enough to override ROE decisions, even though the Hostile nature of the target wasn't proven wrong by any system, or contested. I can PM over a few publicly available sources to back this up, if needed.

Hello all, reporting some behaviour I've noticed following the latest update, I will keep it brief: when we have an uncorrelated (hollow) Hostile Link16 track and we spot it with the radar, it turns into a Suspect track (yellow filled). At first glance this does not look like correct behavior, as the FCR has no say in determining ROE and no reason to change it from Hostile to Suspect. No IFF was involved here, just the mere painting of the target with the radar turns it into a Suspect. I'm sure many would appreciate if this could be taken a look at, if it's a bug, or WIP. Thanks and have a nice week ROEchange.trk

For the next version I will try to implement keybinds which hopefully will solve the issue.

In that case it should work as expected, assuming the mod replicates the original Hornet cockpit layout

Hello, unfortunately I am not aware of a method to implement this for FC3 based modules... their waypoints must be declared in the mission file

I am aware, it will be fixed in the new version.

I am currently in the middle of rewriting the whole codebase including the lua files, so it's a good change I will spot any issues. In the meanwhile, send me your dcs.log file in PMs and I'll see if I can get further clues

Waypoint 1 should be your starting position. TheWay always increments to waypoint 2 to not override it. In this mission though it seems like you don't have any home position set.

I am not too certain how the VR moise interaction happens, I have not owned a headset ... but if you can somehow have the GUI accesibile, either by a keyboard shortcut, it should work as normal

A solution I can think of for VR is to have key binds implemented, so that you can operate the GUI while in the VR environment. I have this planned but the code is not ideal currently and needs to be rewritten from scratch. This will make up version 2 of the program. I have only recently begun writing it.

Yes. I know it's been a while, but I'm planning to get things back on track

Hello all, I will keep this brief, we know that if the Search option on the RWR panel is not pressed, search radars will not show on the RWR screen. However, it seems like the new contact sound still plays regardless of this filter option. Attached you find the trackfile for an SA-10 search radar triggering the new guy sound, even though it is not visible on the screen (filtered out by the Search option). Thanks and have an easy day! RWRsearchModeSound.trk

@BIGNEWYThe evidence is present in the MLU M3 manual, pages 76 to 78. I believe this thread also points at this issue, but it was locked... https://forum.dcs.world/topic/291702-hmcs-acm-bore-fcr-gimbal-limits-symbology/

Indeed, and neither the radar lock should play any role in color or shape (ROE). Yet currently, it does for some reason, changing an ROE of Hostile (decided by Link16), into an ROE of Suspect.

I think he meant red filled triangle, which is correct symbology based on M3

In that case a bump of this issue is needed, as it's a core function of the missile.

Hello everyone, it has recently come to my attention that the AIM-9, while in Slave mode on the SMS page, will not actually slave it's seeker to the RADAR Line Of Sight. Instead, once an STT lock is gained, it is stuck to the boresight cross. However this is incorrect, as the AIM-9 seeker should be immediately "slaved" to a radar lock once that is gained. This is what "slave" mode refers to. The evidence is supported by the publicly MLU M1 update manual, page 139, bottom of the page where the AIM-9 SMS features are described. Additionally, further evidence can be provided in PMs with community managers, if desired. We can also see this video of the AIM-9 seeker head immediately slaving to the RADAR lock. I know this video is not the exact F-16 version we have in DCS, but this particular behavior of the AIM-9 should be the same: https://www.youtube.com/watch?v=VBWBnBrMUfkI have attached trackfiles for both AIM-9X and AIM-9M. Thanks and have an easy week! AIM9MSlaveBug.trk AIM9XSlaveBug.trk