sedenion

The current M2K module's starter sound is pretty the same... the problem with startup and shutdown sound in the module is more a volume, timing and mixage problem...

See this: https://forums.eagle.ru/showpost.php?p=3360062&postcount=22

I Try to get a "normal" interesting meteo using Dynamic Meteo, however, it seem the engine allow only some kind of extremes. For example, it seem impossible to have a dense cloud layer, without rain nor empetuous wind. The only available parameter is the pressure deviation, which almost give only two solution: - High pressure: No cloud, no wind... - Low pressure: Cloud, tempetuous wind, and rain... Major problem is that we can't have clouds without a dramatic wind and almost random precipitations... Is there a way, by editing the lua meteo file, to get some nuancies ?

You probably miss the "lock"... Padlock work only if what you want to lock is near the center of the screen and sufficiently close (something like 10nm/5km).

Wow, that's a lot of game indeed :D I never thought it can be used for so much games in the same time... (that's why the list box is so small). I keep your layout in mind, I will probably modify it like you suggest. This is implemented, in both way, here is how that work currently: 1) Backup dependency tree This dependency tree is created when mod is installed with backup data. If a mod overlap another one, the software create a dependency tree, to ensure overlapped mods will be restored in the right order to preserve the game genuine file integrity. The software indicate you that a mod is currently in a "backup dependency" tree by showing a small orange icon aside the green "V" (you can see it in the screenshots in previous posts). but to know exactly what mod was installed first, you need to dig into the mod properties (this show you details and status about mod and backups). The mechanism is automated and robust, so you can choose to be warned or not if any overlapping is occuring either at installation or during uninstall. 2) Installation dependency tree This dependency tree is defined by the mod-maker in the package. This time, the software will warn you that one or several mod(s) will be installed first in order to install the choosen one (all is automated). This dependency tree act like any other package manager (like DEB or RPM packages under Linux). Again, you can choose in options to be warned or not during installation. The software can act silently so you are not anoyed by warning messages. Here is the options tab for package installation/uninstall warnings: Here is the "Package detail" Window (thumbnail is bugged, small issue)

I started from the original specular map... essential data is already in it. Not so much... As I said, the essential data is already in the original specular map... I simply reused it. I mainly made a negative with some adjustement as base for "details", then added successively Red, Green and Blue layers for what appear to be roughness, specular and reflectivity. Not impossible, I did not passed much time on it.

The original PSD is owned by Razbam, I created the PSD on the fly from DDS images to make the mod... If you want the old mod to work with the updated module, simply rename the textures in the mod from <blahblah>.bmp.dds to <blahblah>.dds...

The new version already have a Modules (game configs) selector as List Box instead of combo box: https://forums.eagle.ru/showpost.php?p=3340249&postcount=614 The Contexts list (related to selected Module) still in a combo box to preserve GUI space. But it can be in a second List Box... If you have question about Module and Contexts and how that work (is intented to work), ask me, I currently suspended the development until I decide definitively the "how" this should work for users... You are users, you are the best to tell me what you want/need (if it is not too much magical). NOTICE: If people dare to, I can produce a pre-alpha build (without installer) to test in live... but currently, the version does not include features such as "presets", network, etc...

What we lose exactly except the need to select radio channel ?

This is a bug, and this is specific to M2000-C module: https://forums.eagle.ru/showthread.php?p=3357396#post3357396

So, this is a bug, because I experienced the same thing and I do enabled "Easy coms"... I don't have digged the problem, I solved it by a strange workaround using the communication menu instead of the shortcut command... however, this may be an general DCS bug (not digged as I said).

A remark here: It would be appreciable that such thing were alreadly correctly set at mission start, specially for missions with hot start. I know the "Clickable cockpit argument", but not everybody are happy to spend few minute each time at mission start by playing with POV hat (no track-ir) searching for switchs and buttons to pre-configure/enable: - Radio - Decoy program - D2M - IFF - Jamming - ILS This situation forces - if we don't want to spent time using POV hat and mouse click - either to maps commands on the HOTAS (what a waste of buttons), or invent some keyboard shortcut which must be remembered...

This is real, funnly real ! : https://youtu.be/p0wqBacGjQM?t=5m59s For the mirage 2000, the smoke appear to me correct (as for the Mig-29 and Su-27)... maybe there a little bit to much, but nothing outrageous.

Hi, While I am currently using the M2000 module for various tests and training using only "hot start" mission I noticed some things. So in Hot Start config: - Decoy program / activation: By default, the Decoy system is totaly disabled: power switch is to "A." (Arret) and the program knob is also to "A"... The result is that even the "PANIC release" don't work. I don't know if it is a position based on a real security procedure, but it seams logical to have the power switch to Semi-Auto and at least one default program selected. The program n°5 appear a good default program since it realease only one chaff and one flare. - VOR.ILS / TACAN : I already mentionned this before, long time ago... this would be very appreciable the VOR.ILS and and TACAN to be automatically configured according the "landing" airfield defined in the mission editor... Or at least, an option in the mission editor to set a default value for this, as this already exists for Rocket Burst, Laser code, etc...

Some people are more annoyed than helped by this Mini-HUD, using Track-IR make it less usefull since you control the head position yourself, so you know "where you are", but with pad-lock view you quickly lose all landmarks.

Don't know and, I don't care, because I already said this is not about realism... The option (to enable or disable it) exists in the option panel, I ask Razbam if it is planed to implement it.

Not really, as I precised, this is a kind of "cheat", so there is no debate about "realistic" or not.... the Mini-HUD is a kind of HMD simulation, but is NOT the HMD, and don't really act as an HMD (the HMD would stay at center of the screen, which is not the case of the Mini-HUD for example)... Also, the Mini-HUD display no weapon / target data, only aircraft basic data (pitch ladder/FPM, speed, altitude) and cannot be used to "lock" a target...

Hello Razbam, Is there a plan to implement a Mini-HUD in the Mirage 2000 module ? The option exists in the main option panel and it consists on a minimal HUD with essential data about aircraft situation (pitch ladder, speed, heading alt, etc), which appear and stay visible on the screen while the pilot's head is away from the real HUD. This mini-hud is also not centered, to implictely indicate in which direction (from the head rotation + POV) the real HUD (cockpit panel) is, allowing to determins the position of the virtual head from the "front" reference. This feature is naturarly NOT REALISTIC AT ALL, this is a "cheat" which come with the "Pad-Lock" to help knwoing in which position is our "virtual head", and aircraft situation, and so, to not being completly lost in a rotating blue sky during dogfight.

I am sorry, but, this feature would be only DCS specifics... the Module/Context feature will be theorically be here to facilitate this for users.

Why using a text file for that, since the destination path could be chosen by the user, by switching, for example configuration, or, in the current in-dev logic, by switch "context" ? There is no real benefits...

Ok dear Software-Architect... tell me how... Not so much... but mod-makers would have to write a full configuration file, and you'll see that almost no one will spend time for that, they will do as usual: Writing a readme to tell you what to do... So you'll have to re-create the mod yourself to make it compatible with the software... The strenght of JSGME, and then OvGME is that mods are easy to creates... But did you see lot of natively OvGME complient zip-archive mods donwloadable for DCS ? NO... Why ? Because mod-makers don't want to spend time for that... so, imagine if a mod requier to create a full structured specific hierarchy and/or with hand writed script-config file ? You ask for something that NO ONE will use, except, one, two... three people... and here I speak only for DCS... outside DCS world, such feature would be a total overkill and break the commodity of the legacy JSGME system... make a pole, we will see. Do it yourself.

First, as stated before, if I make a specific DCS handling, I have to make a specifical handling for severl games, or the software should be called "DCS mod Manager", maybe you will understand why with this explanation: We assume the idea: suppose you have both folders, including the one retrieved automatically. then, how mod-maker did their Mods ? how to automatically dispatch "this file" here or there ? The answere is that in this case, the mod must be architectured in totaly different way than the current one, and maybe carring an extra config file which describes each source and destination, all according DCS specific environment variables... I am sorry Eagle Dynamics tend to scatter all files in several folder with config files to edit... but, yes, if you want something that fitt with your ideal, the software have to be specifically designed FOR DCS, and the mods have to be specifically designed FOR this software... OR... may be, tell me something like: Ok, from now, we totally break with the JSGME legacy logic, here is a new software, more powerful, but more complex, mods are full of scripts, we include environment variable logics, mod makers have to create their mods according precises rules, old mods will no longer work until you completely rebuild them. We can surely inspire from the concept of Linux Deb or RPM packages, but in this case, the mod-makers have to know that tmaking a mod will be an totaly other advanture, complexe, taking more time and attention, no longer automated, because nothing is magical...

Happy to know, but, what the point ? We don't need to dig manually into the registry to retrieve this kind of path, specific functions exists in the API for that... So, this is specific to DCS, and so, this need to be hard-coded in the program specifically for DCS... so, I don't understand what you suggest... Happy new year

Saved Game folder is used by many games but the registry keys to found parameters are different for each games, so what do you conclude ?

I already said I will never implement such automatic path retrieval. The application will not be called "DCS Mod Manager", it is intended to be generic and "universal". If I implement such special DCS feature, I would have to implement it for all other potential games...