Rissala

Well these 2 pics sum it up. When in active pause, as @LastRifleRoundsaid, the designation is accurate. When moving, the code is bugged so the designation is not accurate. It all has to do with the map updates on the MFD and the motion of the Hornet or something like that. Active pause designation: Moving designation: "Hey, this got a bit better from the last time I looked. The geometric transformations have improved but aren't good enough yet. It looks like they have most of the translation fixed but not rotation. When you designate the surface radar you're picking a spot based on the coordinate system at the moment of designation which is not exactly the same as the coordinate system suggested by the rasterized radar image on the display. As such there's an out-of-syncness that changes dynamically and is worse the farther away the designation is from the pivot point. " This sums it up.

This is my .trk that also shows the accuracy when using active pause or in other words eliminating the motion of the Hornet. I hope ED can reproduce this. I can provide more tracks showing the inaccuracy when not using active pause. A-G radar accuracy try #1.trk A-G radar accuracy ACTIVE PAUSE #1.trk A-G radar accuracy ACTIVE PAUSE #2.trk

Newy sad that: "Hi, I do have the accuracy between the TPOD and the RADAR designation reported already thank you" So it is a bit disingenuous to say that the designation bug itself is reported. However, the bug itself seems to be as you described: With active pause enabled, the radar is 100% accurate. When the motion is taken out of the equation, the radar works. (too well?) Is this just a lazy way to make the radar "limited" like in real life, OR is this there some code logic errors that ignore the movement of the Hornet when designating a TGT? I bet it is the latter one... I unmarked the "solved" since the "correct as is" seems to not be the case afterall. Maybe implement a random error after correcting for the A/C motion bug? This way the random error is tunable and can be tuned for a closer match with the real thing. (or just sweep this under the rug and make it "correct-as-is" anyways?) @BIGNEWY Can you have a last look at this? Pretty please? Trackfile for the active pause 100% accurate designation is already in the thread shared by @LastRifleRound. Thanks.

To reproduce: go f11 view use scroll wheel Problems: speed reading is really laggy changing speed is really slow general movement is difficult now Seems to have become bugged after 2.7 (not certain) (my mouse is 1000hz poll rate)

well the point of the A-G radar is to be an all weather alternative to the good weather equipment seems like the discussion jumped quite quickly to the assumption that the A-G radar is really supposed to have a 100 meter+ CEP i just wanted to know if this is the case irl edit: and it seems like it was

A-G radar accuracy.trk When wags introduced the EXP modes, he said that "you can put a weapon on" the designations. This is currently impossible. I tried hitting an AN-26 (medium transport plane) with the last designation happening at 9 nm with EXP3. The JDAM missed about 100 meters. This was literally a best case scenario since going any closer would slow down the scan rate of the radar too much and other alternatives would be a better choice. (unless bad weather like in the scenario) I have never successfully killed a ground target with the A-G radar designation and a JDAM in multiplayer or singleplayer. If the radar is supposed to be used for weapon designations (like in wags video for example) , I would assume it should have like a 25 meter accuracy radius. Currently it is extremely unlikely to hit literally anything.

The radar rotates 180 degrees and then resets in a buggy way to the original position. radar bug (3)_.mp4

"no2, I don't think that behaviour is necessarily a bug. It sounds more like something that would happen from track ambiguities, and it clears up over the course of the frame time." you can see from the trak that it is clearly not the case

There is actually 3 clear bugs in this short clip. 1st bug: The TWS radar scan is not following the TDC as it should. It is behaving as in BIAS mode. 2nd bug: The target is still getting impossible mach numbers assinged to it. Such as mach 100+. 3rd bug: The target, while visible to the hornet radar, dissapears after a few seconds. It can be seen from the scope, that the radar is "about to lose" the target many times and after a few scans, it is lost. This is incredibly frustrating on MP. (Bonus bug) There seems to be a "brick" type track under the main TWS track altough there is only one out of 8 full tracks used. hornet radar bugs_1.trk

It forks fine up to 40 nm. Then it becomes "unusable". You do not need a crystal clear image of the target, only the shapes of them. Pro tip: change the contrast and brightness using the knobs on the MFD the have a clearer image.

Oh and I forgot to mention that the B-sweep freezing bug is still there (0:10). Also a really annoying bug.

Yup, have had the same issues as you. It fixes it self after takeoff so it is only really a cosmetic issue. (wild guess here) I think it has something to do with the revised carrier deck code to stop people slipping off it.

In this clip I fire a total of 4 AMRAAMS with a TWS lock at an F-16 with my F-18. Only the 4th one manages to start guidnace to the target. Before the start of the clip I had already fired one AMRAAM from long range (~50 nm) and it went up high without lofting even tough I had a TWS lock. This can be seen at the start of the clip as an active AMRAAM on the right MFD. The 2 other missiles go stupid in the same way. I want to say this again but this happens only SOMETIMES but when it happens it is infuriating. Video is from today. I do not have the track files but I can download the whole scenario Tacview file if it is required. Link to video: https://a.uguu.se/ylAMFOEu.mp4 (Hosted on a free hosting site)

Gliding in the Hornet is near impossible due to the flaps extending to 100% uncommanded when hydraulic power is lost. I'm not certain of why this happens, but I think it is not a design feature of a combat aircraft to drop like a rock when hydraulic/engine power is lost, especially if you can still steer the aircraft with secondary control laws just fine. I hope someone would investigate this and see if this is a bug or a really bad design problem. Hornet Flaps at 0 fuel.trk

If you pull the emergency brake handle nothing happens. Correct if Im wrong, but It should always work when it is pulled?

Also note that this bug only works if the battery is on. Otherwise the elevator is stuck.

Solidworks I have solidworks and the FLOW CFD. My question is, how can you import .EDM files to solidworks? I can't figure it out.:helpsmilie: