FalcoGer

Same as linked thread below, but the issue has reappeared since it was fixed. The thread was marked "fixed internally", but for several patches this issue has remained. To reproduce: Enter attack phase Enable threat rings in show/threat show page place tg with ident "ZU" Expected result: threat and detection ring Actual result: no ring Notes: rings for threat points that are available from mission start and auto placed are visible. tsd_no_ring.trk

The gun elevation was invalid due to the range. The target was co-altitude and in range, it was well within the gun traversal limitations. But if you want I will make another track and fly higher.

@Lord Vaderhere is your track. I don't know why george thought he'd call "in range, ready to fire", and I don't know what made him re-lase at 4100m, and then continue to not fire. He doesn't do that all the time, more often than not he just doesn't shoot. Again, my recommendation is that george does a ranging whenever you tell him to fire, or to just keep the laser on. When in automatic fire mode, he should do a range every few seconds. @some1 thank you. george_stale_laser_range.trk

@Lord Vader DCS AH-64D early access guide. Page 296: If the laser ranger doesn't see the spot, it does currently not enter laser range as range source. The other document I was referencing says the same thing. The range source switches to laser range when the CPG fires the laser, no conditions attached, such as a valid range. The asterisks should only illuminate solid when a valid range is detected and flashing if it detects multiple ranges (such as when lasing through foliage or the edge of an object) Common logic dictates that 9999 should be used when the spot is not visible to the system, as that would usually indicate a range where the laser spot can not be seen. While the other document does not state either way whether it goes to maximum range or not. @Raptor9 Maybe someone who actually flies the thing can say how it behaves when the laser spot is not detectable to the TADS such as when lasing something very far out of range or the empty sky.

I would be happy to provide a track. Unfortunately you don't allow me to.

Sometimes when george had a laser range to a target that is moving and then switching him over to guns he stops lasing. Then when asked to fire, he will say the target is out of range, even if the target is now in range. The laser range just gets stuck on some value and george doesn't understand that that value is stale and refuses to fire. Just today I had a Mig-29, coming straight in and at me, George had an IAT on the jet, and I asked him to shoot the gun, but he stubbornly refused because his laser range said that the target was 7000m out when it was maybe 2500m away. I'd like that if asked to fire, that george would re-lase the target before deciding that it is out of range based on stale laser range. Alternatively just keep the laser on while the gun is selected.

I have had similar experiences, me flying around and the CPG saying we're still on the ground, and on one occasion me staying on the ground while my pilot was flying around. It's rare though. Usually restarting DCS solves the issue.

The Cued LOS symbol (the dashed crosshair) does only appear on the IHADS, but not on the TDU when slaving. The dots indicating the direction to the cued LOS symbol are pointing away from where the TADS actually slaves to. To reproduce: Store a target point with the TADS Set that point as acquisition source Slave with TADS as sight Expected result: Both IHADS and TDU symbology are the same Actual result: IHADS shows the cued LOS symbol moving to the center as the camera points to it. TDU shows cued LOS symbol somewhere else, usually not even on screen at all. no_cued_los_on_TDU.trk

It also works the other way around. If you select TADS first as sight and then link, the radar will turn towards the TADS. This might also be useful, because you can't slave the radar to the tads otherwise. this is because to slave the radar, the radar needs to be the sight. but if the radar is the active sight, you can't move the tads to slave the radar to it. So LINK is helpful to: Visually identify an FCR contact (FCR as sight, then LINK) Scan an area that you point your TADS to from the front seat (TADS as sight, then LINK) I imagine radar controls (Scan burst) are available when LINK is active in either mode.

laser range not 9999.trk

When the laser does not get a valid return, it should display 9999. But now the range stays what it is when the laser does not get a valid return. This happens when lasing a target that is to far away (greater than 15km) or when lasing the sky. To reproduce: Lase something within 10km to get an accurate range Lase the sky Expected result: Range 9999 Actual result: Range stays the same as the accurate range determined to the previous spot. Related: Get a range using a different range source (Set man range to 2000 for example) Lase the sky Expected result: Laser range 9999 Actual result: Stays Man range 2000

The laser will not fire when your LST is in MAN mode (or auto, but that's more noticable). Maybe one of your hotas switches puts LST into manual mode with sync cockpit controls without you noticing, or you accidentally click through the TDU frame onto the LST switch on the right hand grip by accident. When I find myself with a non functioning laser, I go through this checklist. Sight Select - TADS Master Arm - On WPN/UTIL/Laser -> On LST - Off

Why way this moved? Even if the tool was faulty, it shouldn't result in desync between the cockpits. All the tool does is cause button presses, it does not interface with any code or memory of dcs directly and only interacts through the buttons in the cockpit. it just so happen that the timing of the button presses causes the issue. In other words, the tool can't be fixed. I press the right buttons. The issue is with the module. If you do not wish to install my tool for security reasons, i can provide the json data to send over a tool like netcat to the lua export script instead. the lua script will interpret the data the same way as though it came from the tool. alternatively i could provide a lua file with the data baked in. but I won't bother wasting my time unless you intend to investigate the issue further. Perhaps the next time you could reach out for further information and/or assistance instead of concluding it's my fault, move the topic and label "can't reproduce, it's your fault" without a comment.

I wrote a tool that can enter preset data for the AH64 rapidly by using an exports script. However using this rapid data entry causes desync in that the back seat has the correct frequencies and the front seat has the incorrect frequencies on the presets. For example on preset 4 the backseat has FM2 on 35.0FM while the front seat gets the default 30.02FM. Furthermore, this happens even if the copilot joins later after the presets have been put in. To reproduce: Join busy server Have your buddy join Use coordinate converter to input preset data rapidly. Seems more prone on FM and UHF, but could be random. not sure. Select seat after joining aircraft Select Menu/DCS/Aircraft/AH64/DTC... In the Radio Presets tab select the preset you want to change In the bottom enter frequency data for that preset by ticking the checkbox and then enter the number repeat for a bunch of presets (go to step 3) click the play button on the top Observe com page discrepancies between the two players Tracks attached. Georgia At War v3.0.24_evening-20240420-180921-plt.trk Can't attach CPG track due to size limitation. Please update allow for larger files. This track will be deleted from google drive whenever I feel like it. https://drive.google.com/file/d/18Gb3TsynNAkaRU3R7rbtoLJVe7YTOYKG/view?usp=sharing

I installed DCS on a 256GB M.2 SSD, but after buying 2 additional maps, the space quickly became too small. I then made a directory junction As admin: New-Item -ItemType Junction -Path "F:\Eagle Dynamics\DCS World\_downloads" -Value "C:\Games\DCS_Links\_downloads" and also one for /mods/terrains/ I tried installing Syria and Siani, and the installer reports that there is insufficient size on F:, however there is sufficient size with the directory junction in place. Installing syria, then siani separately works just fine. However, during any update after that I have to uninstall and reinstall them one by one, which is quite annoying. It would be really nice if the installer could detect if the files are installed on another drive and check the correct size requirements for each drive used.

Don't have it. Can't test and don't have the files for the input stuffs. It's modular enough. Feel free to create a pull request.

If neither pilot can get to the power levers, why would they be able to get to the chop button, which is much smaller and also guarded? Wouldn't that be even harder to action?

No. the new line can be placed anywhere in the exports lua file.

Did you edit/create the exports script and placed the lua file into the exports folder as well?

You are right. It's not useful to have them both be the same. But it can't be separated because I can't figure out which one is currently selected because it's a toggle and I can't access the display graphics or DCS's memory in any (legal) way.

This is labeled fixed. But just yesterday george as pilot was reacting to VRS by just raising the collective until torque was 160% at which point I had to take over myself.

I wasn't talking about taking fire, but having an engine fire. Identify affected engine Throttle affected engine: off Affected engine fire button: push Fire extinguisher primary: push consider dropping external stores if engine fire persists, discharge secondary fire bottle land as soon as possible

I'll look into that. That is a bug.

The project gets build by automated github actions. I doubt their toolchain is compromised. I didn't build the executables that you are getting myself. Other than that, the source code is available. While I can not 100% vouch for there to be no exploits possible that could lead to malicious behavior, I can guarantee you that no malicious behavior is intended. The only difference between 0.6.10 and 0.6.11 is some text changes for the AH64 point ident descriptions and the version number. All of this is well documented in the github history. You can and should always upload suspicious programs to virustotal. The program does make a web request (to check for updates), which may lead to some false positives or weak results (like 'suspicious') for some obscure virus scanner vendors. Here is the analysis of v0.6.11 on virustotal. One or two positives are not something I worry about, especially from vendors I never heard of anywhere else, especially for unsigned executables.

You can already do that. You just have to enter the coordinates manually.