sedenion

This depend on the mods inside structure (how and where modded files are stored). OMM handles non-zipper (aka 'Directory' or 'Development') Mods without problem, it was designed for that in part. You simply have to put the folder within your Hub's Library folder (using file explorer), and it will appear in the list. What may fail is the Mod itself due to wrong installation. Because OMM is not magical, and will install/apply the Mod by putting (and comparing etc.) its content (content of the Mod's folder) into the target directory. So, you have to look inside the mod folder to verify how modded files are organized, so it can be properly installed in an automated way. To say it quickly, the inside files and directories structure of the Mod' folder, must replicate exactly the target file and directory structure, like a "mirror". The Mod's files are the "modified" reflect of the target folder. Finaly, once you have folder (or "development") Mod properly installable (that copies the files on the right place in the right order), you can even convert it into a zipped Mod using the Mod Pack editor, it is fairly simple since the operation is mainly automated.

As far as I know, this is not related to the script itself, but with TM driver configuration. The fact is that once a TARGET script run (either via Script Editor or GUI editor), the driver automatically "shutdown" the physical devices so they are not visible anymore in games... In your cas, it seem that the Throttle was not properly "shutdown" and still available along the virtual device. I can't remember where, but I believe remembering that there is an option, maybe within TARGET editor, to allow physical device to not be disabled. You may look for that, or, maybe, simply purge then reinstall the drivers.

They are not "lost", they are simply "not reopened yet", Hubs (what contain channel, folders, etc) still where you created them. OMM Hubs are not centralized and opaque like in OvGME "configurations", they are human-readable set of XML files within folder structure, so they can be moved from there to there, copied, archived, manually edited, etc. and by the way, you have to explictly open them (as file) in OMM. Anyway, you can configure OMM so it opens a set of Hubs you want each time it starts. This is in the Manager Properties, simply browse and add Hubs you want to be automatically opened, check the proper checkbox, and that's it. Yes, this is intentional, because this is a bad practice for a software of such type to automatically request privilege escalation at startup (and you should beware software that did such thing, if they are not explicitly administration tool). If you want to run it as administrator, you have to do it manually, like a "conscient user", either by contextual menu (run as administrator) or by checking the option in the shortcut parameters. (Anyway nowadays Windows gives you a tons of false-positive or irrelevant security alerts to fool user, make him paranoid and give him an illusory sensation of security... so, yes, such advice appear a bit derisory)

Yes, in "Channel properties", go to tab "Backup storage" and enable "Allow Mods install overlap (advanced backup process)". Notice this option is per-channel, if you want it to be enable for all channel, you must explicitely enable it for each.

No. Even at low-level, a zip file is made in such way that it is hard to efficiently (without rewriting the half-to-entire file) replace only one archived file entry of the zip file. The best case is the one the file to "replace" is at the very end of archive, and editing Zip file such way would require some special tricks OMM does not implement. Not possible in current implementation. OMM Mod Pack builder add archived mod files in a sub-directory (whithin the zip file) while adding some extra files at root. Your replacement FA-18C.zip file would be organized like an OMM Mod Pack, which I think it is not what the DCS module loader expect.

Menu Edit > Manager options...

You can configure list of Hub to be automatically loaded at startup via the Manager Parameters dialog.

Does the devs considered the post above (link bellow), and the possibility to use the supplied dual-combiner implementation (attached file) to include it in the module ? Is there something that prevent it ? (NB: the attached zip file includes all VTH script files, however only HUD_base.lua, HUD_definition.lua and HUD_glass.lua are required). I could offer it as a Mod, but this would be incompatible with online games (that checks for scripts integrity)...

Script updated to version 2.6 : - Added support for AVA Base with F-16 and F-18 Grip - New Option to keep Hardware LED setup (ignore custom settings) - New Advanced AP Module that allow short-Long press behavior - Added some script output EDIT: New hotfix version 2.7 : - Fix Advanded AP module enable status itself at mapping load - Refactored Advanced AP module to avoid duplicate code About the new Advanced AP Module behavior: The Advanced AP Module has been modified to allow two possible behaviors for AP Toggle so it is now possible to toggle AP status using long/short press. A short press on AP ENGAGE will enable AP Logical Status while long press disable it. Complex and Simple Mapping presets are configured to keep the behavior of the previous versions. If you want to set the AP Toggle behavior to Short/Long press mode, you need to set the AP_LATCHING macro to 0. https://www.digitalcombatsimulator.com/fr/files/3318341/ Merry Christmas

Hi there, New released version 1.3.3 https://github.com/iquercorb/OpenModMan/releases/tag/1.3.3 Changelog: Fixed various Dependencies Handling issues Fixed Window Placement save/restore minor issues

Hi there, New released version 1.3.2 https://github.com/iquercorb/OpenModMan/releases/tag/1.3.2 Changelog: Fixes issues and inconsistencies related to Library folder and Mod folders changes tracking. New flexible dependency resolving mechanism allowing version number wildcard. New flexible dependency resolving mechanism Open Mod Manager now have a more flexible dependency resolving mechanism that parses wildcard * in version number of declared dependencies entries. It is now possible to declare dependency in the form : Mod_name_v* or Mod_name_v1.* to allow any version of the declared Mod to be selected as compatible candidate. In case of multiple candidate (If multiples versions of the same Mod are available), the one with the greater version is selected. Beware, the mechanism only work for version numbers, this mean that if you declare something like Mod_name_* (without the v), the parser will simply ignore the * and consider you declared the dependency for a Mod named Mod_name_* (which is not a valid file name).

A video, with my terrible french english accent, are you crazy ? Anyway, since I am tired to rewrite the same thing once per year (this is the average frequency people ask for what you ask), I spent my afternoon to write a ... DOCUMENTATION PAGE ... yes ! at last ! https://github.com/iquercorb/OpenModMan/wiki/Create-and-manage-Network-Repository Good ready, tell me if something is not clear or if I made a horrible misspell (which I certainly did)

.omx or .xml this does not matter, the .omx file is an XML data file with custom extension, content is the same. Both extensions are supported.

The Repository Editor is used to create a Repository Reference file (xml file), which is a kind of web page file that you must upload into your web server so everybody can poll this address to know what Mod are available and let know OMM where to download files. Into the Repository Editor, the default download link is the default address or relative path where to download files (Mods) which does not have individual custom download link defined. Once you have created your XML file you have to upload it into your web server to make it accessible via the web to everybody (or you desired local network), like any web page or file to be downloaded. Once done, you can configure a Repository address into your channel using the Wizard. Here, depending you needs, you can set up named coordinate or raw URL. Assuming your XML file is downloadable at the raw address http://www.mywebserver.org/mods/default.xml the base address will be http://www.mywebserver.org/mods/ and the name will be default.

This mean the Zip extraction process failed to create the extracted file into the specified location (on the hard drive). Maybe the already existing file is somewhat read/write protected and cannot be overwritten... I see this is under a .git folder, which generally create file with non-standard access permissions.