FalcoGer

Is there perhaps an explanation on why the aircraft sometimes and suddenly rolls over? I don't mean the somewhat gentle and tame roll to the left during full forward stick, I mean the 360° rolls in 3 seconds out of nowhere at low speeds.

I know this isn't exactly a bug, but it's just disappointing. The IAT is both too good and too bad at the same time. The issues I have with it right now are There is an arbitrary hard range limit on IAT. Even if the tracked target fills out a good portion of the screen with good contrast, you can't keep track of anything beyond some range, even if it's a huge object like a house. I think that range might be 15km, but I could be wrong. When fully zoomed in with TV view, you can usually see medium sized targets, like tanks, quite well, but the IAT just doesn't pick them up. Just today we were tracking an SU-25, and it flew away. It was still pretty big in the picture but suddenly the track just dropped for no reason whatsoever. It can start tracking things behind bushes and trees, despite there being no clear line of sight. I'm not talking about inertially tracking things that were tracked already when they go behind concealment, it just straight up detects stuff behind concealment like bushes and trees from the start, including their shape. It magically detects whether a unit is alive or dead. You can't track a dead, burned out tank. When one is unsure it can be used as a detector. The problem with all three issues is that IAT doesn't actually use contrast locking but detects units and map objects via ray casting (finite length, goes through bushes) instead of using some form of image analysis. There are some primitive algorithms to do what's basically contrast lock. OpenCV has a few, very efficient tools that can be used. The issue with DCS would be that that image needs to be generated and it needs to be the same for all graphic settings. It also needs to be cheat proof. From what I can see from Apache videos that use IAT, the way it works is basically a flood fill with a contrast threshold and/or maybe a small blur filter and then creating a bounding box around the resulting shape. There is no reason to go full AI (neural network), that would just eat the framerate.

Oh my... That's quite the range. I think you got the wrong unit there That aside, the issue isn't that the Apache can't detect above 10km. It might very well be able to do that with the equipment. The issue is that there is a software limit. Right now the laser doesn't behave right. It shows 9999m between 10km and 15km, like it should, but still gets the correct range on the TSD and when storing target points. Above 15km it just doesn't update anything, which is also wrong. It should just say 9999m if it doesn't get any energy back. The current hard limit for laser range in DCS is a slant range of 15000m. Aka the laser is a single ray, cast from the designatior with length 15km. As far as I can tell, there is no real limit to detection of that spot. Another thing to add would be that if I were to fire the laser at 12km, even if I can't pick it up, the laser should still hit something. If i then fire a laser guided missile in the general direction, it should be able to pick that up after traveling maybe 4km or so.

The only ways to tell from the back seat if the laser is on are: TSD shows TADS line of sight in white VID page is open with TADS as video source and you see the X or the * in front of the range You are in rocket coop mode and get laser range as your own range source If you mean the cued line of sight reticle (the dashed plus symbol), that's showing you where your acquisition source is and it has nothing to do with the laser. You might want to read ED's or Chuck's guide or some other documentation on the Apache's systems and their operation. There are a couple of good tutorials on youtube as well. I think you should learn the concepts of operation, like what a sight and what an acquisition source is and how points and routes work, what a range source is and what the symbology means.

Helicopters with turboshaft engines always set full throttle during flight. In the Apache that is the "Fly" position. The Lockout position disables the automatic torque matching for that engine in case of a failure of the control unit, so you shouldn't normally use that position. Just put it in fly and leave it there. There is no such message like "RPM Roll". It might be "Rotor RPM Low", which would indicate that you don't have the required torque. The engines try to match the torque to have the blades spin at a constant RPM. You don't get enough torque if you don't have the throttles open all the way or when you pull too much collective and the engines can't provide enough power to keep them spinning, in which case you need to reduce the collective. You get a "Rotor RPM High" warning if the rotor spins too fast. This can happen if you windmill it too quickly, for example you pull out of a steep dive, or when one of the engine controllers fails and commands full power despite it being not needed. In that case you need to manually adjust the throttle to keep the rotor RPM near 101%.

Had this a couple of times. Also had a few instances of desync, even on self hosted hunting grounds. Pushing the throttles just slightly above idle during start seems to work, but might have been coincidence (small sample size). But that approach had the CPG's engine die while the PLT's engine did what was expected, leading to some massive desync issues, including power failure in flight due to over-torque (230%+) and subsequent INS reset, etc. I should have the track, but the issue happened during the second flight and that's like an hour in, and the track is huge anyway because it's hunting grounds with a lot of voice messages. Also would be nice if this were moved to bugs.

I have the thrustmaster warthog and it works just fine for me. I am able to get all important bindings for both stations, including FCR. The ministick is a bit of a mess, I agree, but it works well enough. For the CPG station I added a modifier on the EAC ARM switch and this allows me to rebind everything for flight controls. In the CPG station I use the main stick as the man track controller and the ministick as cursor controller. If you want I can lay out my mapping for you, and as far as I can tell, nothing is missing, except for CHOP, which makes no sense to me anyway. Warthog Apache PLT Apache CPG (Exactly the same as Apache PLT with EAC ARM incl. WAS on Cyclic) Stick Trigger Stage 1/2 Weapons Trigger Switch Stage 1/2 LHG Weapons Trigger Switch Stage 1/2 Weapon Release (Pickle) CUED Search Switch - Depress LHG CUED Search Button Pinkie Switch Tail Wheel Lock/Unlock Button - Depress RHG FLIR Polarity Button Paddle Switch IHADSS show RHG LRFD Trigger - SECOND DETENT Master Mode Button Chaff Dispense Button - Depress RHG Sight Slave Button TMS U/R/L Weapons Action Switch - G/M/R LHG Weapons Action (WAS) Switch - G/M/R TMS Down Flare Dispense Button - Depress LHG STORE/Update Switch - STORE/Center DMS R/D/L/U FCR Scan Size Switch - R/D/L/U RHG FCR Scan Size Switch - Wide/Medium/Narrow/Zoom George AI Helper - R/D/L/U CMS R/D/L/U Force Trim/Hold Mode Switch - R/D/L/U LHG TADS FOV Switch - Wide/Medium/Narrow/Zoom Trim Hat R/D/L/U FCR Mode Switch - R/D/L/U LHG FCR Mode Switch - RMAP/ATM/TPM/GTM CMS Depress Emergency Jettison Switch - Depress LHG Linear Motion Compensation (LMC) Button Throttle Ministick Depress Cursor Enter - Depress LHG Cursor Enter Trigger Comms Hat Depress RTS Rocker Switch - Down RTS Rocker Switch - Down Comms Hat Up George AI Helper Interface - Show/Hide George AI Helper Interface - Show/Hide Comms Hat Forward Reserved for SRS (Special Intercom Select & PTT) Reserved for SRS (Special Intercom Select & PTT) Comms Hat Down Consent To Fire RHG MTT Promote Switch - Fwd/Center Comms Hat Aft PTT/RTS Switch - RADIO/Left (call radio menu) On small delay (200ms) for SRS (PTT) Reserved for SRS (PTT), small delay (200ms) Coolie Hat U/R/D/L Sight Select Switch - U/R/D/L RHG Sight Select Switch - HMD/TADS/LINK/FCR Air Brake Switch FWD/AFT FCR Scan Switch - C (Continuous)/S (Single) LHG FCR Scan Switch - C (Continuous)/S (Single) Boat Switch FWD Boresight/Polarity Switch - PLRT LHG TADS Sensor Select Switch - TV Boat Switch AFT Stabilator Control Switch - Depress LHG TADS Sensor Select Switch - FLIR China Hat FWD/AFT Symbology Select Switch - Up/Down LHG Image AutoTrack/Offset Switch - IAT/OFS Pinkie Switch FWD/AFT PLT NVS MODE Switch - NORM/OFF PLT NVS MODE Switch - NORM/OFF Landing Gear Warning Cancel Master Warning Button Master Warning Button Flaps UP/DOWN Stabilator Control Switch - ND/NU RHG Laser Tracker Mode (LT) Switch - A (Automatic)/O (Off) RDR ALT ARM Emergency Jettison Guard - OPEN — EAC ARM EMERG HYD Pushbutton - ON/OFF Modifier for flight controls. Also used with the C-key to request controls. Autopilot Engage/Disengage A/S Pushbutton RHG C-Scope Button Eng Oper switches L/R D/U No.1/2 Engine Start Switch - IGN ORIDE/START —

I haven't noticed that. Did you update? What's your DCS version? Can you upload a track?

This is a regression issue. Just had this in the hunting grounds mission (syria). FAT was 29°C. A few issues appeared. Couldn't start ENG2 after ENG1 Could start with a tiny bit of throttle above idle on ENG2 during start, might be coincidence though. Human CPG reported Engine 2 not running for him, spooling down like it would on a failed start attempt, so he gets rotor rpm low, ridiculous torque values on engine 1 and occasional power failures (with inu reset and everything). Massive desync problem, because instead of simulating the engine once and sending the data over the network, the engine is simulated on both clients independently. Couldn't make a track file and couldn't reproduce on Caucasus.

Not sure if related. When I put in an engine fire failure in the mission editor, I get the Engine 1 Fire message only once. The A/C Engine page autopages, Engine 1 Fire indication shows on the fault list. No actual fire is visible outside of the aircraft and all indications stay normal (torque, temperatures, etc all remain where they are). Also the master warning button does not illuminate. Engine fire buttons do not shut off fuel. I thought the voice message would repeat unless the problem is either fixed or the master warning button is pressed to acknowledge the issue.

When I pull more collective, especially on takeoff, I get rotor RPM high if I pull too much, too fast. I find that curious as I'd have guessed that pulling collective increases torque requirement and thus slowing the blades down initially before the engines respond. Is that right or is the PID just over-responding to the demand that it thinks the engines will need to provide? It just seems strange to me. It also feels like I pull collective gently enough, so to avoid the warning i have to be really slow on takeoff with the collective. it feels off.

It's not strictly a multiplayer issue. It happens in single player as well. AI locks up another AI, the player (or all players in front of that AI in an MP setting) gets the spike. The issue is that there is no INS guidance after the target radar was shut off. It is public knowledge that the missile ought to guide to the last known position using INS. BN marked it as correct as is, perhaps due to a misunderstanding. EOM mode uses INS guidance, CEP is a few tens of meters, clearly showing that the missile was guiding. But with the radar shutting off, suddenly the CEP is a few miles. The evidence was presented that the missile doesn't guide, the evidence being the 1G turn, massively different from actual INS guidance of the very same missile in DCS, and instead goes ballistic. It's real info, and physics is not under the protection of some secret document. I'm not asking you to defend yourself because I am not trying to attack you. I'm asking for better communication, because ultimately that's where I think everything breaks down. I don't think I can add any more of value to this topic.

Related, but different to The behavior of the laser range finder is not correct: When lasing > 15 000m, then the range source is not updated Correct behavior: Should switch to laser range as range source (and show 9999m) When lasing > 15 000m, then the range is not set to 9999m, even if laser range is the current range source Correct behavior: display 9999m, TSD laser LOS limit to 9999m When lasing between 9 999m and 15 000m, TSD laser LOS indicator shows ranges > 9999m, can mark targets Correct behavior: display 9999m, TSD laser LOS should be 9999m as well, not actually show the real range. Targets marked in that range should be 9999m away with their altitude above ground to maintain LOS angles Track attached To reproduce: Get in CPG seat Set range source to something other than laser range (for example man range) Lase something > 15km away Notice range source not updating (Bug) Get in CPG seat Lase something close by to set the laser as the range source Lase something > 15km away Notice the range not updating and staying the same (Bug) Get in CPG seat Lase something at 9999m Watch TSD as you slowly move the laser further out Notice the laser LOS following the laser above 9999m despite the display reading 9999m (Bug) Store a target point between 9999m and 15000m Slave to the target point Note that the altitude of the target point and range to the target point is accurate and also between 9999m and 15000m (Bug) laser_no_update_gt15km.trk

I'll try again and make a video. Edit1: I just had a play with it from a cold start. You can't use the keyboard to press the CDU buttons while the power is off, but you can click the CDU buttons with the mouse. My issue was with a hot start though. I'll play around with it some more. https://www.youtube.com/watch?v=rxo1iTKl-Xg Edit2: I had a play around with hot start, couldn't reproduce the issue. Curiously the back key was unbound after I assigned it last time.

Probably related.

They really should increase the file size limit on here. Another option would be some form of cloud storage, like google drive.

Well even if people provide tracks, data, graphs, evidence and logic, then a lot of bugs are not followed up properly. HARMs not using INS. With evidence from tacview data graphs (a lot of them) of track files (a lot of them) and the logic of 1G means they're not guiding to anything, as well as actual INS guidance (EOM mode) looking different (not 1G) and they actually hit somewhere near the target. Verdict: Correct as is, topic locked. Objects not being cleaned up properly. Destroys long running servers' performance. High impact bug. Result: "Can not reproduce" for half a year. Then Flappie got to it, reproducing the issue from the data provided in short order. Actual communication taking place with that hero. He asks for stuff, he gets the stuff to find the root cause. People are in fact willing to help and go the extra lengths. One of mine. FPS issues when using TV mode and looking into the woods (FLIR works perfectly fine). Maybe just me, not sure. Provided track with the first post. Labeled "can not reproduce". Provided video evidence, no further communication. No asking for information, no follow ups, just silence. Then there is stuff like the recent patch. "Added: IAT now syncronized". Then I'm flying for 5 minutes and IAT desyncs when using LMC. Surely one couldn't blame me for coming to the conclusion that testing wasn't done thoroughly enough, especially since this was the big new thing and the patch was in development for over a month now, granted with a christmas break in between. I submitted a bug report, but it certainly doesn't scream competence when "Fixed bug" in patch notes and 5 minutes afterwards the same bug is found when I'm not even specifically testing the feature with all the variations like it should've been done after implementing it. Again, it's EA, one expects bugs, that's fine. But I'm sure you can at least see where I'm coming from here. This one has been here for 5+ YEARS. Mig-29 locks anything STT, whole server gets spiked. Not 5 months, 5 years. Are you kidding me? And that's not one of those "windscreen wiper knob doesn't turn to HI without generator power." RWR is a major feature in DCS for all aircraft that have it, it's very visible and obvious, it's been reported many many times now. Why is this still a thing? Sure it doesn't blue screen the computer, but it affects basically everyone. How can this be? I can understand most things, but those are just incomprehensible to me. And that's just a tiny sample of the things that have been going on. I could go on for pages. I'm sure everyone is working hard, but maybe the methods are wrong. Or you just need more people.

The current behavior of the laser is still bugged, as far as I can tell. Range 0-9999m: Displays range accurately (Correct) Range 10000m-15000m: Displays 9999 (Correct), TSD updates the laser line of sight and range to match actual range (incorrect, should be 9999m) Range >15000m: Doesn't update range information, doesn't even change range source, it stays last valid range source, for example man range, nav range, etc. If the range source already is the laser, no updates are made. For instance you lase the ground in front of you at 50m, then lase the sky, it stays 50m. (incorrect, should be 9999, TADS should also show laser LOS with length 9999) I am pretty confident that it should always switch to laser range as source and display 9999 if the apache doesn't get the laser energy back, such as when lasing the sky or very far terrain. I think right now, the apache gets laser energy back at say 12km, processes 12km, displays 9999 and updates the TSD to show 12km. If there is no return, because the laser stopped at 15km, then no processing takes place at all where it should be processed that, in fact, nothing is returning.

I've had the very same issue in the A10C-II today. Bound it to my backspace key. Is that what you bound yours to here? I'll try checking for this tomorrow.

I tried binding the key "CDU Key - BCK" to my backspace ("back") key on my keyboard. Pressing it doesn't work. I double checked that no modifiers were pressed at the time. Pressing the key with the mouse works as expected, the key performs it's function (deletes one character in the scratchpad) and is visibly depressed. When pressing the back key, neither the function nor the visual are working. I have used the back key in other aircraft and it works just fine there and it also works outside of DCS. I didn't check binding any other keys to the CDU BCK key. Edit: Update below.

Okay then. Thank you for your time. Also the army should fix their helicopter.

So I move my head, super smooth, left to right and very slowly, and the TADS just goes completely wild? That is correct? And the CPG moves his head the same way with GHS as ACQ and it follows the movement super smooth. Is that right? Because something doesn't add up there.

It's normal for the TADS to jump around by like 3° in all directions? I mean you haven't even looked at the track. What's more, it doesn't happen when George slaves to PHS. It also doesn't happen when the CPG slaves to his own helmet.

When the CPG slaves to the PLT HMD, the TADS line of sight jumps around a lot. Steps to reproduce: PLT sets TADS as ACQ CPG slaves to PHS PLT looks around a little. During movement the cued line of sight reticle as well as TADS video on the MFD jumps around quite a bit. Server track is me as PLT, client track is CPG. Ah64Issues-20230126-233247.trk server-20230126-223145.trk