Raptor9

Please keep the forums clean of sexual references and offensive language. Keep in mind that many DCS players that read these forums are underage, and the behavior is also not very classy.

Each RWR symbol and associated ALIC code are located in Appendix B in the back of the F-16 Early Access Guide. As such, the Silkworm is not an air defense radar system and is not included in this list, nor is there a HARM code for it.

Thanks for the heads-up. The website will be updated in the near future.

Upon further testing, it appears the starters aren't engaging when around 3500 feet in elevation or higher. Reported. Thanks.

Described in the George AI chapter of the manual.

You need to command him to slave the TADS to FXD by pressing Down-Short. This takes him out of his "target tracking mode", even if he isn't actively tracking an individual target in the crosshairs. As long as he is using the TADS while the TADS is de-slaved and looking around, even if he isn't specifically steering it, he is still in "target tracking mode" logic. This is to prevent him from rapidly arming/safing the aircraft repeatedly if he loses line-of-sight on the target he was tracking, which can happen when the target is in a tree line or amongst structures. As for the weapon assignment, I misspoke. Assigning him a weapon alone shouldn't make him arm the aircraft, but once he enters "target tracking mode" he will. This is what I should have typed: "If the aircraft was safe prior to directing George to track a target or assigning him a weapon, he will automatically safe the aircraft after you direct him to cease tracking targets or assign him to NO WPN." Pressing Down-Short via the AI Helper interface is directing him to cease fire (if he is in Free Fire mode), stop tracking all targets, and slave the TADS to FXD (fixed forward).

From the open beta changelog on April 13: If the blue indicator is not displayed, the hold mode is not engaged and affecting the flight controls, even if the hold mode itself is enabled. A more detailed description of each is in the Quickstart manual.

As a reminder, roadmaps are intended to provide a means for community members to check on what major items the dev teams are working on, as a supplement to the newsletters and other communication mediums. They aren't a literal and thorough summary of what is being worked on or what is planned/not planned. This way the ED team members (specifically the community managers) aren't constantly pinged to ask what the dev team is working on at any given point. I mean, the questions are still asked obviously , but these roadmaps allow the community managers a quick reference to direct the community to. The CM's like BigNewy and NineLine have a lot of responsibilities to cover the various communications outlets and social channels 24/7, so this helps them out as much as it helps the community see what is cooking in the proverbial development oven.

George is a task-based AI crewmember. When you assign a weapon to him as the AI CPG, you are actually directing him to engage the target he is tracking (or will track) with that assigned weapon, at which point he will fire on the currently tracked target or wait for Consent to Fire, depending on his ROE setting. This task requires the aircraft to be armed; so if you safe the aircraft, George arms the aircraft again because you are contradicting this task. Likewise, if you direct George to track a target, he will arm the aircraft so that he may fire the laser rangefinder/designator. If you safe the aircraft, you are contradicting this task so he will arm the aircraft again. If the aircraft was safe prior to directing George to track a target or assigning him a weapon, he will automatically safe the aircraft after you direct him to cease tracking targets or assign him to NO WPN.

This has already been requested internally, but I have no news to share unfortunately. For now, this is the current logic of it in game. This is because the Ka-50 flight computer does not have force trim "breakout" values like the AH-64D does. Its autopilot's Hover mode will actively fight pilot inputs for as long as it is enabled and the force trim ("trimmer") is not pressed. However, the AH-64D's hold modes will disengage if the either the force trim is pressed or the breakout values are violated.

If Attitude Hold is enabled (in any submode), the hold mode will only engage when the cyclic is within 0.25 inch (0.635 cm) of the force trim reference position, which translates to 2.5% of axis movement in DCS. If the cyclic is beyond this position or if the force trim release is being pressed, Attitude Hold won't engage. In other words, it may be enabled, but it isn't actually trying to hold anything because you are telling the FMC you want to fly it yourself.

Nothing changed in the flight model. The only thing remotely related was the criteria for when Altitude Hold engages or disengages was refined, but this does not have any bearing on how the aircraft flies.

It sounds like George is trying to power the TADS laser back on, but you've powered the TADS off. The Shutdown page isn't fully implemented yet, so the logic isn't there to recognize the condition.

I can't determine what happened in your gameplay, but if the aircraft is too heavy for the air density, George won't be able to prevent a vertical descent rate from building. There are times the aircraft may not have the power-to-weight ratio to hover and you should keep his speed setting at 40 knots or higher.

The ECM pods on DCS F16 can be employed in both Noise (Mode 3) and Deception (Mode 1 and 2) jamming modes, as described in the manual. I've personally done testing in this regard and have had many instances where missiles have simply blown past me when I was jinking around trying to egress from a target area when I was out of chaff. As with many things in DCS, if improperly employed, it will have limited effectiveness or no effectiveness. If doing air-to-air missions, I don't bother carrying it because I prefer to maximize my maneuverability (can't jettison it). But when doing SEAD or air-to-ground strikes against targets defended by SAMs where Im trying to rush in and rush out, it can actually be quite useful.

There are still improvements that are being worked on. The roadmaps are a way of letting players see some of the highlighted features that are in active development, instead of constantly pinging the community managers like BigNewy or NineLine to ask what the devs are working on. The roadmaps do not encompass all development, nor are they exclusionary one-off events. Just because a feature is added, doesn't mean it won't receive additional bug-fixes or refinements as the product matures. There were some substantial changes that were being made to the flight model and SCAS systems in the spring, so it was a way of letting users know there was something coming, and then letting them know that an update was delivered. This is important for those players that may not regularly play DCS, like if they came back after a month or so and wanted to review what has changed since they last looked at the roadmap or last played the DCS AH-64D.

Please verify the LT switch on the right TEDAC grip hasn't been set to the M position for Manual. The LRFD can't fire when the laser spot tracker is enabled. Unfortunately, there is no indication that it is enabled in Manual since in Auto mode it would be doing it's 4-bar scan. In Manual mode you can still move the TADS around like normal, but the LRFD is disabled.

It depends on what the mission maker has set in the mission file. When AI Gunner skill is set to Realistic, I typically will get a list that is full of just a bunch of yellow "GROUND" "GROUND" "GROUND" "GROUND" "GROUND" when hovering at like 5 or 7 km. And then as I scroll to the next target and command him to zoom in, it will change to a red "ZSU-23", and then scroll to the next target and let him slew the TADS there, it will change to a red "T-72", etc.

@Watari George is still very much WIP (I know its been said a lot, but it is true), as both a Pilot and a CPG. We are always looking for ways to improve the interaction, and a general search mode has already been requested: As the aircraft evolves in Early Access it is necessary to ensure George's abilities evolve with it. Sometimes these changes cause unforeseen effects in his behavior. Typically these are found in testing, but a few slip through. We have a number of bug reports regarding George's flying habits and his weapon usage that are being addressed. As for the AI interface, it shouldn't impact the number of keybinds since those keybinds are only active when the interface is displayed. As an example, I have a 4-way POV hat set as both my Sight Select switch and my George AI interface 4-way commands in both cockpit.

Just to clarify, the weight ratings in the mission editor are based on structural limitations, not performance limitations. If the aircraft is loaded to 20,000 pounds, that is below the maximum gross weight the aircraft is structurally rated for, but that does not mean the aircraft has sufficient power-to-weight ratio to carry such a payload. Even if it can, it may not be able to maintain a hover until it burns off fuel or expends munitions.

As was already stated by BigNewy and myself, EO-VIS as a whole is being looked at to identify any inaccuracies within the logic. However, I will state once again that the OP's topic of this thread is already determined to be correct as is. Your specific circumstance will be looked at during the review, but as for the original topic of discussion (which we have since departed), it has been determined to be correct-as-is.

I think I know which document you are pulling that from, and that statement is from a larger paragraph that is describing the events, in sequence, that occur when EO-VIS is being used. The designation is performed, and then the LOS circle appears. Further, the figures that immediately follow that paragraph distinctly display the LOS circle in the post-designate state, but not in the pre-designate state. There is a specific Slew mode, even if not described in that document; others are worded differently and are annotated as "in Slew". The MBC is a function of the TGP (not the AGM-65) that is active when performing handoffs in EO-PRE. When this is occurring, the TGP is commanding movement of the AGM-65 seeker LOS while the TGP is SOI (WPN is not SOI, AGM-65 seeker is in Slave mode). The MBC is commanding movement of the AGM-65 seeker, just like the TD Box is commanding movement of the AGM-65's seeker while in pre-designate EO-VIS. So again, our interpretation of the logic of the LOS circle is already as it is within DCS. I understand others have a different interpretation or opinion of what should or should not be in DCS F-16C, but we are confident that the current implementation is accurate.

There is a specific distinction between the the process of "slewing" and the state of being "in Slew mode". The difference may seem inconsequential, but it is distinct. "seeker line-of-sight appears when the AGM-65 seeker is in Slew or Track," "seeker line-of-sight appears when the AGM-65 seeker is slewing or tracking," As for the DCS F-16C Early Access guide, that will of course receive any necessary revisions to be more clear to describe the accurate behavior. As BigNewy stated above, we are investigating the logic of EO-VIS mode as a whole to identify any required refinements of the behavior, but in the case of the OP's topic within this thread, we have determined that the current implementation to be accurate.

Each time as I am taxiing to the runway or shortly after takeoff while enroute to the target area. Only takes a minute or so. I have my ICP set up on my keypad and arrow keys so it is pretty easy to rapidly input data. Makes navigating and interacting with the DED a breeze and I've gotten pretty quick with it. (The "Dec" and "Inc" keys are the Increment/Decrement rocker to the left of the ICP DCS switch.) EDIT: I sequence to the CHAFF page, edit chaff in PRGM 1, Decrement to PRGM 2, edit the chaff in PRGM 2, and then each programs chaff through to PRGM 6. Then I sequence to the FLARE page, and do the same thing in reverse order for flares by Incrementing from PRGM 6 to end with editing the flares in PRGM 1. Minimizes needing to cycle through CHAFF>FLARE>OTHER1>OTHER2 for each program.

@skywalker22, I am not going to go back and forth on this. I've already stated twice that our documentation is quite clear on how this function should work when enabled. And I even stated above to clarify how it should appear: You may not agree with or like how the function is implemented, but unless you can provide clear evidence to the community managers (from a publicly-approved source of course) that contradicts this, there is nothing more I can say on the matter.