Beamscanner

[This bug has been mentioned in un-related threads. So to make this an officially reported bug, here is a thread just for it.] The video export of the DCS F/A-18C is blurry and does not match the video quality depicted in-game. Please expand the image to clearly see the quality of the DDI exports. This is an ingame snapshot of my screens. You can see, as compared to the text on other objects on my second screen, that the DDI exports are very blurry. (The in game DDIs are normal) (note: the IFEI, RWR and UFC on the second screen is part of a HELIOS profile and is not part of the DCS video export) I am running two 1080p displays stacked vertically. My game resolution option is set to "1920x2160". The 3D world is rendered on only the top screen at 1920x1080. Some members have tried fixing this by altering the LUA files. However: 1. The modification that they came up with, actually sharpens both the the exported video and the in-game displays. Making the in-game DDIs and HUD very thin and difficult to read. 2. A player modification should not be a solution to a bug affecting everyone. Not that I believe it helps at all, but just in case the 'no track' mob runs out, I've attached the log and track. Also, all my mods are off (hence why you dont see UFC, RWR or IFEI video exports) cursor.trk dcs-log.txt

I think your confusing the CFD simulations IASGATG did with the missile guidance logic. Heatblurr did build loft guidance into their simulation, but they mentioned that they couldn't implement everything they wanted to due to limits of the DCS engine. So I'm wondering if ED's expansion of the AIM-7 and AIM-120 will enable Heatblurr to do more with their AIM-54 simulation.

Will ED's improved guidance logic for the AIM-7 and AIM-120 enhance your ability to simulate the AIM-54? (ie will you have additional C++ features at your disposal for guidence logic)

This is not modeled.. Though I wish it was.

It makes the ingame screens thin and much harder to read. (including the HUD)

As I already explained, rolling should NOT break lock. https://forums.eagle.ru/showpost.php?p=3571222&postcount=14 Thus, it is still not working.

Degrading the quality of the in-game displays to fix the exported displays is not an adequate solution. The more people keep saying that this is a solution, the further down the list this bug gets and the longer it'll take ED to address this issue.

HB team, Will your simulation of the AWG-9 display chaff returns in Pulse Search on the DDD? Or does the DCS engine not support it?

Very cool!!!! rare indeed Do you have any video of the SPO-15? I want to see how the signal amplitude behaves. (the one called the "light strip") In DCS it acts like a digital unit, registering only the peak amplitude it sees over a given time. But I have a hunch its analog and moves up and down in amplitude in real time, as the emitter scans around you. But I need video to know for sure.

Thats not a fix.. That messes up your in game displays

how'd you get rid of the blurry exports?

"BUG" or not, its not being simulated properly. Extreme roll should not have any effects once your locked on to a target. For those who do not know radar operation and theory, this is akin to thinking that a flashlight rolled upside down would not be able to illuminate an object ahead of you. Rolling the antenna is used for just a few things. 1. Guard antenna orientation (keep towards ground for sidelobe cancellation) 2. Keep scan pattern orientated in relation to ground. 3. Optimal Polarization so as to not receive more sidelobes than desired (horizontal polarization is more reflective off the ground) None of these would lead to a break lock scenario. The slight increase in sidelobes is almost entirely mitigated during STT by range gate tracking, CFAR, doppler processing, etc.

U.S.

Footage of the APG-63 (same radar family as 65/73) shows lock-ons averaging about 2 seconds from initiation to lock-on. Look around the 6 minute mark here: Yes, that is not realistic. ED must think that the antenna must be stable (or oriented upright from the earth) in order to detect and track targets.. This is not the case. In the same sense, the target does not need to be in level flight for the radar to detect it. As long as the target is in the cone of the antenna, it can continue to track it, regardless if the antenna cannot roll anymore. The antenna only rolls in the first place to keep the guard antenna towards the ground (sidelobe reduction). Once a target is being tracked, sidelobes dont really matter because the radar will use range gate tracking (ignoring returns not immediately around the range of the target) and thus not be affected by close range returns from the ground. The extreme antenna roll would only have a minor effect in search modes in at low altitude (strong ground return) where range gating isnt being used (because your searching all ranges). Even then it wouldn't necessarily prevent you from detecting targets, it would just lower your detection range/probability (due to worse than normal signal to noise ratio). If they applied this same logic to the Flanker (which has its guard antenna fixed to the bottom frame of the aircraft, meaning it doesn't rotate to keep facing the ground) it wouldn't be able to use its radar at all if the plane wasn't in perfect level flight. I imagine that has to do with similar coding to the rotation issue mentioned above. Ed seems to have set the lock-on mechanic to the area on the display rather than the range/cell (ie position in space). When you turn, the radar should continue to look for the target at that position in space, not at that column on the display. Meaning if you turn right when trying to lock a target, the radar beam should look like its moving left. (its using the true bearing from your aircraft to find the target, not the aircraft relative bearing. Im also not sure if ED realizes that the radar is also only trying to lock a target at within the range cell of the brick, meaning it should be impossible to lock a target on the same bearing that is at a different range. It'll also used the doppler information attached to the brick to sort even further when trying to lock it. Same as my first statement. Not implemented yet. Something else that no one has brought up before. The radar bricks move properly in azimuth when you turn, but they dont move in range as you fly closer to them. I'm not sure if this is accurate or not. But what this means is that if your closing in behind someone who is flying away, the bricks will actually look like they'll flying toward you as the newest bricks will be closer. This can confuse the pilot as to the direction the contact is flying via bricks alone. If the bricks were locked to a position in space (that was my initial assumption) they would appear to slowly move toward you as you flew toward that position in space until they aged out. What I do know is that bricks are a static representation of raw hits at a precise time in space. The question is, is it static to a position on the earth (like a LAT/LONG) or static to the display. We know its not static to the display in azimuth (bricks "move" side to side when you turn. real footage shows this to be true). So if the brick moves relative to your aspect, shouldn't it also move relative to your position.

If that's how this team responds to issues with their product, I'm definitely not buying the CE..

Even a year after I provided evidence, the RWR issues still haven't been addressed. The only thing they have to the contrary of my sources is a NATOPS manual for the F-5N(which doesn't explicitly say that synthetic tones are the only audio; PRF audio would be addressed in a TAC manual not a NATOPS) from a Squadron who doesn't even have the RWR anyways. "[F-5] has no defensive systems, no RWR nor expendable countermeasures" - https://fightersweep.com/129/flying-the-f-5-tiger-ii/ The only people who use and update that NATOPS don't even have an RWR! Do they expect to re-sell this product (with MCG) without addressing the issues with their "simulation"?

I really want to give you guys money, but you still dont have the gunfighter base available. :(

That "simple" fix isnt a fix at all. It'll mess up your HUD and in-game DDIs. You either get good looking in-game displays, and bad looking exports. Or bad looking in-game displays (cant even see HUD), and good looking exports.

Do you know what year the critical threat rings were switched around? The host of "the fighter pilot" podcast stated that the critical ring was switched at some point (presumably from the outer most ring, to the inner most ring).

Tornado makes the most sense.. Also, its what I want!

One of the issues with loading into MP missions is that the game has issues "finding" files. I know this as I've checked my log immediately afterward. It'll struggle to find certain files which will cause the program to hang. If it hangs too long in MP, the game will freeze or crash. Putting the game on 2 SSDs in raid 0 "fixed" my problem by giving the game greater speed to locate the files it struggles to find (so that it doesn't hang as long), but this shouldn't be the solution. game badly needs to optimized.

since DMC_stroke_thickness = 0.4 DMC_stroke_fuzziness = 0.2 alters only the ampcd and stroke_thickness = 0.4 stroke_fuzziness = 0.2 alters everything else i imagine there must be a name for the you could insert before "stroke" to keep the HUD thick. example: HUD_stroke_thickness = 0.8 HUD_stroke_fuzziness = 0.4 that line doesnt work, but if we can figure out what to place here: XXX_stroke_thickness = 0.8 XXX_stroke_fuzziness = 0.4 then maybe we can make it look good

how did u fix the ddis? that #5 post did absolutely nothing

thats not a fix. still blurry

mine is still blurry