Tiromir

I found myself hit by a missile in a sortie, and lost my right engine, all hydraulics power as well as control over my right wing pylons (nice to see the damage model is still a WIP, but has cool functionalities on the way!). I managed to limp home but found out when approaching the airfield that the emergency landing gear deployment handle, located under the left side of the main panel, was neither clickable or bindable. When can we hope to see it modelled? Thank you for your time

We shouldn't have to adapt at all. This is a russian aircraft, and this variant was always historically used in metric. Only the 29G was in knots, a variant this module specifically isn't. I understand the wish to make the module easier to access by those who are used to western cockpits, and i'm happy imperial units are included, but they should in no way be the default in either the tutorials, as mentioned here, or in the manual, which hasn't been mentioned so far. I'm not sure about the tutorials, but I can confirm the russian manual is in metric as opposed to the english manual, which is in imperial units.

I believe as of now the avionics and gauges values are set through two different settings: Avionics, through the very, much too general "units" overall DCS option and gauges through the cockpit language skins, which we'd need an option for English Metric (this is meant to be a russian cockpit translated to english, not a western cockpit), and possibly Russian Imperial.

Hi Aerges, Since 2.9.15.9408 dropped, I've had the english voice ALR-300 voice and had to adapt to the less convenient gear lever and firing safety logics. Before that, i'd gotten used to my preferred options, enjoying the historical spanish and french voices, and the keybind logics that made sense with my peripherals setup. I understand this change is from last patch, developed in this line of the patch notes: I'm curious as to why this change was made, and if it really is necessary. It's nothing dramatic, although the new version may be quite inconvenient, the F1 is too good a module to let up for such a small reason. I suspect it may have been motivated by better synchronisation when multicrewing the BE, but I can't know for sure. If that were the case, I'd like to request that these changes are only made to the F1BE, without affecting the EE or CE. If the change was made for another reason, I'd like to request that this reading from server be made optional. I understand some may want to standardise the functioning of all player aircraft, but I believe that is a very invasive change that isn't justified on bigger multiplayer servers. Thank you for your work!

It seems after yesterday's update, the problem remains. Formation lights are partially visible to others, nav lights are exclusively visible when set to the "CLIGN" blinking position, and not the solid position.

Would be great if you could post about this in the bugs section of the forum

AS-30Ls are laser guided. We have no means for radar designation in our F1, and none are planned, so it won't come.

Hey, guys We just ran into a similar issue to the one reported by Kerosene on Oct 19th on a night mission today. I'm not sure it's exactly the same one though. No other MP pilots able to see another's navigation or formation lights, when they were visible to ourselves. Taxi light functioning as expected and visible to all users. We ran into the problem in a quite long mission in which I confirmed multiple other users could not see these externals either. Those were cold starts. Here come two tracks from two different users, myself and Caprice. Mission start on Kola in the dead of night. We just hopped in to hot aircraft on Rovaniemi airbase and flicked our lights back off and back on, then confirmed our own lights were visible but not the other aircraft's. Let me know if there's anything I can do. Thanks! F1LightsCaprice.trk F1LightsTiro.trk

Great! I'm happy this was so quick to figure out. All that's left now is to cross our fingers and hope the delay till next update is shorter than the delay since the previous one, but I guess we'll just have to improve our gunnery and learn not to rely on the radar so much! I assume you mean not breaking the lock with "telemeter/zo ne scanning switch - CENTER (OFF)" is correct behaviour. I'll be binding "unlock" then. Sorry for the confusion over the radar ranges, mixed units are a challenge we're all facing Thank you for your quick reaction time and letting us know exactly how we could help you. Have a good one! Nice catch! If i'm understanding you right, I guess that placing the Alidade ahead and more or less at the expected range should result in a correct lock with ACM modes? That would mean we have a way around the problem until the fix gets released to us through the next DCS patch.

Hi Vibora, I've just taken her up to test this out, here are the tracks. Target was always an IL-78, plenty of radar returns to be seen. F1ACMModesChase.trkFirst, Ideal conditions for a pulse radar with no doppler which I believe is what the F1's Cyrano IV is, on the 6 of the IL-78 at 5000m. I have achieved a lock, but only within around 3.5nm of target, halfway down the 7nm display, despite the manual's description (p.108)stating automatic lock from 7nm and the Ilyushin's radar brick being clearly visible on the cockpit display. Locking is reliable within this 3.5, but impossible out of them. Once too close, i manoevre to get some range and try again. F1ACMModesHeadOn.trkSecond, even better conditions: same aircraft and altitude, but head on. Same conclusion: No lock until 3.5nm, then lock. F1ACMModesLowAlt.trkThird, at low altitude. First in a head on, then a chase. I manually lock the target to gain visual, then try to lock in the head on pass. Despite the radar display showing the target, i thought it could be reasonable to assume you guys implemeted some limitations in such extreme look-down cases. So I turn around to chase and give it more attempts, to no avail, whether I get a couple miles of separation or i'm basically point blank, whether i'm making the radar look down which may lose the target in ground clutter or looking at this behemoth of a plane against nothing but clear sky. I'm certain the the radar as currently modelled is capable of acquiring a lock in all these situations, as I occasionally show by locking the target manually in HA mode. Moreover, the target's return brick is, in each of these cases, visible on the display itself (as highlighted by @bramimond). I'd therefore expect it to get locked just fine. It also seems i'm unable to break lock using the "telemeter/zo ne scanning switch - CENTER (OFF)" input, which previously was my go-to to abort a radar lock. Thank you for your work.

Hey guys, I just hopped on with a fellow F1 enthusiast to try out today's patch. We had no success on any TL or BZ locks, which we tried between 2 and 5 nm, targets contrasting against the sun, even though we've both gotten hundreds of such successful locks in the past. I think any radar misoperations can be discounted given that both our separate radars were on, with targets square in the HUD. Has anyone been able to get it working?

Thanks for your explanation. The aircraft just feels so different in BFM to what it used to be, I was really taken aback by how that delay (on top of the sideslip induced roll) affected the aircraft's behaviour in the context I prefer to use it. I'm weirdly sad that you guys have done good work this time, as it kinda goes against my personal use of the F1. I guess it's back to 2022 when you released the F1 in the first place, learning how to work around the airframe's weaknesses and gitting gud.

Dear Aerges, The F1 has slowly but steadily become my favourite aircraft in DCS. Patch 2.9.6.57650 has seen a number of changes to the Mirage F1's flight model. I am grateful for all of these, as the FM truly is the heart of any aircraft's simulation, and I believe it a domain that can hardly get too much polish. Among these changes, there is one that stands out to me: I wish for this change to be reverted, or made optional, as it stands as an artificial delay between player inputs and how they're translated to the aircraft. It makes the light fighter and strike craft that the F1 is significantly more sluggish in any combat manoeuvre context, to a point that I just don't recognise it compared to its pre-existing state. This change just feels like it makes any flying of the F1 under pressure blunt and haphazard. Secondly, and less importantly, outside of the interface between pilot and aircraft, it also harms the F1's competitiveness, as I don't believe any other DCS modules have such delays, or at least not to this extent. I'd like to know more about this change. What "speed movement limitations" is it meant to reflect from the real aircraft's behaviour? Is it a hard set limitation to how mucht eh F1's stick can be moved at a time, or rather a difficulty, a required force? Thank you for all your work.

Thanks for your time! Hope this gets the attention it deserves

ColonelAgile has a point, also, yeah, proper radar modelling will drastically affect the delivery of radar-guided missiles. A "simple tutorial" takes time to make, and Aerges might already be tight on manpower. Other modules lack proper training missions, or have in the past, and there are many other ways to learn, including fantastic community-made guides and a detailed manual made by Aerges. Until the module is fully developed (radar and F1M included), I don't think this is a priority.