mattag08

Is there any word on these being worked on? Right now it's difficult to properly execute BVR tactics with other players since you don't really know when your missile is pitbull and the timeout is off by upwards of 30 seconds.

This is not the case and has never been the case (and is not correct behavior either). If you're experiencing this YOUR game is bugged.

:thumbup: Amazing. Glad to hear it!

Count clicks, that's what I do in real life.

Out of curiosity, what makes you think this is incorrect? Simply because other modules don't do it? Are you familiar with how a jet engine works? If so, I think you'd find that it's very possible that this is a realistic implementation.

Would it be possible to add the ability for Jester to do an in-flight alignment? I would be happy with a very crude solution even at this point. Something as simple as: 1. Use Jester menu to tell Jester to update the INS 2. Jester says, "roger that" 3. A couple button presses heard 4. INS is aligned perfectly Just to illustrate the point, the F-14 squadron I am part of regularly does 2-3 hour missions each week. Because we don't have a perfect 1:1 ratio of pilots to RIOs usually at least 1 person (often more) will have to use Jester. The lack of this feature really hurts those that have to use Jester for these long missions. I'm sure we are not the only unit that conducts lengthy missions in the F-14. Another anecdote, today I had a situation where I had been flying for only about 20 minutes and then got into two BVR engagements over about another 10 minutes. Afterward my INS showed an 8 NM error. I had no way to fix it other than to go land and get a new aircraft. IMO, we don't need a realistic implementation at this point. Any implementation would be better than what we have now. It's frustrating to fly more than an hour with Jester because your position and datalink info gets so screwed up that it is not usable anymore. Depending on the mission you can almost become ineffective because of it.

Currently the radar elevation adjustment is too coarse. Jester moves the radar 16° at the smallest increment. This translates to about at 16,000' change in the center of the scan at 10 NM and a 160,000' change at 100 NM. More practical adjustments to the radar would be in 1, 5, or 10 degree increments. Similar to how Iceman can be told to change altitude in an absolute or relative way, it would be great to be able to tell Jester to set the radar to say -15, -10, -5, 0, +5, +10, +15 absolute pitch angle or to tell him to adjust the radar by -15, -10, -5, -1, +1, +5, +10, +15 relative pitch angle. This would allow us to track targets in TWS more easily and scan in RWS for a target in a specific altitude block.

As usual, the limits of ED's missile code shows. Hopefully HB will be able to clean up ED's mistakes at some point.

Mike, any news on if this will be addressed/patched soon? Seems to me functional issues like this should be decently high priority. Especially if they are an easy fix.

On missions where you start on the cat, it seems there is a bug where you have to throttle down to near idle before it will shoot the cat. I want to say the F18 had a similar issue, but I don't know if it was ever resolved.

Any update on if this behavior will be changed? It's unnecessarily difficult to use in flight while formation flying. Seems like it would be quite impractical if it worked like that in reality.

It seems a new bug(feature?) related to stores has been introduced as of a patch or two ago. Now after ordnance is expended, there seems to be no noticeable increase in performance from the (now) reduced drag and weight of the airframe. It seems as if the flight model is still being processed based on the initial state of the aircraft. See this post: https://forums.eagle.ru/showthread.php?t=244657 I've tested this with TALDs as well as all the F-14's air-to-air missiles and it seems to be a universal problem. Other friends in multiplayer indicate the same behavior with the F/A-18C. I suspect that there is an issue with aircraft weight used in FM calculations being updated throughout the mission because fuel seems to be treated similarly. The aircraft flies the same at fuel fuel, 50%, or nearly empty. Currently a clean F-14B that started with full fuel and a combat loadout of 4-2-2 is requiring nearly MIL power to maintain altitude in the Case I pattern even after dropping all stores and reducing fuel down to less than 9,000 lbs. Prior to this issue, it was more common to see around 5.5k-6.5k PPH fuel flow be sufficient depending on weight. The TALDs are the most obvious indication of the problem as even with the TALDs and their racks jettisoned, the aircraft flies as if it was about to fall out of the sky. This is being posted in the DCS 2.5 bugs section because Heatblur explained that stores drag and weight calculations and aircraft gross weight is handled exclusively by the DCS engine and not by the 3rd party FM. Also, it seems to be a problem that is affecting more than just the F-14B, I just happen to have only personally tested it there so far.

Just updating this post, my unit conducted an operation in multiplayer using TALDs just now without afterburner we could not achieve a speed greater than 300 KIAS at any altitude. Four separate aircraft with four pilots and three RIOs. We launched the TALDs on a target, no increase in performance. We then dropped the racks that were carrying the TALDs and still gained no performance increase. It very much feels like someone accidentally moved a coefficient of drag one order of magnitude last patch.

Background: RWRs track a wide spectrum of radar-band frequencies and use various signal processing techniques to determine what is and is not a military search or fire control radar. The signals are processed and analyzed against known threats. The RWR will then return a warning along with the type and threat level based on this processing. From the point of view of a player with no classified knowledge of EW, but a background in physics and computing, there are areas where DCS's RWR modeling seems to fall short: 1. Radar wash and radar limits - aircraft often receive an FCR lock ("spike") indication, FCR guidance (missile launch) indication, or active radar missile homing indication when the source radar is of no threat to the aircraft in question or is well outside reasonable parameters. The beam width of a typical FCR is generally less than 1°. As a rule of thumb, this means the width of the beam is less than 1 NM for each 60 NM the radar energy travels. At ranges of less than 10 NM, the beam width is on the order of 0.1 NM. Currently in DCS, lock and guidance indications, which occur in a situation where the radar antenna is trained on a specific target and no longer sweeping, appear on the RWR of other nearby aircraft with an extremely high frequency, even when the aircraft is significantly offset outside of the normal beam width. Additionally, for threats such as active radar homing missiles, the active radar missile warning indication appears for a significant period of time after the missile is no longer a threat. In fact, the aircraft can be behind the missile's seeker head and still receive the threat indication. 2. Radar strength and rejection - It stands to reason that RWRs have logic filters that would eliminate physical impossibilities from being displayed. Radio emissions follow the inverse square law. RWRs can detect the strength of the emission and determine the range, and thus threat level, of the source radar based on a threat catalog. Likewise, this catalog would know the maximum possible detection and launch ranges of the platforms involved. This mean an RWR should, for instance, reject a launch/guidance warning from a source radar that is beyond a reasonable distance to engage the aircraft. For example, an F/A-18C that launches an AIM-7 would generate a launch warning for any aircraft that received sufficient energy to indicate that the F/A-18C was at a reasonable range to guide a semi-active missile. Allowing for error and unknown factors (such as missile improvements), this range would likely be 40 NM at most (since a reasonable range for the missile is at best, 20 NM). Additionally, the known capability of the FCR radar itself would be taken into account. If the radar is only capable of detecting fighter-sized targets at approximately 40 NM. It would be reasonable for the RWR to reject any radar guidance warnings of a strength that indicates that the particular radar is outside of 40 NM. Currently in DCS it is possible to receive missile guidance and lock warnings from platforms well outside of their detection range let alone that particular platform's best missile Rmax. This physical impossibility should be filtered out by the RWR. 3. Warning decay times - RWRs must balance probability of warning (POW) against false alarm rates (FAR). This means that there is some signal processing time that must occur for the RWR to determine whether or not the received radar energy is in fact a threat radar and then to classify that threat. Higher confidence reduces false alarms, but increases the processing time. However, in aerial engagements, this increased processing time also comes at another price, the inability of an aircraft to know when he is "naked". In other words, how quickly the pilot is made aware that the enemy has stopped locking, guiding, or searching for his aircraft. This information is vital in beyond visual range missile engagements. Currently in DCS, warning decay times are excessive. Multiple seconds elapse between a threat disappearing and the warning stopping. At best, 1-2 seconds is the longest period a threat should remain after the source signal is lost. All of these issues means that RWR usage in DCS is difficult at best and worthless at other times. A DCS pilot simply cannot rely on the RWR to produce accurate, useful warnings in a busy battlespace. Only in small-scale, set-piece air battles can a pilot expect to be able to use the RWR to a reasonable degree. The above is based on my personal testing and observations in the sim and my own reading and knowledge on the various physical principles involved. I would be interested to know what other people think or if there is other evidence that demonstrates that DCS's RWR modelling is actually accurate.

Yup, broken in general.

I still get this bug. Recently I cannot fix it simply by restarting the mission anymore. I have to restart DCS completely to fix it.

Generally when aircrew call, "MISSILE, break!" it is usually because they have visually spotted the physical missile or missile smoke trail and they are instructing the recipient of the message to evade/countermeasure the missile. Otherwise, there would be other calls to "turn cold", "crank", "notch/beam", "slice", "split-S", etc. for more typical and less emergent kinematic missile defeats. For SAM launches where it is unknown what the SAM is currently targeting (usually during the initial portion of the missile's flight where it travels vertically) are usually called "SAM launch" or other ambiguous terminology that is simply noting a launch and not describing its target. I'm confused, therefore, why Jester constantly calls out missiles from well beyond visual range as "MISSILE BREAK." This terminology should only be used for missiles inside of approximately 5 NM (probably more like 1 NM given how small they are and how fast they are moving). If the missile is not smokeless, perhaps up to 10 NM might be reasonable. Also, missiles from directly below or behind the airplane would be invisible to Jester as well. I assume that additional voice lines for Jester are unlikely to be recorded, so I would like to see the "missile break" gated down to only missiles within a certain range of the aircraft. This line should not play unless missile range to your aircraft is <10 NM (preferably less than 1-2NM). This would make the call both more realistic and more useful. Currently Jester calls out so many missiles that are no factor to his jet that the pilot becomes numb and simply ignores the calls even when the missiles are an actual threat ("the boy who cried wolf").

I seem to have found a workaround for now. I have to set everything up perfectly and prompt Jester to do a normal start and wait for him to say, "ready to start" before I begin cranking the right (1st) engine. If I do that, it seems to work fine (5 out of 5 sorties so far).

Come to think of it, I always just started cranking the engines to force Jester to start the alignment rather than actually asking him to start up. I'll try it with the Jester menu and see what happens. Never had problems with that method before the patch though. HSD works. It's very specifically the TID repeater and Jester going to the TCS camera and not cycling back.

It seems Jester is selecting the TCS continually and not returning back to TID.

As the title says, multiple members of my squadron have all experienced an identical bug. When playing as a RIO in multiplayer, upon entering the runway DCS will experience an error and the crash dialogue box will appear (e.g. it is not a hard crash straight to desktop). It is occurring at approximately the time that the ATC options normally appear and/or you get an ATC notification about taking off on the runway. I suspect the dialog box or ATC could be related. At least 4 people have all had an identical crash playing as RIOs. I was able to restart the game and join in to the backseat again as a RIO with no further issues.

I get this bug randomly. I even got it on the Case I tutorial. It seems to be a random chance that the right engine is just not functioning upon spawning in. In the case of the Case I tutorial the engine just instantly began to spool down when I hit fly. It's about one out of 20 spawns that does it and it is fixed by simply selecting a new slot (if MP) or restarting the mission (if SP).

Seconded.

Also, are all aircraft now supposed to show a "U" indication if they are enemy?

Does anyone know how DCS does thrust calculations? With the recent hotfix to the F-14, I'm left wondering if it actually models it properly. I've been under the impression that air density is actually calculated and then used by the engine model to determine thrust since the Ka-50 was released. Does anyone know if this is true for all/none/certain modules?