IvanK

See the Thread "Mirage still pulls to the left"

Flip flooping the wind proves that wind is causing the directional control issues. With 2Ms (about 4Kts) crosswind the aircraft is just controllable. Full rudder can stop the heading divergence and bring the aircraft back on to the centreline. However you still end up at least in the middle half of the upwind side of the runway before any directional control is achieved. Given that the drift starts at around 80Kts I am presuming that the NWS is input is washed out as you accelerate and you relying on pure aerodynamic rudder input for directional control. If so it would seem that this is insufficient..... which also imo is a basic issue in all flight regimes that is I think the Mir2K's response to rudder input is very very weak. It would be very interesting to see some data on Rudder deflection versus IAS for the Mirage 2K. The Flight Control system I would think would limit this at the higher speed to prevent Fin overload etc. If this happening at too low an IAS perhaps this is cause for concern ?

Tested In Nellis Ver 2.03.5945. Nil wind no issues. 10ms Surface wind (so around 20Kts) all crosswind. Up to around 40Kts no dramas then the weathercock into wind starts. the aircraft cannot be held straight with full pedal deflection with NSW engaged. There doesnt even seem to be any reduciom in divergence with full pedal applied. Will retest to determine max crosswind that is ok. I believe Mir2000 crosswind limit for take off is 25Kts. As such it should easily be able to cope with 20Kts cross. Mirage III had a 25Knot (clean) crosswind limit for take off, No NWS just a castoring nosewheel and diff brakes. Aircraft could be easily held on the runway Centreline just with aerodynamic rudder control from around 40Kts or so. Something is wrong with directional control and wind in the Mir2K.

Ok thanks Jay done now working okay.

Err Map to what I mean shouldnt the R500 seeker automatically slave to the radar target if you take the lock with R550 selected ? Or does it behave similar to cage switch in that you have to manually command the slave after lock ???

Ver 2.03.5945 Every time I hit refly for a manually built mission I get a DCS has stopped working message. Seems identical to the earlier instant Action refly crash. Win10

Though I read somewhere in the various forum threads that with the latest update (2.03.5945) the R550's would slave to the radar. I don't see this with manual locks or CCM locks. I still need to put the Gun cross on the IR source for the R550 to lock.

New HUD with VV referenced to the pitch ladder is great. However the ILS presentation is still bugged in that the Azimuth (localiser) line on the HUD still behaves erratically. As you apply a roll correction the Azimuth line and its Anchor point mark on the horizon line moves (darts) in the same direction as roll. should it not always be positioned in azimuth to indicate a Fly To direction to the ILS localiser ? in effect its unusable see attached Track. this with Ver 2.03.5945 ILsbugtrk.zip

Yep exactly the same for me.

For what its worth the USAF manual is a little firmer in its recommendations as to which mode should be used for Snapshots.

Ok thats really interesting. I did some simple ground tests. From a standing start I needed 62% to get the aircraft moving. Once moving I selected 60% aircraft was slowly accelerating. at 15Kts I selected Idle (50%) aircraft decelerated and eventually came to a stop.

Guns A/A1 is fundamentally different to Guns A/A2. Guns A/A1should be thought of as a Snapshot sight you don't need to stabilize the sight or even achieve the the targets plane of motion. Guns A/A2 is the conventional LCOS sight that requires steady tracking for the sight settling time x the bullet time of flight. See below the excerpt from the manual that illustrates the completely different sight handling available in A/A1. As can be seen Open fire can commence prior to pipper target co incidence

How did you figure out that 60% is min thrust ?

Engine smoke is still excessive compared to real life F5E. http://forums.eagle.ru/showpost.php?p=2851063&postcount=1

Navy F5EN specifically discuss carriage of AIM9L/M

So in essence using the Trigger you are placing a UHF ADF on the map ?

Is there a link to the video from where this came ?

Great Work Mbot slowly getting to the bottom of this. I agree using measured in game AOA rather than the dash 34 chart is the way to go. Also need to add the huge Altimeter lag we have in game. For me I now go out and fly the planned pass in game and note both actual AOA and Altimeter lag (thanks for the idea). I use the recorded in game AOA for the calculation and then apply the noted Altimeter lag to the altimeter for the actual release. For the devs I guess they could play with AOA in the FM (I doubt they will) or publish a DCS AOA chart..... or we users could if we all got together produce our own measured AOA chart. The Devs have indicated they will look at the altimeter lag issue.

How in the DCS F5E you cant tune NDB's ?

Interestingly many F5E's are equipped with Anti Skid ... including the Swiss ones as the Anti Skid On/Off switch is located on the centre pedestal. This F5e is not modeled with Anti skid.... so very careful use of the brakes are required.

The Artificial Horizon (AH) on the Belsimtek F5E has both a Sky Pointer and a Ground Pointer. This is incorrect the Real F5E AH only has a Ground pointer ... thats why the Bank reference scale is marked on the lower side of the case. The Sky pointer should be removed.

Mbot I know you discussed this in the other thread. AOA(FRL) from the chart you come up with is 36mils. In your Screen grab it shows AOA of 0.9deg or 16mils. Assuming the AOA displayed on the screen bar is FRL referenced than the diff between the chart AOA and what you achieve is 20mils only 6mils diff to the angular bomb error you show in your graphic of 14mils. So if my mental gymnastics and lines in space are right then if your Game and all other parameters are correct using planned numbers with pipper on (assuming game bomb range is the same a chart bomb range) AOA is 16mils less than the Chart AOA it would mean that if using Chart AOA figures (38mils .... just talking about FRL referenced AOA)) then bombs would go over the top.... since the error would result in a weapons release point closer to the target, pipper on. So it follows to get bombs on target would require the actual in game release point to be further away therefore to have pipper on would require less depression ... by about 16mils in this case.

Nice Job ... but as in the other posts I believe the real issue is Altimeter lag :)

Just did some testing on Diskey's findings. Basically if you select the first digit as "T" it then allows you to tune any VOR or ILS station ...i.e any VHF navaid. the "T" representing the first digit as a 1. So tune whatever VOR or ILS you want then select the UHF selector to DF and the Nav selector lower down to DF and the HSI bearing pointer will give you mag bearing to the tuned VOR or ILS localiser station. No DME is available but bearing is. So in addition to the VOR stations Diskey labelled the following ILS stations are tuneable as well: ILS LOCALISERS Kutasi 109.75 Koblutei 111.50 Batumi 110.3 Min Vody 111.7 and 109.3 Nachlik 110.5 Beslan 110.5 Tiblisi (Lochini) 110.3 and 108.75 Tiblisi Vaziani 108.9 and 108.75 Great little "Easter egg" Now to play around with the "A" setting to see if it allows certain NDB's

The T and A positions are IRL I believe associated with HAVE QUICK and setting it up with the the cyphers etc. Not sure it should be working the way you describe but great find. :) The 2 and 3 are there just to select the first digit which in the UHF band can only be a 2 or a 3 .... for like 234Mhz and 305Mhz