IvanK

The "suck in" happens when you're really close (next to the leader's wing tip) and then going forward. You'll reach a point where you'll suddenly need much less power to maintain position. I'll see if I can possibly record a track during the next days. That is unrealistic in itself.

Did some F1 on F1 close form Echelon, Line astern and transits from Echelon Left to Echelon right through close line astern. I did not detect any "Suck in" effect in normal echelon. In transiting through the close line astern position the roll inputs were imo consistent with what I expect most of the time. Occasionally a severe wing drop occurred. Trying to figure out exactly where this occurred is problematic as it had a certain amount of randomness to it. Transiting the line astern slightly low and around 5 aircraft lengths back the encounter with wake turbulence was gross and way overdone imo considering we are similar types and identical weights and AOA etc. Retested with Wake turbulence off and things were to me more consistent and dare I say it felt more natural in close formation.

In a standard echelon position you should not require ANY aileron input. ... if you get super close with wing overlap then yes.

Tried F1 on the wing (echelon) of an SU27 ... no issue. You shouldn't really be flying echelon with any wing overlap anyway Did some stuff in the line astern and transitioning with Wake Turbulence enabled, seems a little bit random to me. On some occasions not a big deal on other occasions a very large roll disturbance occurred. Be nice to be able to visualize the vortices to see whats really going on.

Ok I dont fly with wake enabled will try and have a look. Changing from echelon through line astern and into echelon on the other side does in IRL (in almost any aeroplane) require a reasonable amount of aileron input to hold wings level in the transition as go through the wing tip vortices. So the next question is this DCS wide or F1 specific ?

What exactly are we talking about here ? ......... aerodynamic Buzz/buffet as a function of AOA ?

I think its actually a DCS limitation. VORDME stations are not coded as such. VORTACS work so it shouldn't really be a problem to code VORDME stations.

Going to ask the devs directly

Thats an interesting speculation. Does DCS actually have a tropopause ? is there any way in game we can determine it ... like temp v alt etc ?

RAAF F35 Handling display 13/11.2022

Wingtip is R550 training round. ECM pod on the wing pylon

To me its as shown below for the IR missiles anyway

You brought up Israeli guncam footage thats all Mirage III footage. You implied that based on that footage the Mirage III had similar function to the F1 as set by the GYRO/ANT switch (whatever that does) My response was dealing with the Mirage III CSF97K gunsight that does not have any GYRO/ANT function .......... not the F1 As to the Gyro gunsight diagram you posted that comes from the F1ED NWS manual pg 175-55. Its worthy of pointing out that the F1ED does NOT have a Gyro/Ant switch. Scrolling down a couple of pages to 1.75-61 is a large complex functional table.In the two Gun related sections there is reference to "antenna tracking errors (full scale) and also the curious phrase "future prediction angles for radar distance (firing at a fleeting target)" which might imply some sort of snapshoot mode (similar to the F5E sight). It does imply that in the F1ED the Antenna angle and or antenna angular rates might be a factor in the F1 prediction angle calculation. Also it would be required for the Guns Autofire/blind mode as the small square TD symbol (positioned by Antenna angle) and the guns pipper would need to be in coincidence. Still does not resolve what this GYRO/ANT switch actually does which it seems is unique to the F1CE we have in game.

Not at the moment as far as I can make out.

At present to Deselect in the Mission editor. the three dots at the end of the dialog box that you use to select payload etc.

Yep thats exactly what it is. I have a lot of time sitting behind the Mirage III gunsight Smooth handling allowed very precise tracking. It as also worth pointing out that the original Israeli gun camera film was all shot at 16fps.

I agree there is an issue with the icing model and implementation. I posted this in the Closed Beta Testers area. Not sure if the devs have acess to that area. "On further testing it seems the "canopy icing" is external airframe icing. However no sign of airframe icing is visible on wing leading edges and tip tanks which one would expect. It is further strange that this icing can occur in completely clear atmospheric conditions. I started at Batumi in Sky clear conditions with 26c surface temperature. Passing 19,000' the ICE caution illuminated and icing was visible on the canopy. No icing visible on the airframe when looking to the wings. Jumping into external view no icing visible anywhere. IRL the ICE caution is triggered by ice build up on the ice detection sensor on the fin. If there was ice detected and the ice was visible on the canopy then there should be ice elsewhere. You wont get icing without visible signs of moisture (and the right temperature) cloud,mist,fog,rain or snow etc. To me the canopy icing is a scripted eye candy thing that results in just canopy icing, and in conditions that IRL wouldn't result in icing."

Mirage III CSF97K sight never used any Antenna angles or angle rates. Mirage III system was either locked on where the radar range and own aircraft body rates (sensed by the internal sight gyro) was used to calculate prediction angle. Gravity drop was assumed in the aircraft/s plane of symmetry and not earth vertical. A fixed value for trajectory shift was used. No Antenna angles or angle rates were ever used. If not locked on then a fixed range of 6Hm (or 3.5hm if the caged button was used)and own body rates were used. Again a fixed Trajectory shift value was used and Gravity drop for either 6Hm or 3.5hm if caged were used.

These square lights/pushbuttons are visible on MB339A when the RGS2 is not mounted. I don't think these should be here on the MB339A. They should only be there on the PAN version.

Re tried displayed Present Position (Mode data pg 3) still in error. Not Data pg 2. TRK attached MB339PPos.zip

Testing further. Given Navigation is correct I think this is a straight display of present position problem. If you make a MARK point the Lat Long is correct and when you call up the MARK point data the Lat Long is correct.

The CDU displayed Present Position (data pg 3)does not agree with DCS present position.

Be really nice if you could have an option to have the RGS2 on its own without the camera fitted on top. Its non functional in the sim and is a removable item IRL.

You can enter Western Longitudes. To do so first Select the Key next to the the Longitude entry. BEFORE typing any values press the CLR key , the Longitude identifier will change to "W", then enter the digits. Same procedure for Southerly Latitudes. If you try to do a MANUAL IP entry using this procedure for alignment you need to be quick, as the system jumps into alignment even if you have not finished entry a valid start Lat/Long. EDIT: after some more reading the jumping into alignment mode automatically is normal and occurs as soon as the system gets valid GPS data. then uses GPS position to align. .... I guess the only time you need to use Manual or last stored position is if you don't have GPS. Regardless once aligned the STEER function works as intended, Select STEER then say Airport Rng and Brg displayed are correct and work in flight. Though calling up a SB waypoint to see its Lat and Long doesn't provide any values.

I can go 0.95 to M2.0 in 3:28 for 990 litres burnt Clean aeroplane Profile: 0.95/F350 Start the clock , 0.5G pushover to 10deg nose down, level at F300 accel to 650Kias , climb at constant 650Kias (Increasing Mach) till achieving M2.0. Tried the same using Mir III profile climbing at 580Kias took 10 seconds longer. Machrun.zip