sedenion

Hi, Since some people had complain about cockpit sound setup and Mirage 2000 sound setup has changed, I took the opportunity to remake this mod. From the current Mirage 2000 sound stage (DCS World 2.8.6), here are main changes : New compressor flow (whistle), turbine flow (rumble) and thrust (roar) engine soud, created from real Mirage 2000 samples New synthetized alarm tones with calibrated volumes (-6dB) Cockpit engine sounds is now properly located at back of the pilot Cockpit engine sounds mixing and effect modified to increase "power" sensation Cockpit noises, clicks and throttle gain are adjusted and dimmed Starting sounds gain adjusted to be louder Sounds position, audition sphere and cone are adjusted and a bit rationalized Download link in the initial post of this topic, here Hope you enjoy.

Hi, Since some people had complain about cockpit sound setup and Mirage 2000 sound setup has changed, I took the opportunity to remake this mod. From the current Mirage 2000 sound stage (DCS World 2.8.6), here are main changes : New compressor flow (whistle), turbine flow (rumble) and thrust (roar) engine soud, created from real Mirage 2000 samples New synthetized alarm tones with calibrated volumes (-6dB) Cockpit engine sounds is now properly located at back of the pilot Cockpit engine sounds mixing and effect modified to increase "power" sensation Cockpit noises, clicks and throttle gain are adjusted and dimmed Starting sounds gain adjusted to be louder Sounds position, audition sphere and cone are adjusted and a bit rationalized Download link in the initial post of this topic, here Hope you enjoy.

Ok, I am not competent enough to judge precisely the curves. There are differences, but the Mirage 2000 was not turned into a Rafale (STR of 27 °/s for the Rafale), it still a Mirage 2000... Maybe the Mirage 2000 is not what so many people had beleived (while many people think the F-16 is the best fighter of all the times). Maybe the STR of the Mirage 2000 in DCS is a bit overperforming, maybe the DCS F-16 is little underpeforming. The rest of what I said still valid. There is, afaik, no source that can tell which one from Mirage 2000 and the F-16 is the best in BFM context, and the two aircraft had met together numerous times. Find an F-16 pilot that can tell you the Mirage 2000 is easy to catch, I doubt you'll find any. In the other hand, Mirage 2000 pilots seem to not particularly fear the F-16 (no more than any other high maneuverability aircraft). Both are serious oppoment for each other. You are in a F-16 or F-18 in DCS, you meet a Mirage 2000 for dogfight, take the threat seriousely, your are facing a dangerous machine, not a flying "french baguette".

Yes, at last ! Long time I did not tried the Mirage F1, tryed again recently and noticed very appreciable improvements of FM. It now act as flyable aircraft. No surprise, it has hard time against agile opponents (such as F-5) and the telemetry gun sight is... well, maybe I did not understand how it work (I guess this is the same as the Mirage 2000, but without the "snake", which is even worst)... Anyway, Mirage F1 is not the dogfighter of the year, but is now at least quike hard to hit. I think improvements can be done by fine tuning the controls logics to do a better "translation" of real-stick reistance variations (ARTHUR, etc). Current setup with ratio set to 50-60 si good, but I think some more tweeks with non-linear curves can be better.

Sorry to dig this old topic (we will see if it is locked again)... What I hear (read) appear to be (no offense) frustated people discovering the F-16 (or F-18) is not the king of the airs they thought, and come here to request the Mirage 2000 to be "Nerfed". First thing, the truth is not necessarily 1 OR 2, but can also be something in-between. Secondely, we know, by experience, that the Mirage 2000 is,in the mind of many people, a kind of "super Mig-21" or "modernized Mirage III", and have hard to swallow pill when they discover this is NOT, absolutely NOT. 1. You use the words "contrary" and "heresy", however, be nuanced. DCS Mirage 2000 is currently close to the well know public performance chart, that it was said to be probably inaccurate and probably, intentionally pessimistic. Maybe the DCS F-16 need adjustements, maybe the DCS Mirage 2000 is not perfectly accurate, but there is nothing like as "contrary" or "heresy". 2. What "written" things are you talking about, this is pretty vague ? Despite what you seem to arg, the Mirage 2000 is known to be a very serrious oppoment to the F-16, and there is, afaik, no source that tell one is frankly superior than the other (especially in BFM context), because both aircrafts are very capables and agiles. If you take the raw numbers, the F-16 have better thrust to weight ratio, and maybe, if you trust some available charts, a better STR, ok, but this does not do all the thing. F-16 and Mirage 2000 have very different aerodynamic design, each have their advandtages and weakeneses, Mirage 2000 can take advantage of F-16 weakeneses and F-16 can take advantage of the Mirage 2000 weakeneses. For example, the Mirage 2000 is known to have a better ITR than the F-16, with the prejudice of bleeding more energy doing so. The F-16 vs Mirage 2000 scenario is tipically a case where pilot (and luck) make the difference, because both aircraft are very good. The Mirage 2000 is known to be, with the F-16, in top list of very manoeuvrable and dangerous dogfighters aircrafts of the 80-90's. Mirage 2000 is known to be a direct competitor to the F-16. This is mirrored (maybe not perfectly) in DCS... deal with it.

OMM should work with HTTPS, however there is no certificate validation, only encryption. Anyway I doubt encryption would be a real benefit for mod download. You have the choice, you even have many choices... but, first, you'd better use the Repository Editor than editing the XML directly, especially to manage package collection. The most general case is to use the "Default download Path" (<downpath> in the XML) to define the subdirectory where to find packages to download. This path is relative to what is called the repository "base URL" which is by definition where you put your XML repository file. In your example, it is "http://thisisatesturl.com/mods/". So let say you define a Default download Path to "files/" then the packages must be downloadable at the url "http://thisisatesturl.com/mods/files/" For particular cases, you can define per-package specific URL or Path and here you are very free to put what you want, OMM will deduce itself what you "mean" based on what the value looks like: An alternative subdirectory that will supersede the default subdirectory (eg. /custom/path) An alternative URL that will supersede the default base URL (eg. http://domain.tld/path) An alternative full URL to file that will replace any other default (eg. http://domain.tld/path/My_File.zip Sumary : Repository is qualified by a Base URL and a Name, the Name is the file name of the XML file withou the ".xml". (This mean you can have multiple repositories at the same Base URL). Suppose you have a "DCS.xml" file available at the address "http://mysquadron.org", Repository Base URL is "http://mysquadron.org" and the repository name is "DCS" For each repository, the Download Path define the default subdirectory (with Base URL as root) where listed files can be found for download. For example, if the Download Path is defined as "files/dcs/", packages files should be available at the URL "http://mysquadron.org/files/dcs/".

the Target path is where mod content (files and folder) will be applied. It is usually game installation root directory or game's sub-folder in user's saved game folder. This also depend on how the mod are made itself, the mod have to properly replicate game file and folder structure to be properly applied by the mod manager.

It is a bug due to wrong config file init procedure introduced with new "Show Hidden Files" option. You can workaround by enabling "Show Hidden Files" (it is in the same propertie dialog than "Developper Mode"), then closing properties dialog (so the propertie is written in config fie). Once done, you can open the properties dialog and disabling "Show Hidden Files" again. I corrected the bug and rebuilt the binaries and installers under the same version. You can redownload the installers and install again if you want to prevent this bug to appear again.

New version released 1.0.8 https://github.com/sedenion/OpenModMan/releases/tag/1.0.8 Fix library not properly refreshed when switching Target Location Fix lack of consistency of Package menu according selection Fix Package Editor inconsistent prompts for unsaved changes Change properties dialog buttons to Apply/Cancel/Close Add "Uninstall All" Command Add support for detecting and skipping hidden files Fix gif creation fail if color map size is not power of two Change Menus organisation Change UI terminology "Software Context" is now "Modding Hub" or "Hub" "Target Location" is now "Channel" "Installation Batch" is now "Script" "Network Repository" is now "Repository" "Destination folder" is now "Target Path" Please comment names and terminology changes, any critic or suggestion can help.

I am not able to reproduce this. Your mod has a visible version number which is not the case the one distributed by author, so it seem you edited it, recreated or else. What did you exactly ?

So, I am currently implementing "Uninstall all packages" command, but I have to implement it to stay consistent with current UI organization... 1) Does the "Uninstall all packages" must have "Target Location" scope (uninstall packages only for current selected Location), or have "Softwate context" scope (uninstall package for all locations of current selecte Context) ? 2) Since "Package >" sub-menu is dedicated to selected package, I can't place the "Uninstall all packages" command within. So I have to put this command directly in the "Edit" menu.. Depending the answere of the first question, at which place it is better to place this "Uninstall all packages" command within the Edit menu ? After "Software Context properties..." ? After "Add Target Location..." ? Elsewhere ? Do I should I add separators ?

I don't remember what option OvGME menu have, but I think OMM menu have more... However, there is no "Uninstall All" option, indeed...

Ho, you want a tool bar... too much work, sorry.

Yep, I know, but what if I told you you can apply several "batch" sequentially so they are cumulative ? So they are no more really "preset", they are more like "scripts" you execute. Knowing that, did you think "profile" or "preset" is a proper designation ? How would you name it ? Main menu and right-click menu are here for that. What you suggest would make an UI with buttons everywhere, so many buttons that other people would come here and tell me the UI has so many button that it is chaotic. Do you really need a "Uninstall All" menu entry ? Then, ask for "Uninstall All" menu entry...

You simply have to create an Installation batch with no mod to be installed... 1) Click the "+ New..." button bellow the Installation Batch list (right frame) 2) Name it "Uninstall all" for example. 3) Uncheck "Clone from current state" option 4) For each Target Location (or as you whish), put all mods in the "Not selected" (left) list. 5) Click OK Please tell me what terminology you would prefer or seem more appropriate to you. Explain what shock you with storage procedure.

Yes, but if the "default" setting led to something that cannot be used, this is a TRUE design error... My attempt here was to explain that using your way, user have to choose a location for Library folder, using my way, user have to choose location for "Game Profile"... In all cases, user must use two neurons to browse and select a folder, because the application will not did for him... It is not forced, as you saw yourself, current implementation allow to set separated library and backup folder. The purpose of create an "home" folder for each "Game Profile" where everything related to that game modding is put together is precisely to have everything together, well "packed" and organized in consistent structure instead of having mods here, backup data there, config file hidden elsewere, installation batches in another obscure location, etc... Notice that "Software Context" is not the name of this paradigm, I see the the way I wrote this may lead to confusion. This way to organize data exist since long time, and have no specific name (at least I don't know it, except maybe "project folder paradigm"). I know, but notice that I ma not responsible of how modders packs their mods... Now, OK, I heard your point and this tell me that in fact, from your user perspective, what you are seeking for, is a kind of "Mod Importation" tool that will pack "raw packed" mods located anywhere into a well-packaged OMM mods directly into the Library folder. Which is not especially the purpose of the current "Package Editor" which is more designed for mods creators that use OMM to developp and pack their mods. To be clear : You want a Tool/Wizard that import raw/folder mods and pack them into the Library. And yes, that is an idea and will think about that.

So as developer, you intentionally mislead user so they can complaint to you you did something inconsistent ? I am sorry, but i can't do that... If I made Game Profile to be saved in AppData by default, I have to force user to choose at least a separated Library folder... Don't you agree ? You got it... that's why the Game Profile (Software Context) is designed as a separated entity whose user choose name and location, and not hidden in some "AppData" folder... You know Blender, maybe you know Autodesk Maya, another 3D modeling software. So, in Maya you create "Projects", you give it a name, choose location and in each Project folder you have a Texture sub-folder, Scene sub-folder, Script sub-folder, and various files... and User have to fill the Project sub-folder with textures files, scenes files, scripts files, etc... so the whole Project can be moved, saved, etc, and everything still available an consistent. Maybe you sometimes used Development environment tool like Visual Studio or Code::Blocks, so in these software this is the same, you create "Projects", meaning, a folder with pre-determinated (and customizable) folder structures and configuration files, where you will store sources files, complied data, resources, etc... That is the OMM "Softwate Context" paradigm... Maybe you never encountered this paradigm, so OMM present it to you. https://help.autodesk.com/view/MAYAUL/2022/ENU/?guid=GUID-9CE78B5A-7E9F-45E6-AB6D-66795E5656F4 https://learn.microsoft.com/en-us/visualstudio/ide/solutions-and-projects-in-visual-studio?view=vs-2022 Those are only some examples, many application use this paradigm, from 3D modeling software to Video montage through Music Creation softwares... In fact, any software where multiple kind of files are involved and linked together for the same final purpose... and that is exactly what a "Software Context" (or "Game Profile") is. Ok, so, you want the application work in a way so that you don't have to click and browse... but if other users have different usage and habits ? So, make a poll, so that the next user come here to tell me he prefer the default path was he same as the source because it is "more logical and practical" to him, I can tell him : No sorry, users have democratically choose the way it is. The existing program profile is what is called a "database"... Who decide the games in the list ? who maintain this list up to date ? Who will have to add a new game to the list each time an user wanted his game to be included ? Sorry, but no, I don't want to be in charge of this... Ok, I will look at this, maybe wrong field fill detection...

Ok, so, I lets the user did a mistake by creating a profile in AppData (because he don't want to be bothered, so he click next, next, ok next), so he discover later that he don't understand how and where to put mods to be installed, so he come here and asks "Where the hell do I have to put mods ? Why the hell the library is created in an Hidden folder ?"... Please provide me a suitable UI process to prevent that. Nothing forbids you to save your created package in the proper Library folder, there is a button to browse location where to save the Package. So, what is exactly the problem ? explain me, I don't understand... You want the field pre-filled so you don't have to click the button to browse location ? Again, currently, nothing forbids you to do this... So, what do you want ? What is the problem ? If you want the saving destination path to be pre-filled with path to the proper Library folder, put your mod source folder into the proper Library folder, and will not have to "browse" to select another location. Ok, you are working on mods... so lets me propose that to you: Put your mod source folder into the Library folder, it wil appear in OMM as a folder, you'll be able to manage it like any other "zipped" package, you'll be able to install it, uninstall it, while working on files inside, you'll even can prepare description text and image (ask me for further informations)... And then once the mod is ready, you'll be able to right-click on it and select "Open in Package Editor" and, maybe, you will understand why what you ask for is somewhat meaningless. Ok, you manage the games data-base with unique identifiers to be sure everything is consistent from one mod creator to another ? Or you simply want another data field you can fill like you want, to informally indicate which game a package is made for ? For the first solution, personally I don't want to manage a games database. For the second option, an informal field can be easily replaced by a proper description text.

Ok, OMM is not supposed to work only for games, but ok for "Game Profile"... I will think about. Ok, in this case, the Library and Backup folders will, by default, be placed within folder tree in AppData, which is by default an hidden folder in Windows. So user that create a "Game Profile" without touching anything, and then wants to put its mods into the Library folder (which is deep somewhere in AppData) will never found it. How do you address this scenario ? I am sorry, but this is not relevant. Package itself do not hold any information about "what game" it is designed for, only the mod creator and who use the mod know that, and it is assumed that they know what they are doing. It seem you want to confine Package Editor so it save packages into the Library folder, but, this has no sens, many user use the package editor to create package from place to another place, and they do not want the package to be placed in the library folder... It seem you think that Package Editor is here to "import" mods into Library folder, I repeat : This is not the case, Package Editor is not here to "import" mods into Library, it is a TOOL for mod creator to make packages from their source with images and descriptions. Are you Mod creator ? If yes, I will explain you how OMM can help you develop and pack your mods so you can distribute to others. Being clear, the current "Package Editor" toot is somewhat a "Developer Tool", like "Repository Editor". Now, maybe you want ANOTHER tool (may be derived from the Package Editor), an "User Tool" that is designed to IMPORT mods into the current Library folder ? Is that what you expected by using the Package Editor ?

I am perfectly aware of this problem, even since the early development time. This subject was already discussed here. My answer will be simple : Please give me ideas for better names and terminology ! Tell me what you think that would be better. I ran out of idea... so, if you find current terminology unclear, help me found another. I would say, if you want Software Context home to be located in AppData, then create it here... What if Software Context Home path field (the first page of the wizard) were pre-filled with a path to AppData folder ? Do you think this would make things more intuitive for common users ? Because creating new behavior as "option" require quite massive UI restructuring and will make the application again more complex... OMM is already complex because each user have its own usage and "view of things", and tried to content everybody... So, stop the "optional" things. You want a "one way" application with a single tunnel that lead user to a single solution for a single usage, so : Tell me how you want this single tunnel, single solution for single usage... describe it exhaustively, take the place of the the software/UI designer and tell me what I should do from A to Z. Ok, so what is your suggestion here ? Should folders and paths be "hidden" to user ? Should I prevent to users the ability to choose were to put things ? Ok, lotus pose, breath... The Package Editor is a tool dedicated to mod creators, the default saving path is set beside the selected source, because this is more logical and practical in such usage. If you want the Package Editor to save the created package within the proper Library folder, put the source folder within the proper Library folder. You are not forced to use/create package version of a mod, OMM is able to work with folders like OvGME or JSGME. If you want to create "package" version of mods that are in form of folder, then put the folders intot the proper Library folder, as for OvGME/JSGME, the right-click the folder in OMM and selecte "Open In Package Editor", and Voila ! Now, if I pre-fill the saving path of the Package Editor to the current selected Target Location's Library folder, other users will come here and screaming "Bruh !! this is crasy, why the Package Editor set the default saving path to the current Library folder ? You should change that !"... So, go fight yourself with other users Ok, can you please be more precise, where did you go, what exactly you attempted to do, what exact error message did you get ?

Some explanation and video tutorial available on the first post of this topic.

Two or more. The installation and backup mechanism is designed to handle mods overlapping (conflict) and proper data restoration. However, installing overlapping mods may result in unpredictable behavior in the game side, but this is user responsibility.

The Software Context home folder is a folder to be created (the Wizard will create it) where Open Mod Manager will "install" configuration files and required sub-folders organization to manager and hold data (and mods) dedicated to the created Software Context. You can create this home folder everywhere you want. The Destination Folder is where mods will by applyed (installed), this is typically the game or application root installation folder, in your case, A (I will explain what to do with B later) The Library Folder, if you let default setting, is created within the Target Location sub-folder (depending the how you named it), within your Software Context home, this si where you must put your mods collection to be installed for this specific Target Location. The Backup Folder, if you let default setting, is created within the Target Location sub-folder (depending the how you named it), within your Software Context home, this si where backup data for installed mods is stored for this specific Target Location. If you have mods that must be installed in the DCS Saved Game folder in parallel of the root installation folder, you must add and configure a new Target Location within your Software Context, this will create a new sub-folder in the Software Context home folder, with another library and backup folder. A Software Context is a kind of "Project" folder for a game or software to be manager, but specific usage is not specified and can be used as user want, it is only a folder that contact specific configuration files and subfolder organisation. A Target Location exist only within a Software Context, and describes a specific configuration for mods installation, typically game root folder. There is a library folder and backup folder configured for each Target Location. A Software Context can hold as may Target Location as you want. I let you with this for now, let me know if you have some question.

At first glance, this is not an issue, but a wrong usage. Lack of precision here, please describe exactly what mod you speak about, where you store it, what destination folder you defined, etc...

Yes, "Destination Folder" is where mods will be applyed/installed, so, the game or software installation root folder for most case. The path where to create "home folder" can be anywhere and home folder can even be freely moved after creation.