MARLAN_

This may be another case of true vs magnetic mismatching. I've lost track in how many spots it incorrectly uses true but that would be my first guess of what the issue is.

In my limited tests when the bandit is any more than 5000 ft below you your radar range is ridiculously reduced as you've shown. About 48nm to 31nm vs. a Fulcrum. Definitely needs fixing.

I'm building a program that does exactly this. (https://github.com/dMARLAN/DCS-Dynamic-Weather + https://github.com/dMARLAN/cvw8-scripts) It's currently functional, but I haven't made it "public-user friendly" yet, so not sure how much this will help you unless you already are familiar with programming you could connect the dots. It's on my to-do list to add appropriate read-me's etc. once I have time.

It's literally in the document if you read it, it isn't labelled QNE, look at pressure altitude as I've explained multiple times. The FAA handbook also explains the relation with pressure altitude & standard pressure (QNE). Just because you haven't heard it doesn't make it nonsense. As you said, UK/Russia may use this more often, and the definition exists. (This is aside from the fact it is still a mathematical equivalency as well which applies globally) I have never said referring to QNE as the pressure altitude is common place, I've said multiple times its not, but you guys keep saying as some sort of fact that it is straight up not an altitude, and I am just saying it absolutely is an altitude (pressure altitude), that altitude changes based on local conditions. It isn't just some antiquated radio system either, it is also a mathematical equivalency as previously mentioned. That pressure altitude when at the field is well, the pressure altitude at the field (duh), so it's not wrong to define QNE as the pressure altitude at the runway threshold (but certainly not the common use of QNE which is a pressure setting, e.g. 29.92/1013.25/etc.) I'm done replying here before this gets any worse. Frederf you obviously understand the topic, just getting a touch stuck on common usage vs. definition. I only brought up pressure altitude and its relation in the first place because Yurgon seems to think the definitions are in conflict (they aren't). Yurgon, you're so confidently wrong you really ought to just read up on pressure altitude instead of constantly trying to insult me, looks really silly when you're so off the mark with your understanding of this topic. The fact you think multiple official definitions are in conflict should tell you something (read the handbook). (P.S. 29.92 (Pressure Altitude) = 29.92 (QNE) to clear that up. I didn't think I would need to say 29.92 = 29.92 but here we are)

Using runway thresholds to explain QNE is certainly a simplification as it is more accurately defined as pressure altitude, but there are certainly definitions that use runway thresholds as part of it, and it's not wrong, because when you're on the runway, with QNE set, your altimeter will display pressure altitude. I think explaining it that way helps understanding. I do totally agree though that it's more accurately defined as pressure altitude. Huh? My comment clearly went over your head. See: FAA-H-8083-25B, it's defined about 5 times in there as myself and Frederf are explaining to you. This topic is becoming pointless.

It can be both, just like how distance can be expressed in seconds or meters, but is typically expressed as meters. QNE is typically expressed as a pressure setting, e.g. inches of mercury, but it also represents a pressure altitude. I think you are not understanding what pressure altitude is. Both definitions are correct, you are not understanding what they have written. If you set your altimeter to 29.92 inHg it will indicate an altitude that is equal to the runway threshold pressure altitude. Both definitions are correct, the former one is just written in more layman's terms. -> Set your altimeter to 29.92 a.k.a. QNE a.k.a. standard pressure -> look at your altitude while parked on the runway threshold -> this is the field's pressure altitude -> Set your altimeter to QNH per ATIS/METAR -> look at your altitude while parked on the runway threshold -> this is the field's altitude

In the mission editor / brief it indicates a QNH setting, but this is actually QFF. QFF being the true / actual altimeter setting as if it were measured at sea level. It could also be referred to as QNH when measured at sea level, but it's important to make the distinction that QNH would normally be measured at a station based on local pressure & temperature and corrected with ISA. QFF is using true values as if you dug through the ground and measured at sea level. Understandable since DCS is currently setting pressure globally across the map, would be neat if updates to DCS weather allowed local settings, but even currently it is pretty confusing. For example, real world Nellis AFB is at this time reporting a QNH of 29.95 with a temperature of 38 C. To have this match correctly in DCS you would need to set the mission value to ~29.779* inHg with a temperature of 42 C (corrected for temperature lapse rate for sea level) If you want to check it yourself, try the linked equation (*still in WIP, only tested at Nellis, but consistently precise for DCS, just inaccurate by about 0.01-0.02 inHg, I'm guessing I'm missing a step, thinking DCS doesn't actually measure QFF from sea level but something like 15 meters.) Put together by referencing: https://en.wikipedia.org/wiki/Atmospheric_pressure https://en.wikipedia.org/wiki/Pressure_altitude https://www.metpod.co.uk/calculators/pressure/ I am not a mathematician, meteorologist, or aviator of any sort, just a nerd learning how to program and noticed these issues while trying to create a program that sets real world weather in DCS.

Well explained! Much better than I could explain it.

Like I said, I was explaining the inverse or other side of it to help you understand. It is not commonly referred to as an altitude, but it does mathematically relate to an altitude. Setting for example, 29.70 inHg (assuming appropriate pressure/temperature conditions to match) will indicate 1850' when parked at Nellis . Setting your indicated altitude (at the field) to match 1850' will also indicate 29.70 inHg in your Kollsman window. They mathematically relate to each other and you can solve for one if you know the other (assuming you have pressure/temperature data available as well) But yes, you are correct, you would never hear "QNH 1850 feet" on the radio, it is not used this way, I am only trying to show you the opposite side of the relation. Yes, extensively, I am programming a dcs-weather-update program and I needed to use a lot of these equations to convert the incorrectly reported DCS: QNH to QFF, which includes using pressure altitude and QFE as part of the equations. QNE is the pressure altitude, like I previously explained, they all relate to each other, and pressure altitude is not the same as (true) altitude. If you measured vertically from sea level to Nellis your measuring tape would read 1870' but your altimeter when set to 29.92 (QNE) would indicate pressure altitude which would be a different value depending how much the pressure & temperature differ from ISA on that given time, at that location. The use case of QNH is to have consistent values based on local pressure such that obstacles or field elevations match charts because pressure/temperature changes, but measured elevation doesn't (but pressure altitude does). If an obstacle is 4000 feet, you want your altimeter to correctly read 4000 feet when at that obstacle based on the local pressure so you can consistently and safely avoid that obstacle and fly above it. If you had QNE set (29.92) instead of QNH, if pressure was low that day, your altimeter may indicate 4050' when you are in fact at 3850' and thus you would collide with that obstacle. The use case of QNE is to uncouple local pressure to a set standard so that when above altitudes where earth obstacles are no longer a concern, but typically only other aircraft, you all have the same altimeter setting without needing to resync every time you enter a new airspace that has different local pressure.

QNH is an altitude, that is, the ISA MSL altitude of a field. But it's not commonly referred to as an altitude obviously, that is the inverse of the equation. QNE is a pressure setting, that is, standard pressure, and this will correlate to the pressure altitude of a field. This is not the same as the altitude of a field. https://en.wikipedia.org/wiki/Pressure_altitude https://en.wikipedia.org/wiki/Atmospheric_pressure Nellis is not "29.96" if you mean a set unchanging value, its a variable that changes with local pressure. Nellis QNH at the time of this last current report 29.95, which I'm sure you know since you just checked, but it was as low as the 29.70s yesterday. If you think this is a set number you're not understanding the material, and the fact you believe the Wikipedia and FAA definitions of QNE to be in conflict shows you aren't understanding the "details" as you put it. I don't mean to be rude, but you are literally calling me out when you do not understand.

What do you mean? I'm just trying to help you understand it by explaining the other side of it.

QNE is a specific pressure setting, i.e. 29.92 or 1013.25 which will match the pressure altitude of a field. The pressure setting doesn't change, but the pressure altitude will. QNH is a specific altitude for a field, so the altitude of the field doesn't change but the pressure setting does. QNE is always 29.92 but the pressure altitude is different. QNH will always be 1870' at Nellis but the pressure setting is different.

The definitions you posted don't conflict. It's important to note the verbiage "pressure altitude" which is not the same thing as altitude. QNH is corrected for non standard pressure, that is, it is local pressure. QNE is standard pressure. QNH will indicate field elevation when you are on the field. QNE will indicate pressure altitude when you are on the field. QFE will indicate 0 when you are on the field. For example, KLSV (Nellis AFB) field elevation is 1870, if you set QNH (e.g. 29.71) you'll see approximately that elevation. If you set QNE (29.92) you'll probably see something closer to 2000' (depends of course) which is the pressure altitude. It's also important to note that DCS indicates "QNH" incorrectly in the briefing & mission editor but it is actually a modified (in that its not from sea level) QFF.

For those interested, I briefly talked to a Rhino pilot today about this topic. They won't transition during cyclic ops. They will transition to QNE when based out of a field with an IFR clearance (incl. flight >18K which is most flight)

From one of my group's F/A-18C pilots: I know this quote has no credibility besides trusting my word (though hopefully you don't consider me a liar), but what part of OP's post conflicts with ED's evidence? I've not yet seen any evidence that says you cannot designate (L&S) a track file. Understandably it's very difficult to connect the dots on such a complex system with only parts and pieces available to source, but when you combine SME input I believe the answer becomes fairly clear. Does ED have input from a F/A-18C pilot that indicates there are conditions where you can't designate a track file? Additionally, both the FRM and 742 do not indicate anywhere I know of that you cannot designate a track file. They do, however, specifically indicate that you can designate a track file as the L&S in multiple places.

It's in the FRM or 742, I forget which off the top of my head, but 100% in there, and ED references those documents so they have the evidence. Guess it depends if they want to implement it or not.

You could employ in RWS with LTWS/TWS MAN, but the manual nature of it is sub optimal, but certainly doable. Modes such as STT, TWS AUTO or TWS SCAN RAID are usually used for employment. Though when launching an AMRAAM out of RWS, the MC should command TWS AUTO, but this isn't implemented in DCS currently. (Other modes will also command TWS AUTO when an AMRAAM is launched, such as TWS BIAS, TWS SCAN RAID, or EXP, though I don't have a source on TWS MAN commanding TWS AUTO, which would seem logical to me, but I haven't seen that specifically) You could employ on datalink only contacts, your track quality would just be limited by the data rate of incoming information. For example, if you launched with data link only, using a E2/E3 as your offboard source, you'd be looking at a ~10 second delay for their radar sweep, in addition to the AIC link delay which would result in poor track quality (though certainly usable for a non maneuvering target), but for track information coming from another fighter that radar sweep might be as quick as half a second depending on their radar settings, and the F/F link is also significantly quicker (IRL that is, in DCS F/F link is still too slow) which would result in track quality that would be nearly as good as if you were tracking them yourself. Things like this coupled with A/A tactics would totally eliminate the possibility of notching since you could have 2 fighters (and AIC) providing track data from very different angles. If MSI is ever implemented things such as your FLIR or CIT would also contribute, if you had a FLIR Track on a target, they would not be able to notch you at all. Note: You still need to supply the mid course updates to the missile yourself even when using target data from offboard sensors. My understanding is mid course updates for an AIM-120C5 requires your radar to be emitting (but not necessarily detecting the target under missile attack). So you couldn't skate early otherwise you'd still be ending support for your missile. Though if you don't provide any mid course updates (or end support), the missile would still be provided the initial target data and fly to the last known intercept as is already modeled in DCS, so you could reasonably employ with radar silenced against a non maneuvering target.

It seems the bug that was present in the F-16 for some time has made its way to the F-18 in this latest update. The DCS: F-18 currently detects fighter sized contacts around 47-48nm, shows hits and a track file, but is unable to be designated (L&S) and/or locked (STT) until ~44nm. - The F-18 should be able to designate any track file at any time, generated via onboard, or offboard (F/F or SURV). - Track files can be contributed to/created by other sensors than just radar, such as HARM, FLIR, CIT, or offboard sensors. There are multiple videos that show HUDs with a designation while on the ground. - The F-18 should be able to designate track files regardless of radar contribution. Whether or not radar contribution exists on a track file is indicated by the radar contribution circle (not currently implemented in DCS) - The F-18 can't designate (L&S) until a track file is built, which requires 2 correlated radar hits. This is not a set reduction in range, and is based on your scan volume/frame time which may be faster or slower. For example, in 1B/20/HI this may be near instant, where 6B/140/INTL may take some time longer. If an offboard track file already exists, the track file is already built and can be designated at any time, including before your onboard radar is contributed, but for the purposes of the current DCS implementation where we can't yet designate offboard tracks, we should be able to designate a track as soon as you get radar contribution. - Any time we have radar contribution we should be able to attempt a lock (STT), this could of course fail to acquire or have trouble based on other factors, but should not be based on hard coded ranges. F-18 SMEs, the FRM, and the 742 can correlate this. A lot of these issues can be resolved by implementing even a rudimentary implementation of MSI into the DCS: F-18 which can be sourced from the aforementioned documents. CantDesignateTrackFile.trk

They increased it recently, a month or two ago. I forget exactly, I think it's 100 seconds now or so.

Yea, definitely. Would be nice to see improvements to this very important feature for all ops

The radar isn't locking anything while on the ground (radar should not be emitting with weight-on-wheels if I remember correctly), it is designating track files from memory. The distinction between a lock (STT) and a designation (L&S) is good to know, the community's misnomer of "soft lock" (which isn't a thing) often contributes to this common misunderstanding. For example, if MSI is ever implemented in the DCS F18 you could designate an offboard track without radar contribution at all, allowing you to designate tracks while on the ground even after radar memory has timed out.

When I first posted this, the missile was falling out of the sky after about 10-15nm of flight. That would mean there was a bug in either AI DLZ calculation because AI was firing outside of Raero, or the missile was not performing as expected. It would have been one of the two, but I did say I do not know which, because I don't know how the missile is expected to perform. Anyway, it is back to normal now, so it feels okay now. Can lock this thread if you want.

For a long time I was under the assumption that the eventual ATC improvements would include GCI/AWACS but after seeing some road maps I'm no longer sure if that is or ever was the case? If it is already on the menu, then ignore me! Would be really great if DCS had made some improvements to this, there are a lot of ways this could be improved, and lucky for us, all of this information is public release with a plethora of knowledge available that covers almost everything in the ATP3-52.4 (MTTP for Air Control Communication) and the P-877 ADV E2 NFOTS which are both 100% public release distro A. Some areas that can be improved - "for", "at", "bulls" shouldn't be used (use full word "bullseye", and have a short pause in between bearing/range and altitude) - alpha check to bullseye is inverted - having a check-in would be nice - irrelevant groups shouldn't be called out, e.g. groups greater than 100nm away (perhaps the AWACS in the mission editor can have some configuration ranges for broadcast, commit, tac range, meld, and threat range) - contacts within 3nm should be considered as one group. - while it may be too difficult to code in automatic group labeling (azimuth, range, champagne, vic, box, etc.) one smart way to approach it is using the phonetic alphabet to label groups (e.g. "alpha group", "bravo group" etc.) - use bullseye format until groups are inside meld range (and even then real world the controller would keep quiet though this may be complicated to have an AI always perform as desired) - "telepathic" radio calls that only you hear should be heard by everyone on the radio channel -- perhaps there can be a check box for "easy mode" in the mission editor that goes back to the old telepathic BRAA calls. And lots more, the documents noted above are a treasure trove of information and would really improve the A/A simulation of DCS without requiring trained human AIC/ABM/GCI's for all missions.

Yea, I'm definitely just simplifying a complex problem, all I meant was since it's a simulation they have perfect values available so they could obtain a perfect range in the code and then use that as they desire. I'm probably misunderstanding what you're mean, but I don't want to derail, feel free to DM me!

I concur, just never got around to making a new report for this. Was previously reported and "fixed" but is still very inaccurate. I wonder if this is also a contributor to why the LOST cue is still extremely inaccurate. I would have thought DCS knows precisely the range of its own missiles in its own simulation and no guess work would be required. Then after that exact value is determined, add some minor percentages of error to account for what would have otherwise been real world inaccuracies. There must be a math error in the code somewhere to account for this issue.