FalcoGer

When flying with a human player, the setting in TSD/Util to display either local or zulu time randomly jumps back to the previous value. Pardon my french in this video. between a generally a bad day, framerate issues for no apparent reason, lots of bugs with the aircraft, george not being able to hit stuff and me getting shot down as a result and the server crashing I was quite frustrated at the time. Issue at 1:27:17. The first press randomly worked. It usually doesn't. I press it a few more times and the bug appears.

your link is broken.

He was always going over for me. Here is the actual flight where this happened. He shot 10 missiles, and got 1 hit. Sorry for my french in the video, it was just really frustrating overall between a generally bad day, some ridiculous framerates for no reason at all, bugs, server crashes and my own ineptitude at times.

I have a Nacon GC-100 connected in XInput mode, emulating an xbox controller. The Z axis on that controller is shared between the left and right trigger in such a way that pressing neither trigger has the axis be on 50%. I do not use this controller with DCS, so i set it to DISABLED in the control options. In the AH-64D apache, the default for the Z-Axis on that controler is the collective. If the controller is connected, then the apache starts with the collective applied 50% even though the controller is disabled. If I remove the Z-Axis assignment from the controller, the apache starts with the collective value of the controller (my thrustmaster throttle) as it should. I think the sync hotas controls doesn't check the disabled status of connected controllers. I didn't check for other aircraft, but this should not happen on any of them. Disabled means disabled.

It started happening again. I believe it might have to do with my Nacon GC-100 connected in XInput mode, but that controller is set to DISABLED in DCS, nothing but it's presence in the controls screen should be affected by it being connected, least of all flight controls. This shouldn't be happening. I will start a general bug report for DCS

He also happily anounces "engaging" and then not shooting when you give the fire command, even when out of constraints.

George reports the rapier optical and radar trackers as SR Sams while the launchers are LR Sams. This makes no sense at all. He should report the Trackers as trackers and the launchers as launchers, not some weird sam categories. Track attached. george_cant_hit_rapier_tracker_6500m.trk

George has some serious wobble left and right that a human gunner wouldn't have. I have had issues with george being able to hit a rapier site from around 7000m, and I shot 10 missiles, every one of them landing in the sand. I was shooting from a hover at around 50m using the automation with some slight wind (7m/s). Even in a mission with 0 wind and a perfect, stable hover, george can't hit a rapier tracker from 6500m. While not easy, I can manage to do the feat in less than 10 shots and so should george. Track attached. george_cant_hit_rapier_tracker_6500m.trk

Sometimes your pylon gets shot off. At least for hellfires, I think the aircraft should detect a failure state. In the pylons are the pylon interface units which are connected to both the weapons processors and the system processors among other things. I imagine the aircraft would notice if they were not connected (missing). If not that, I would imagine that at least the hellfires, which send their status to the aircraft (ready, tracking, bit failed, etc), would be detected as failed. Other failures are indicated with a yellow box and the message FAIL beneath the pylon on the WPN page and a failure code on the missile itself. I would think that if a missile didn't respond (missing because shot off) it would detect as failed. How would the actual aircraft respond to a pylon being ripped off in flight? Would it indicate the hellfires as failed? If so with what failure message? Would it detect rocket pods as failed? Would it show any other message on the EUFD, even if no weapons were loaded on the now missing pylon? Other items exist in that pylon after all, such as the CMWS cameras, would that throw a warning?

Ever since the TSE was implemented, I found it to be plenty accurate. Still doubt 3 direct hits would kill a BMP, but what do i know. Certainly would blow up the tires, antennas and optics. On the other hand, still doubt that 10 3m misses would leave infantry in a fighting state. From what I gathered it's like a small grenade launcher. Shrapnel everywhere.

The permissions system really needs some changes. When the pilot's game freezes you can't take control because he's unable to click accept. When you just want to take control you can't do so quickly because he needs to grab his mouse and awkwardly place it relatively precisely to click accept, which in a pinch is not ideal. In VR the pilot might not even notice the control request because the windows don't pop up in an absolute position but float around in a fixed position relative to the cockpit. Then you might want your CPG to handle your throttle but not your flight controls, currently impossible. I really don't see an issue with last commanded position overrides the previous position. More options are always good. They just need to be in the right place. For example FCR mounted doesn't belong in the ME but in the rearm screen. This gives both players and mission makers options. Don't want apaches to fly with radars? Prohibit them, done. Want to fly without radars anyway despite them being fitted in the ME? Pull them off. Instead we get more complexity at the wrong position, check boxes that need to be remembered to be checked or not checked. Want to hand over controls without authorization requests? Well, you better hope the mission designer put the drop down list to what you prefer, because you get no say in it. That belongs into the special options for the pilot, not the mission editor. That's a player preference (aka options menu), not a mission or aircraft thing. And finally Want your CPG to be able to handle your throttles for you in the case of a DECU failure? Well, that also belongs into special options. I don't see an issue or conflict past anything we have anyway. For example every time you switch control, even now, if the aircraft is not trimmed beforehand you get a control conflict because your stick will be in a different position than the other crew member's stick at the point of handover. How is this solved in DCS right now? Correct: It isn't. Last input overrides the previous input. You don't move your stick after handover, then nothing happens. any axis value changes and the aircraft stick snaps to a new position instantly. I agree that this will cause issues, for example an unstable axis being bound to throttles on the copilot that twitches values between say 2 and 3 (out of 100), despite being pulled all the way back and should be a constant 0, which would not be interfering with the pilot's input. This would prevent throttles to be applied, but that can be solved by having the CPG unbind the axis or at least having a modifier on it.

Yes. The C-Scope button puts the radar contacts on a C-Scope*. In particular it puts FCR Target icons on the TEDAC and HDU, depending on the sight. For the context of this discussion, I thought the icons on the TEDAC scope were yellow for some reason. Are they? If they are not, what color are they instead? And since we're on the topic, are they green on the HDU? Surely they are. * Radar scopes: A over B meaning A is on the Y-Axis of the scope, B is the X-Axis. We get the bold marked radar scopes for the apache B-Scope: Range over azimuth, box format and distorted. Known from many fighter aircraft radar scopes. We also get this in the apache on the FCR using the RMAP radar mode C-Scope: Elevation over Azimuth. Also known in DCS for example in the hornet's AZ/EL page. We get a C-Scope overlay on the TADS and HDU upon pressing the C-Scope button on the HOCAS/TEDAC or the FCR MFD format page on T1 when in RMAP, GMT or ATM radar modes. PPI-Scope: Plan Position Indicator. Undistorted scope in the form of either a circle or a circle segment. Known from the mirage radar for example or typical air traffic control radars. We get this using the GMT or ATM radar mode. Old stuff: A-Scope: Detection strength over range. Old school ranging scope only. Hardly used anymore. RHI-Scope: Range-Height Indicator. Found in some old sam systems. Elevation over range. J-Scope: Old, circular scope, radar return strength indicated in spikes on a circular graph indicating azimuth E-Scope: Old scope. Elevation over range. Since the display is distorted into a rectangular scope, the same elevation is on a hyperbole path. In DCS we see this for example in the A-4 community mod when in profile mode. F-16s with TFR functions (not the US version we got) also have this on the TFR MFD page. We also get the terrain profile radar mode for the apache. This will display terrain contour lines at different ranges. More information here: https://www.radartutorial.eu/12.scopes/sc04.en.html

For george I'd agree that there should be some kind of indication of what he's targeting. The apache itself doesn't care what you shoot at and won't inhibit weapons fire.

Easy solution: the latest input would be used for the actual value, just like with flight controls. When you hand over controls, the values stay the same until you make an input, at which time the value jumps, which is why it's a good idea to trim (in DCS) before handing it over. I for one don't use an axis bind to bind to the throttles, because it's just not needed and I don't have too many spare axis to give away to something that's generally staying the same all flight long anyway. So I just use num+/num- or the mouse with click and drag, both of those options would work just fine since they use relative adjustments instead of absolute values like an axis would. Consider this: Both Pilot and CPG use a springless cyclic, one goes full left, the other (without effect because they're not in control from DCS' point of view) goes full right. Then the controls are transferred. Obviously you can't physically link the joysticks, unless they have force feedback. What now? You get the same problem. It's the same problem with the same solution. Last input is the value used. Unless the CPG moves the stick after control transfer, no action is taken within DCS as the axis values are not updated.

Aren't the C-Scope overlay icons supposed to be yellow?

Couldn't you wear a single tube NVG on your left eye while using the HDU on the right eye? Or would that be too awkward?

The wheel brakes are controllable by both pilots simultaneously, and I would like the throttle to be the same. In the event of a DECU failure, the non-flying pilot may manually adjust the throttle to match the torque on both engines for the pilot flying. As it stands now that is not possible since the pilot flying is the only one who can move the throttle levers.

rockets tend to fall short for me even around 3km by a few hundred feet.

Ok. Threat ring shouldn't stay though.

There are massive blank spots in the 1:250k maps, even in the caucassus map. Higher resolution maps aren't even available. There was an A10 map mod once that had those charts, but the rastar maps have since been integrated into DCS core and the format changed and so the mod became unusable. I would like to see those maps built and included in DCS for all modules. null

Only pre planned target points at mission start have range rings attached on the TSD (I believe it should be on any point with an ADU threat ident, no matter where it came from). However when overwriting a target point because the target file is full, the range ring sticks to that target point number (even if it's a completely different ident or even a target point without range rings at all ("TG" ident in this case)) In the attached track there are 49 SA-8s, which are added as pre planned targets to the DTU Cartridge, creating 49*2 range rings (detection and engagement range, presumably). Adding target 50 does nothing special. But adding yet another overwrites T26 (not sure if that's accurate or if it should be starting with T01?). Despite that target point getting the IDENT "TG" for generic target, it has the SA-8 range ring attached to it that was on the point 26 from the previous point. Track attached range_ring_sticks_to_new_target_point.trk

When changing the map type on the TSD to SAT, the scale is force set to 25, regardless of what it was before. Changing the scale from this point sets the map type to stick. zoom_satmap2stickmap.trk

not the issue I'm having. The issue isn't the 30 FPS, which I'm fine with. The issue is that I get 10FPS when I look into the woods with the TV camera.

the TM is unclear about this. RFI/Radar correlations have a database of detection and engagement ranges associated with them. I would Imagine that a manually placed threat symbol will have the same database behind it to display the rings. If I were designing a system, I would make it so, reducing user errors, workloads, be more helpful to the crew and generally reusing a system that is in place. I mean what's the difference between a point loaded from the DTU and a point put in by the crew? I say there should be none. Maybe a real pilot may shed light on if threat rings are only displayed on purely pre-planned targets that are loaded from the DTU or if manually putting in threat points should also have range rings associated with them, which is what makes sense to me logically. In other words: Are range rings associated to points and that feature is unavailable in the cockpit, or are range rings associated to point identifiers, meaning they're static for a particular threat point type?