sedenion

I don't understand very well... can you explain with more details what you call "mod source code", why you have to "navigate to it" in order to do what ?... I suspect what you ask for is already a main feature implemented since the beginning, known as "Mod-Directory" or "Mod-Folder"...

Hi, New release version 1.2.3 This version fixes some major (but not harmful) bugs of the Mod Download process, notably when starting multiple download. If you had encountered unexpected and bizarre "checksum error" messages, this version should fixes it.If you encountered unexpected and bizarre https://github.com/sedenion/OpenModMan/releases/tag/1.2.3 Release notes: If you come from Open Mod Manager version 1.1.x or below, please read the Migration notice https://github.com/sedenion/OpenModMan/wiki/1.2.x-Migration-notice Change logs: Fixed various Mod Download bugs due to thread concurrency problems Fixed potential bad error handling of download file creation Fixed URL escape method Fixed download rate limit cannot be greater than 32767 KB/s Added more errors reporting during download processes

Hi, New release version 1.2.2 https://github.com/sedenion/OpenModMan/releases/tag/1.2.2 If you come from Open Mod Manager version 1.1.x or below, please read the Migration notice https://github.com/sedenion/OpenModMan/wiki/1.2.x-Migration-notice Change logs: Added new Per-Channel Download Limits options (accessible via Channel Properties) Added query received data entry in Channel Properties's Repositories tabs Fixed 'Channel properties' menu not properly disabled when no Mod Hub is loaded Fixed Mod download may fail due to bad URL escape/Encoding Fixed Mod download error dialog box not showing failure reasons

Unless Microsoft throw out the old C Windows API - which I think is not planed - there is no reasons OvGME become "incompatible". OpenModMan the sam, they are based on the same good old tech, except that OpeModMan use some newer features from Windows Vista and Seven. However OvGME have some known limitations that Open Mod Manager don't have anymore, notably the network code of OvGME is very artisanal and have download bottleneck. OpenModMan is also more flexible. You can install and try OpenModMan along OvGME they are not conflicting unless you install mods on the same target from both app at the same time, in this case you may loose game original files.

Well, since a new major bug was found, I was forced to create a new build... So, this time to be clear on where we are, I created a new 1.2.1 versions, and here is the changes logs https://github.com/sedenion/OpenModMan/releases/tag/1.2.1 Changes logs 1.2.1 Fix created mod files are not properly deleted at restoration Fix window not properly activated after progress dialog closed Changes logs 1.2 Dec 20 Fix OvGME like Zipped mod not properly installed Fix Mod restoration fail with "PERMISSION DENIED" in some cases Fix window always on top Fix Presets not properly installed and disapearing after application restart Changes logs 1.2 Dec 19 Fix repository definitions files not properly opened in repository editor Increase (up to 200%) checksum computing performances especially on large files New button to compute/show Mod file checksum in Mod properties dialog Fix Network Library not properly refreshed on Local Library content changes Fix inappropriate LF to CRLF conversion when loading description text file Fix UI bugs in Mod-Package Editor and Repository Editor Repository Editor now properly alert if specified URL/path is invalid

Thanks ! Problem found and solved (see below) Actually files were going nowhere because indeed the Mod parser produced empty package-source with no files to copy/extract. The problem ocurre only with "old fashion" OvGME style packages, wrongly parsed. The problem is solved, I did not created a new "release" version, I simply created a new 1.2 release with the up-to-date sources and build. You can redownload and reinstall, all should work fine now. https://github.com/sedenion/OpenModMan/releases/tag/1.2 Sorry for the headaches on trying understand what was going wrong.

Ok. Can you please give me some link to download ones of the zipped mod that doesn't work on your side ? I will investigate this on my side.

Ok, first of all : Don't Panik Indeed I found bugs in Presets implementation at several level, this is now resolved and I will publish corrected version soon. But However : Here I cannot reproduce that behavior... Notice that If the software cannot create/write/copy file or directory for any reason, it immediately show an error dialog box, so, if you don't see any error dialog box, this probably mean the files were properly written/copied, but, maybe in the wrong place. So, try to make more testing to identify the bug or error, I suspect problem with target path (but I can't figure out what at this stage). Checks Mod installed file and verify date changes within the target directory, try to create a new Mod Hub with a Channel that points to a dummy target directory, check that files are created in target dir, etc... Also notice that Green tick actually mean that backup data exists for this mod, so, theorectically, files are installed, there is not actual verification that files in target directory are the "modded" ones. The only bug I found throw an "PERMISSION DENIED" error while restoring backup data, it is identified and already addressed internally.

Well as I mentioned earlier this was a pre-release, because I now have the habit : When I release a version I always lost some obvious bugs, and this time doesn't change this habit. So here is the FINAL1.2 release with some corrected bugs and few minor features. If you already installed and migrated to the 1.2 pre-release, you can simply install the software over the 1.2 pre-release, otherwise PLEASE READ CAREFULLY The Pre-Release notes (here) Here is the Changes logs for the Final 1.2: Fix main window Z-order default configuration (stay always on top) Fix repository definitions files not properly opened in repository editor Increase (up to 200%) checksum computing performances especially on large files New button to compute/show Mod file checksum in Mod properties dialog Fix Network Library not properly refreshed on Local Library content changes Fix inappropriate LF to CRLF conversion when loading description text file Fix UI bugs in Mod-Package Editor and Repository Editor Repository Editor now properly alert if specified URL/path is invalid https://github.com/sedenion/OpenModMan/releases/tag/1.2 Good game and merry christmass evryone !

This is an "unwanted" feature I noticed just after the pre-release (that seem related to fact I jumped from Windows Vista/NT6.0 to Seven/NT6.1 API). This is already addressed in the modified code and will be corrected for the true final release with some other UI bugs of the Package Editor... Thanks

No, unlike OvGME if you uinstall OMM only the application installed data (executable file, dlls and icons) are removed. The general configuration file within the User/AppData is conserved as well as all your Modding Hub directories, which are strictly independant from application (know that you can even freely move them, then simply open your Hub again at the new location, the application is designed for that) So, theoretically, you will lose nothing... The migration is the most "risky" part.

Damn, I forgot to pay Microsoft and other Security compagnies to sign my software with an expensive certificate and prevent SmartScreen to scares users so to justify their racket business... too bad. Thanks to you !

What you can do: Uninstall the 1.2 Reinstall the 1.1 then Uninstall it (to correctly remove ressources and registry keys) Reinstall the 1.2 Reboot system (to properly refresh files associations)

Oyé The new Open Mod Manager is finaly here (Please not this is pre-release because so many things changed that it may remain some unspotted small bugs). Please Read First ! This new version introduce substantial changes in various aspect both at system wide and application level, please considere the following elements : 2. Application migration This new version use new configuration structures and will automatically migrate any opened Modding Hub to the new structure. For this reason, any Mod Hub migrated to the new structure will become incompatible with previous versions. The migration process is robust but since nothing is infailible it is redommanded to uninstall all currently installed mod and making a backup of your Modding Hubs "home" directories before installing this new version. 1. System integration Some resources are removed while other are added and default files associations changed. to prevent inconsistant files associations, orphan registry keys and residual non-uninstallable files, take care to uninstall the previous version before installing this one. Release Notes This new version have some visible changes, but before all have huges changes under the hood. Vast portions of code are completely rewritten in the objective to make it more robust and optimize maintainability. Many small bug disapeared, but there are potentially some new ones. Changes log (summarized): Fixed bug with files size not properly computed. Fixed bug with files size not properly displayed in List Views. Mod-Channels are now visible and selectable in a List View instead of a Combo Box. New menu bar, with new organization. Contextual menu for all main window List View. New prettry icons everywhere to see life in color. New "Add to Library" feature accessible via button or menu to browse and select Mods to copy to the current Channel library. New "Import to Library" feature accessible via button or menu to browse and select Mod-Directories to be built as Mod-Packages directly to the current Channel library. Totally rewritten Mod-Package editor with new interface, a menu and toolbar, and now looks and act like an "Editor". Totally rewritten Repository editor with new interface, a menu and toolbar, and now looks and act like an "Editor". New "zip" archive library allowing multiple compression algorithm, including Deflate (usual Zip algorithm), LZMA, LZMA2 and Zstandard. Mods installation, restoration and download now implemented as queued operations. New per-Mod visual install and download progression in List View with changes in abort logic. Network Repositories can now support two address/coordinate system and allow to setup custom raw URL. "Installation Batches" become "Presets" (still roughly the same under the hood). Presets (formerly "Batches") files are now located in a ".Presets" subfolder within Hub "home" directory. New Wizard dialogs to create Hub, Channel and Repository with better helping texts. It is now possible to double-click on Hub, Channel, Repository and Mod-Package files to opens it in application. You can now support me by donate via PayPal (link in About window) A word about compression methods (algorithms) This new version use the zlib-ng library and allow to create Mod-Package and saving Backup data as Zip archives (with or without the .zip extension) but with unusual compression algorithms. Zip files with unusual compression methods are usually well supported by advanced archive readers (WinRar, 7-Zip, etc) but NOT by Windows File Explorer for example. So if you want to create really widely standard Mod-Package Zip file, prefer using "Deflate" compression method. The "Zstandard" compression method (which is not the standard Zip file method as its name let think) is the prefered and default one, it perform better than "Deflate" and provides good balance between speed and compression ratio. If you want the best compression ratio use LZMA or LZMA2 but be aware that these methods are way slower that others, both for compression and decompression. Download here (open "Assets" if needed): https://github.com/sedenion/OpenModMan/releases/tag/1.2

It is probably possible to change curve programmatically using TARGET, via button combination for example, but the required work not worth it. If you want per aircraft custom curve, configure them within DCS and let a neutral curve in your TARGET script, this is way more simple and convenient.

You can achieve that in OMM by creating multiples Mod Channels, all pointing to the same Target directory, however this a "dangerous" setup since Channels work independently and will not check Mod overlaps for each other. If you take care that no Mod from one channel may overwrite one from another, this is fine. The terminology changed and will change again a bit in later versions (i am currently in major code refactoring)... This is really less complicated than it seem, the main problem is that contrary to most application, OMM does not confine user to a specific usage but let him combine elements and use them as he wish, more like in "sandbox" paradigm, that is mainly why many new users are lost at their first look. Mod Hub (or Modding Hub) is conceptually one "Sandbox", like a "project folder" where you will manager all mods and data related to a specific context, typically, a game. Within a Mod Hub, you can configure as many Mod Channel as you want. A Channel is typically linked to a Target directory, where mods are installed, for example, the game installation path. Typically, for DCS you may create two Mod Channels, the first for DCS Installation folder, the other for the "Saved Games" folder. Each Mod Channel is a specific "stream" so has its own dedicated Mod Library and Backup data directories, but you may however, customize both so theys points to the same custom folders (I think you now understand that you have very few limitations). That is for the basic setup.

You want to create/manage a repository, or be "client" of existing repositories ? OvGME repositories are not compatibles with Open Mod Man... If what you want is to create/manage a repository, you have to look at the Repository Editor: Tools > Repository Editor. The mains steps are the following: Create a Repository XML file using Repository Editor Upload the file to your web server so it can be available via HTTP or HTTPS Provide URL/Name couple to your "clients", suppose XML file is available at http://example.com/default.xml, this give base address "http://example.com" and name "default" The "Default Download Path" is the default location where OMM will seek for files to download, it is relative to where the repository XML file will be available (from internet). In our example, if you left the default Download Path to "files/" the downloadable mods should be avaiable in http://example.com/files/ I plane to work on the Repository Editor to make it a bit more intuitive and give more instructions to user, I also admit the very domagable lack of documentation.

Open Mod Manager don't care in which drive or directory Mods are to be applyed, you only must tell him where to apply... If I well understand what you wonder for: Yes, Open Mod Manager implements backup mechanism that allow to freely install and uninstall Mods on the fly. The main difference with JSGME is that under the hood, since Open Mod Manager is intended to work with compressed archives, data are copied instead of moved...

There is now a mechanism that automatically "clean" install scripts according existing packages in the library. If you remove packages from your library, all your install script are updated accordingly to avoid useless entries. It is already opened the order you see in the parameter dialog, but I guess what you really want is to control the order they are listed in the main combo box (which is another mechanism) ?

To be honnest I don't even remembered this feature existed, I wanted to implement "Delete backup data" and found some "unused" (I beleived) code that I can reuse for that... I realised later the feature was hiden in a menu. If you want a quick way to uninstall all installed package, simply create a Installation Script with no installed package and call it "Uninstall All"... You still can use the classic Windows method, select all packages, right click > Uninstall or hit Backspace.

Hi, Still on GitHub, even if this 2AF mechanism piss me off. Here is a new release here which I hope, will resolve most of problems occurring with large files. Some parts of the code was corrected and consolidated to ensure full compatibility with file larger than 4GB, which was a bit hasardous in some cases before, and completely bugged for the 32bit version. Another good news is that XXHash checksum (and maybe Md5 too, but I don't have tested) now compute at decent speed (the read buffer size was way too small, causing bottlenec). And finally some will be happy to hear that aborted downloads can now be resumed from where it stopped. There are also some other bug fixed. Fix inconsistent and buggy file size handling for 32 bit version Fix very slow XXHash digest computing, now way faster Fix application crash when remove package Removed Modding Hub "Uinstall All" feature Adding Per-Package "Discard backup data" feature Adding partial or aborted download resume mechanism https://github.com/sedenion/OpenModMan/releases/tag/1.1.1

Hi, I finally released a new version integrating mapping for Viper TQS and Panel corrected and debugged (despite nobody for testing). The whole script set evolved and the DX assignation changed, but the good news is that mapping chart are updated. Without geting to far into details, the DX numbers assignation is now partially dynamic but on detected/mapped device basis, meaning that if you keep the same base device configuration, nothing will change and you can refere to the new mapping chart to help you. Changelog for this version: New mapping system with per device dynamic DX assignation Viper TQS and Viper Panel mapping implementation Updated mapping charts Link for download in the first post of this thread here

Ok, I finaly created a new mapping logic and implemented mapping for Viper TQS and Panel. Script set got a big evolution and is now architectured differently. However, since I don't possess the Viper TQS nor Panel, I need some "beta testers" here to check whether everything work fine and that mapping options are relevant considering physical switch behaviors. There is no graphical mapping chart, you'll have to check button assignation using Target device analyser. "Beta" version of the script avaible in attached file TM Combined Full DX v2.4.zip

I checked manual and I am able to create mapping for Viper TQS and Panel. The main problem now is that the Viper TQS+Panel have more buttons than Warthog Throttle and my current button assignation is tightened around Joystick+Warthog Throttle with a specific logic to keep some consistency and optimize the count of used buttons depending enabled "mapping features". This mean that to implement consistent mapping for Viper TQS+Panel I have to rethink the button assignation logic, create a new assignation, so, also new (modified) mapping chart images... So, I will probably try to work on that, but this will take some times.

The script can work with Viper devices, but mapping functions are not yet implemented, so you have to implement them yourself at this stage. In the principle, you have to create a new mapping file for each new device to map (notice that technically you are free to proced how you want, I give you here process to stay in my script pack organisation logic). Each mapping file implement a mapping function, which must be then called within the main() function you can find in each run_*.tmc file of my script (near the end of file you'll see how other mapping functions are called). In the TARGET Script Editor, Thustmaster declared two new devices, "ViperTQS" and "ViperBBox". ViperTQS seem to be the throttle grip while ViperBBox must be the additional panel. So lets take an example to create a new Mapping script for the ViperTQS device: Open the "Run_Custom.tmc" file in TARGET Script Editor (or any advanced editor) Go to the end of file and before the return 0; add MapViperTQS(); (do not forget the semicolon) Save and close the file. Open file explorer and go to the mapping folder of my script pack. Duplicate the file "MapLMFD.tmh" (copy - past) and rename the copy "MapViperTQS.tmh". Open this file in TARGET script Editor (or any advanced editor) Change the function name from MapLMFD(), to MapViperTQS() for example Change all references of &LMFD to &ViperTQS You now have to add mapping functions calls to assign DX# to Viper TQS buttons. The Viper TQS buttons names and axes are defined near the end of the defines.tmh file that come with TARGET Softwares. So here is an example of mapping function calls for the Viper TQS : MapKey( &Dev, QB_BTN1, DX22); MapKey( &Dev, QB_BTN2, DX23); MapKey( &Dev, QB_BTN3, DX24); MapKey( &Dev, QB_BTN4, DX25); Unfortunately, contrary to the Warthog, for the Viper TQS and Viper BBox, Thurstmaster did not any effort to name buttons with friendly identifiable names, we are left with basic sequential numbered identifiers, so you have to look at the manual that list buttons and their number. I will see to create a mapping function for the Vipen Panel, unfortunately I don't own it and reference documentation is very sparse...