sedenion

Indeed, my mistake, I did not replicated a small change from the vanilla version. I just uploaded a new correcte version, you can download it againt, this should be fine now.

The mod was updated according the latest Mirage 2000 Module update released with DCS World 2.5.6.45317 (Open Beta) Follow link in the initial post.

The mod was updated according the latest Mirage 2000 Module update released with DCS World 2.5.6.45317 (Open Beta) If you use/run DCS World Open Beta you should download and use this new version. Otherwise, wait for DCS World to update to its next version. All informations and download link in the initial post.

Requested by speedbird5 in PM, I let here my latest "universal" Warthog profile: https://forums.eagle.ru/attachment.php?attachmentid=228495&stc=1&d=1582458271 This profile is NOT specially designed for the Mirage 2000 Module, but will at least be usable with its latest version. Since this is more a "private" version than an official release, there is no "readme" and all the documentation for customization and basic usage is within the source code files. TM Combined DX Universal.zip

Is the "Auto" mode for decoys working / implemented ? How it is working / intended to work ?

I second that. if previously in Nav mode, when we go back to neutral after Magic or AA gun mode, the Nav mod does not come back properly and the PCA top row still in "attack/weapon" mode. To exit "attack/weapon" mode we need to manually hit the PCA MAG or CAS button (one or two times) to "reset" the PCA. There is also a bug with le standard radar vs CC modes. If the radar is in "Silent" mode and we select any CC mode, the radar exists the "Silent" mode (maybe this is intented, I don't know), but if we exist/Return to normal mode (Radar Unlock / Exist special mode), the Radar do not return in "Silent" mode, but still in "Emit" mode, despite the radar power switch position on the panel. To return in "Silent" mode, we must manually change de radar power switch position.

Electronics is not what you have to worry about. The real big diference between 16000m and Warthog stick is the feeling and handiness. The 16000M is a lightweight plastic joystick, very easy to manipulate. Warthog stick is an other world : heavy metal joystick, which really require streng to manipulate. A 8 years old can use a 16000M, it will have some trouble manipulating the Warthog.

Indeed, the latest updates are in the DCS Beta version.... It seems Razbam did not released any update for the "stable" version since long time... You better install the DCS Beta version, anyway we now live in a epoch where games are eternally in "Beta" state and never go to the "stable" state, so, forgots the "stable" version, it will never exists... (This message was sponsored by the Buddha)

Maybe it is too late, but some correction and explanation here... To begin, your script is syntactically correct, but programmatically/logically wrong. So, it "compile", it "run", but did "nothing"... nothing effective. The EventHandler() function is what is called a "callback", called (executed) by the driver at every TM physical device state changes. This is not mandatory but it is better (for readability and understandability) to define the EventHandler() before the main() function, because if you look closely in the main(), the "alias" (in C/C++ we would say, the "reference", "pointer" or "adress") of the function is passed as argument to another function. Anyway, except you explicitely want to introduce your own personnal Mapping function to received and send input and ouput frome physical to virtual device, the EventHandler() should always have the same form, with nothing more and nothing less: [color=seagreen]// Event Handler function definition, will be called at every [/color] [color=seagreen]// physical device state change.[/color] [b][color=royalblue]int [/color][/b]EventHandle([b][color=RoyalBlue]int [/color][/b]type, [b][color=royalblue]alias [/color][/b]o, [b][color=royalblue]int [/color][/b]x) { DefaultMapping(&o, x); [color=seagreen]// Default mapping *process* (input -> output)[/color] } Followed by this, you now must define the main() function, with, at first stage, a call to the initialization function, with the "alias to" (Reference/address/pointer to) the previousely defined Handeler callback function (so the programm know which function to be called when it is needed to process an "input event" to generate an "output" event): [b][color=royalblue]int [/color][/b]main() { [color=seagreen] // Initializes the whole mechanics & specifies the event handling callback[/color] [color=seagreen] // function reference/adress (alias)[/color] [color=royalblue][b]if[/b][/color](Init([color=Magenta]&[/color]EventHandle)) [b][color=royalblue]return [/color][/b]1; [color=seagreen]// ...things will continue bellow[/color] NOW, you can add your mapping commands. Theses commands are evaluated ONCE at the script start (when you hit the Start button). Actually, all the "MapKey*" and "MapAxis*" commands are creating some values in a table in memory before the whole thing enter in the "event loop". This table (litterarly a "mapping table") is used to generate the desired output according the physical device state. All this happen within the DefaultMapping() function, called within our EventHandle() callback function. [b][color=royalblue]int [/color][/b]main() [b][color=red]{[/color][/b] [color=seagreen] // Initializes the whole mechanics & specifies the event handling callback[/color] [color=seagreen] // function reference/adress (alias)[/color] [color=royalblue][b]if[/b][/color](Init([color=Magenta]&[/color]EventHandle)) [b][color=royalblue]return [/color][/b]1; [color=seagreen]// "Write" in the mapping table, that physical TS1 must generate DX1 in the virtual combined device.[/color] [color=seagreen] [color=Black] MapKey([color=Magenta]&[/color]T16000, TS1, DX1);[/color][/color] [color=seagreen][color=Black] [color=SeaGreen] // Here we create another mapping for TS2 with Press and Release[/color][/color][/color] [color=seagreen][color=Black][color=seagreen][color=Black] MapKey([color=Magenta]&[/color]T16000, TS2, DOWN+'a');[/color][/color][/color][/color] [color=seagreen][color=Black][color=seagreen][color=Black]MapKeyR([color=Magenta]&[/color]T16000, TS2, UP+'a');[/color][/color][/color][/color] [color=seagreen][color=Black][color=seagreen][color=Black] [color=SeaGreen] // do not forget to close the brace[/color][/color][/color][/color][/color] [color=seagreen][color=Black][color=seagreen][color=Black][b][color=Red]}[/color][/b][/color][/color][/color][/color] If you read back your code, notice that you called the MapKey() function within the EventHandle() function. This mean each time you pressed or released a button, you write the mapping table with the same rule EACH TIME... this is perfectly useless and take ressources (comput cycles, function call, etc..). This can event lead to memory leak, since you used the "CHAIN()" function, which create dynamically allocated function, but I will not enter in details here. In one word: THIS IS BAD, Do not do that ! do not call any "MapKey" or "MapAxis" function within the EventHandle(), always do it within the main() function. Hope this will help.

For people living in Europe, I have found a replacement switch at Conrad (product ref: APEM 5639MA) : https://www.conrad.com/p/apem-5639ma-56390147-toggle-switch-250-v-ac-3-a-1-x-onoffon-latch0latch-1-pcs-700101 The small indentation/crenel is a bit narrower than the stock one so you must force a bit to insert it in the hole but the diameter is ok.

Ok, my mistake...

I think he mean, by setting the last waypoint to "landing" in the Mission Editor... This is indeed an old request, which I join, with some others old requests. Fact is that the ILS and TACAN are not (and worse: cannot be) preconfigured for mission start. An automatic ILS and TACAN preset according the "landing" waypoint configured in the Mission Editor would be a nice feature.

You can only select Magic using the HOTAS, and you no longer can using the PCA Button. However, to select the 530D, you have to select it using the PCA button. It seem strange, but this is how the real one behave, according people who know.

Well, anyway, this was indeed my mistake. I published a corrected version of the Mod with HUD and VTB heading tape correctly aligned according true north.

New version 1.1 of the mod released with bug correction. The previous version had missaligned HUD and VTB heading tape according the true north. This is now corrected. You will find the Mod donwload page link in the initial topic post.

By past, a similar situation occured with more obvious FM problem, right here in this forum, and some people with "no knowlege" but with logical and common sens, was saying something was wrong. And others, stayed in their view that "the FM is okay"... Until publicly Razbam admit that, yes, indeed, there were a problem. I am not saying we are in the exact same situation, I only say that, the "Duning Kruger" argument is almost the same as "I fly a F-106 30 years ago so I know how a delta-wing Mirage 2000 fly". Sometimes, common sens, usual logic, observation and college math can be pretty good tools.

Good feedback means the current FM is surely quite good enough, but it does not mean it cannot be improved or don't need adjustment... I guess that comparing real in-flight aircraft behavior to a simulation is not so easy for a pilot. Simply imagine you have to compare the simulation of the car you actually drive every day... Except if the simulation make very notable mistakes within your usage/test spectrum, you will probably say "yes, this is good enough".

My two cents on the current FM subject: I find hard to land with the Mirage 2000 comparing to other tested aircraft... And, I admit the main problem is AOA vs Thrust balancing, which is very hard to obtain, need a constant adjustment. Anyway I don't know, but my personnal intuition is that real pilots never have the hard time we have in DCS for landing with M2k...

DCS Mission editor use wind vectors (from->to) indication, because its purpose is rather "topographical" and its perspective is global. Also, standard meteo wind indication also use vector (from->to) type indicator with a special fashion to indicate the direction and speed (vector length). The METAR / TAF protocol/report use a wind "heading" (coming from) indication, because the purpose is related to navigation and its perspective is mainly intented to be relative and "subjective" (to the pilot, or to a specific point on the map [eg. an airport]). In two words: - In a topographical context, on a map, if you want to show the wind, then, you simply draw an arrow (vector) because this is the best way to indicate its direction in a global view. - In a navigational context, you tell the pilot from where the wind is comming from, because this is the best way for the pilot to know were the wind will "hit" him and what is its angle from its current heading. Both views are totally okay in their respective context according their application.

Well seen... This was indeed a wind problem. Strange thing: for the airfields I tested (with only one-way ILS) the ILS is disabled if the wind speed at 10m is greater than 0 m/s and lesser than 3 m/s, whatever its direction. I dont't know if it is normal. One sure thing, this is not related to Mirage 2000 module. Thanks for advice...

APP Mode, ILS frequency selected, tested on several runway, nothing to do, the TACAN work, but not the ILS. I used the ILS before, it worked, but now I am facing a systematic fail... The strange thing is that the ILS work in the Training Mission. I wonder if I missed something but I don't see what.

I am not able to get the ILS to work anymore, except in the ILS training mission... does the process changed or is it a bug ?

Hi, I come back with old features request, which become even more desirable as the module implements more details. The main observation / problem is that click on cockpit elements is made mandatory for some elementary procedures. A good example is decoy programs: Its default state is disabled and its program selection knob on "None", which require first to enable the decoy dispenser, then to select a program, each time, for each mission. Another example is the ILS and TACAN, which need to be manually configured. For this kind of thing, very appreciated features would be both: 1) The ability to preconfigure theses elements in the Mission Editor, like Rocket Burst Count, Laser GBU, etc. For the ILS and TACAN we can even imagine (if it is possible) to automatically preconfigure them according the "Landing" waypoint airbase. 2) Keyboard adapted commands. I mean, bindable commands which can be easily used to bind some key or joystick button to quickly toggle and cycle states or modes. For example, this kind of "cycle" or "toggle" command would be also very appreciated for some radar parameters (cycle radar power mods, cycle bars count, increase or decrease azimuth, cycle PRF, etc.) Thanks for reading.

Another good question about dynamic weather is : Is that possible to have a real cloud cover without generating hurricane-like winds. Because in the current model, it seem the only way to have cool clouds is to create a monster cyclonic depression... In its current state, the dynamic weather is almost useless and unusable.

I don't know, try, and tell us...