mrkline

Is this a bug, or how the stick actually operated? It makes it quite hard to accurately place marks if you're moving at a decent airspeed.

I was lining up with a Tomcat on a runway, and when I looked over my shoulder again, half of its textures had disappeared: EDIT: sorry, meant to put this in the bugs subforum. If someone could move it that would be great.

Both supersearch and the normal scans still jump back to center in 2.5.4.30038. Watch how the azimuth and elevation settings zero themselves whenever switching modes, or when commanding supersearch with an HCU half-action: Did this miss the release window and get slated for the next OB?

Yes, which is why you can maintain a PSTT lock even if the target is below you, so long as they don't get too close to the ground. You can even see the range gates on the DDD. From TFM:

Unfortunately I've lost track of which day I saw this in the time since it happened (2+ weeks). If you're just looking for the mission layout, I've attached a recent track on the same server (DDCS), but I'm not sure how helpful that is. If I see it again, I'll try to grab a track file. DDCS-Modern-CA-3.12_Spring_1-20190414-205921.trk

I don't, sorry. I was just doing contrast locks on various objects as we went in for landing in multiplayer.

The April 10 Open Beta still seems to show the following behavior in multiplayer: Radar volume snaps to center whenever switching modes, then returns to the desired AZ/EL once those controls are touched. Supersearch seems to ignore EL knob (but does respect the vernier thumbwheel) until AZ/EL controls are touched.

In the guns-only ACM instant action on the Nevada map (against an F-16), the CADC needs resetting when you spawn in, as if you just pulled the wings out of oversweep: I haven't checked if this happens on other instant actions where you start in the air.

Thanks for fixing the desync in the April 10 patch! The strange sound loop is still there, though. It seems to happen randomly, maybe half the time, instead of the usual "click" of the arming handle snapping down.

While grabbing more gas after a sortie, I saw this from the back seat: Interestingly, when the external tanks were attached, the fuel level decreased by about 2000 pounds each time instead of increasing, causing the gauge to end at the usual 20100 pounds.

After crashing out of the RIO pit and trying to rejoin my pilot, controls were unresponsive and I got the following: The problem went away when we got a new bird. Possibly related to https://forums.eagle.ru/showthread.php?t=234981

I was futzing with the TCS on approach and this happened: The TCS contains a single camera, yes? I assume it shouldn't jump between multiple targets as you switch zoom levels.

The good news is that supersearch now scans however many bars you've set. The bad news is that it still jumps to the centerline until you mash the AZ/EL controls in 2.5.4.29167:

This affects supersearch too: When commanding supersearch with a HCU half-action, elevation snaps back to center until the user futzes with azimuth or elevation controls. Watch the antenna elevation meter.

What it says on the tin:

I've got it on video, which should demonstrate the bug better: Here I've got several contacts about 25 miles off my nose, as you can see from the initial DDD picture, and on datalink. But once I command supersearch with an HCU half-action, those contacts show up at the correct range scale for a single sweep, then suddenly show up at the bottom of the DDD as if the range scale was set to 200 miles.

If it was only due to latency, you wouldn't see completely different flight paths from the shooter's & everyone else's perspective. That shouldn't have anything to do with whatever lag compensation is being applied. Hopefully this is addressed soon - it's a huge issue in Multiplayer air-to-air currently, as folks have to try to defend Phoenixes that are in completely different places than what their client is showing them.

Yep, previous report + video at https://forums.eagle.ru/showthread.php?t=235070. The game seems to ignore what the RIO does - unless the pilot arms the RIO's seat, it won't fire when either crew pulls the handle.

Right, but: It doesn't matter what the server and target see - since the shooter is who determines what the missile actually does, the missile isn't "passively" tracking, even if that's what everyone else sees. Right, and this is an entirely separate problem, previously acknowledged by Cobra to be on ED's side. The desync is a serious issue, but I was responding to claims that the missiles also passively seek their targets when you turn cold.

As soon as you command supersearch in pulse search, DDD range jumps to 200 miles, despite the range rotary showing whatever it was set to previously. Here I've got the TID set to 100mi, the DDD set to 50mi, and datalink is showing targets about 40 miles out. But as soon as I enter supersearch, the contacts appear on the DDD as if it's set to 200 miles: The DDD stays that way until I hit the "50" button again:

I think there's some misinformation here. Yes, ARH missile behavior has its quirks (lofting desync, going pitbull at a hardcoded range, etc.). I hope these will be addressed soon. But, the missiles don't seem to magically track targets before going pitbull. I've attached six TacView tracks of me firing a Phoenix at a Backfire, about 30 miles out. Half are in TWS, and half are in STT; the behavior was the same in both cases. In each radar mode I: Turned cold (and lost the radar contact) within a second or two of launching Supported the missile for about 10 seconds Supported the missile for about 20 seconds In the first two scenarios, the missile stops lofting and snaps downward as soon as I lose the contact, but it does not immediately start tracking. It instead flies a straight line towards the contact's last known position until it reaches pitbull range. Once pitbull, the missile snaps towards the target, tries to play catch-up (since it was aiming at a point behind the target), and loses too much energy to hit. In the last scenario, where I supported the missile the longest, the missile is in or near pitbull range by the time I lose the contact. Having lofted most of the way, the missile has plenty of energy to hit the target. FWIW, I ran this in a multiplayer session, and a friend ran a similar experiment in singleplayer. So unless shooting at a human target, or being in a heavily populated server like BlueFlag or DDCS somehow impacts missile guidance (which I highly doubt), Phoenixes do not magically track their targets before going pitbull. I'm pretty sure people got this idea because they do suddenly stop lofting and change course. But they're only snapping to the target's last known position, so supporting your missiles increases your PK, as it should. I think the perception also comes from the desync in what the shooter and the rest of the server are seeing, as <Blaze> points out. phoenix-test.zip

Not to my knowledge. I'll keep posting here until it's tagged per the bug reporting sticky (https://forums.eagle.ru/showthread.php?t=236238)

The ejection desync is still present in the latest OB (from March 27).

This is still present in the latest OB, but seems to only show up in multiplayer. In singleplayer, the radar doesn't jump at all: I'm assuming this makes it some sort of network sync issue as the RIO transitions radar modes.

In multiplayer, the RIO often sees a fuel caution: It stays on the entire flight, and doesn't seem to go away when the pilot presses MASTER RESET.