sedenion

I would ask the same question about the F1C, since I guess the differences between F1C and F1CE are very minors (I think it is only a mater of Sidewinder)... Anyway here is the cockpit of F1CT... it appear modernized compared to current CE variant (Central weapon panel, HUD and stick remind the 2000C). And here is the F1C cockpit (with missing HUD, apparently) and here, it appear to be exactly the same as the F1CE...

The Mirage F1 vs F-14 is very similar to what I experience against the Su-25 and Mig-21... So, yes, interestingly, even the Su-25 pretty easily overshoot your Mirage F1 (which is pretty funny to begin), but without the ability for the Mirage F1 to pull noze to properly reach the target... I have only one thing to say: Try yoursef a guns-only against a Su-25 and Mig-21 and, you will see if everything appears normal to you. I know I have a biasis because I mainly come from the Mirage 2000, which is very agile and very easy to pilot, but... Honestly like the first version of the Mirage 2000 flight model appeared prolematic to me, the current state of the Mirage F1 fligt model appear problematic to me... Not dramatic, the basis is good, it simply need some adjustments here and there.

Don't worry, I have thick skin. That's true, I mainly use rudder (erzats) only for taxiing, which is not an huge problem for all Modules I have... Anyway, I am aware that rudder may be usefull in many circonstances for a better aircraft stability. This topic originaly don't focus specifically on yaw instability, but also pitch sensivity, an finaly the flight model in general, since the question was : "Is that normal I can't even dogfight a Su-25 ?"... meaning, between the lines : "Are you sure the real Mirage F1 fly as bad as it fly in the current state of FM ?" Then, once the Mirage F1 was compared to the Mig 21BIS (Like the Mirage 2000 when released in early access <cough cough>), we had some consideration arround: - It seem the real Mirage F1 have yaw dampening system that seem to be not implemented yet. - It seem the real Mirage F1 have several pitch regulation systems, that seem to be not properly implemented yet. - Maybe, the current FM implementation need some adjustements... So, to answere HWasp dans la foulée, it appear reasonable to me to wait and see if developpers have some adjustements to do to the current FM, before investing in a rudder device and considering cropping Y axis curve by 40% as a "normal state"... And, once again, the same thing happened with the Mirage 2000, same reactions, etc... So, I am not afraid, I am pretty confident that things will go better and Mirage F1 will finaly be able to properly catch a Su-25 and beat a Mig-21 in guns-only (without over-tuning axis curves nor buying a rudder)...

And, here we go again. No, that's not what I was saying, but, as always here, once you emit a single question about current FM or Radar implementation of a (early access, for recall) module, some people simply don't tolerate such questioning and blame the fool heretic that dared to emit some doubt about the pure fidelity and finishness of modelisation which, as everybody knows, is always directly perfect, absolutely complient and non criticable. Same thing happened with the Mirage 2000... So I am not so scared. Topic is end for me... thanks

This part of the manual explain the risk of spin by rolling unreasonable way at low speed / High AOA... which is true for almost all aircrafts... in the same logic : beware, at very very low speed, the flight controls are not responding anymore and aircraft begins to fall like a stone... The main problem here is : what exactly is "low speed", and "high AOA". "low speed" and "high AOA" is not the same for a Cesna 172 and a F-16... So, at which speed it become impossible to properly stabilize the aircraft roll and yaw without constantly playing with our feets ? It is absolutely normal to have a very careful manoeuvring at landing, but, landing is a very specific situation.

Did you downloaded the latest version (v1.4 actually) of the mod from DCS world website, or the v1.0 from the attached file ? (I will delete the atached file, it is no more suitable with current module implementation, and update with the 1.5 version)

Nop. See above... Mirage F1 also have such limiter, but it is not ARTHUR... I tried with and without, I did not noticed big difference since below 300 kts (which seem pretty high speed to me, but maybe I am wrong) the aircraft become very hard to manoeuver.

I don't blame anything... I simply tell what it is. Currently what I found after some reasarch, is that the real Mirage F1 actually HAS yaw damping systems, and one in particular named "ARTHUR" [EDIT: in fact it seem to be a kind of "power steering" but applied to stick moves], which, I am pretty sure is currently not implemented in the module... I also guess (this is a guess) that the current Pitch electrohydrolic mechanism is either not implemented, or need adjustements. It is also mentionned a pitch auto-trim... Here is what I found in french forum about Mirage F1 controls (which seem a not exhaustive listing) : https://www.checksix-forums.com/viewtopic.php?p=1832909&sid=647aa22917dff2eecb3d0c4f0b657826#p1832909 Translation:

Ok, sorry for the peremtoire sentence, but be honest, the pitch sensitivity is too high. Yes, you can deal with the native response curve by moving the stick in a extremely gentle way but even for normal manoeuvers, you go above the red very quickly. So, in dogfight, where you try extreme manoeuvers by definition, you clearly need a saturation croped response curve, unless you want to train for rodeo contest...

I don't have real rudder device, I use warthog throttle mini-stick as ersatz, which is sufficient for my usual usage (taxiing, mainly). I tend to think like Nealius stated in the post above, there is currently a lack of automated controls assistances. Mirage F1 is not a modern aircraft, but it is definitely more modern than Mig-21 for example (and with a more classical wing configuration) and it comes right before its well known sucessor, the Mirage 2000, which is full FBW. And as we can read in the current manual, there is actually (theoretically) plenty of automated controls assistances, as non-exhaustive example: Pitch mode switch: allows to activate and deactivate the pitch electrohydraulic mode. Yaw mode switch Anti-slip/Yaw/Off: allows to deactivate the anti-slip mode and the electrohydraulic mode separately. ARTHUR switch (under guard) AUTO/HIGH/LOW: Allows the pilot to select the sensitivity mode of the ARTHUR To what you must add the Combat Flaps mode, which indicate that the aircraft was not only designed for ground attack or air-air missiles (unlike the F-4 Phantom for example)... I don't know how much these controls assistance systems are currently implemented in the module, but my guess is that they need adjustements. As everybody noticed, the aircraft is currently almost uncontrolable in pitch unless you crop 30-40% saturation of the axis response curve ... which is HUGE, and probably NOT normal. And at this precise subject, even without simulated control assistance, we can guess that the real controls stick have progressive resistance, requiring high strenght to pull out the stick as its maximum amplitude, in order to avoid ludicrous manoeuvers... and this should be also implemented as a response curve within the module, since our toys are unable to reproduce that.

Tuned axes, made my best... I give up for now: I tryed guns-only against AI Su-25 and AI Mig-21BIS, I am almost unable to get fire oportunity against Su-25 and got hit by the Mig-21 after few turns. I am probably not well trained, but to me the Mirage F1, as it is, in addition with the lack of proper gun sighting system, is unable to dogfight.

Indeed, adjusting curves may help transforming the aircraft in a jumbo-jet by avoiding any excessive (usual) manovers, but de facto, a jumbo-jet cannot dogfight an Su-25... The problem seem to be that you have to transform the aircraft in a jumbo-jet to fly it in a stable way.

I know this is an old aircraft, I know there is no FBW, but is that normal I can't even dogfigt a Su-25 ? The plane is incredibely sensitive and unstable, especially in yaw, but also in pitch... It is almost impossible to keep track on target, at any speed, each stick impulse in pitch or roll creates huge oscilation that shake the aircraft like dead leaf in the wind.

Ok Indeed found the option. For information I have to set it to 78 on my side. Anyway, the dead zone problem still here.

The deadzone is a module problem. I mentioned all module need axis tune, but here the tune is, to me, problematic, especially the fact that almost half of the valid throttle travel, giving useless precision on afterburner reducing precision in non-AB, where you need it, for landing for example. I don't know what you are talking about. The deadzone I speak about is clear and obvious: The first part of the axis course do not move the in-game throttle, so, the first part of the axis is simply ignored by the software. There is a software implemented deadzone. I don't know why, but this has nothing to do with taxiing or engine response consideration. The deadzone amputate precision, the curve make the input/output response non-linear (definition of a curve) which is counter-intuitive and makes the throttle adjustment less fluid. A little bended curve is not a problem, but here, with 25% curvature and 15% amputated throttle move, this become clearly non-natural. If no modifications were made by developers, this is what I will do. Anyway, I let here the problem of the deadzone (which is not hardware specific) et let developpers hear my opinion about the dry vs AB ratio in axis range. Ok, sorry, I was not aware a new version was available... I check this out.

Sorry, how do you did that ?

Hi, The first part of the axis has a relatively large dead zone (see picture bellow) which will amputate a part of the physical device precision. [EDIT: edited to let only Dead Zone problem, since the AB detent problem was solved with latest update]

The aircraft name is "Mirage F1" and "Mirage" is actualy totaly part of the name. "F1" is kind of "variant" or "generation" of the same family (Mirage). That's why you have "Mirage III", "Mirage IV", "Mirage V", "Mirage 2000", etc. If you forget "Mirage", it is an error. Before "Mirage" family there were "Mystère" family, and now you have "Rafale" (and NOT the frequent misspelled "Rafael"). So, to be clear and strict, you have: Mitsubishi F-1 Dassault Mirage F1

Thanks

Hi, Sorry if that was already reported, but I did'nt find any mention of this since now. Is that normal the HUD pitch ladder is visually so misaligned from the "visible" pitch ? I know the hud is very small and maybe this is intended, but here, there is really a huge gap and as it is, it act more like an ADI drawn on the HUD than an usual pitch ladder.

Yes, OMM warns you that each mods are writing/creating and overwriting the sames files... this warning is not blocking, you can continue. The reason this does not work in DCS is out of range of OMM, this may be because mods are not properly designed, and I guess your problem come from the fact that your mods are not designed to be "ready-to-install" via a Mod Manager, so the result is a wrong folder tree (bad installation) in the targer folder...

In any case, except you cancel operation, all files are installed. The manager only warns you that installed files will overwrite previously modified files. Manager will also create kind of backup dependency tree to keep ability to properly restore initial files. You can disable the warnings in the Target Location's properties. If you have problems installing two mods simultaneously, with one conflicting with another, this is up to the mod designer to prevent that if possible. OMM only installs - in a safe way - files of the mods, it is not responsible of how the mod is working.

If you want to host/manage a repository, you need a web (HTTP) server, where you can put files for download. In other words, you need a website where you can provide files to download. There many ways to have a website, from personal hosting provided by your internet provider (if it provide such service), to paid VPS dedicated servers, some solutions are suitable, other, not. Anyway, "How to have and manage a web site" is a question on itself, which is not the topic of this thread and one can not provide you a short answer for that.

Please explain what you want to do exactly. If you want to provide/host a repository, you need a web (HTTP) server, or at least, a website you manage where you can provide public access for package download and so on.

First, if you properly name your packages, the version of these packages will be properly parsed. So, to begin, you should name your packages as follow, the 'v' make all the difference: 40th Livery Pack - phoenix _ v1.9.0512.zip 40th Livery Pack - phoenix _ v2.0.0529.zip If package version is properly parsed, OMM compares packages versions between library and those available in repositories, if package with a newer version is available in the repository, it is signaled by a small orange star icon, so the user know this is a new version of a package. From there, user can either: Download the package: The new package is downloaded, the old package is not deleted. Upgrade the package: The new package is downloaded, the old package is (default) renamed with .old extension (it become invisible in software) or moved to trash. If user double-click on the repository package (instead of explicitely choose download or upgrade from menu or button), the software prompts a message box to ask user if it want to keep the old version. and HERE is a small bug, the displayed message is wrong, and user should read "do you want to remove the old package" instead of "do you want to keep the old package" (my bad, I just catch it while testing it myself). Anyway, this is not dramatic si the file is not definitely deleted. (EDIT: you can download the latest 1.0.1 version which fix this bug) I hope this is now clearer. Before considering metapackages, you can tell your users to change the default behavior of package upgrade process : Edit > Target Location Properties > Network repository tab > On package upgrade: Move older version to recycle bin. This will prevent user to have to manually clean their library folder each time they upgrade a package. This is probably what is the closest to the OvGME behavior. Anyway, I think user are tall enough to organize their Mod library folder and clean if required...