Open Mod Manager

[sedenion]

8 hours ago, Tracer1 said:

Now we are using this new version and I am getting the same issue, partial file error then have to restart from the beginning.  Is there anyway that I can select something to restart from the point the download failed?  Rather than at the beginning?  And is there a way to manually update?  I tried but was unable to see a method.

Unfortunately, Open Mod Manager doesn't implement such feature at this time. However you can easily manualy "update" package by downloading file using web browser:

When you select a package in the list, you'll find a Package Details tab in the bottom frame, scroll down a bit and you'll find a download section with the URL to download file. Simply click on the link to download via your default web browser.

You should put the downloaded file in the "Library" folder of the corresponding "Target Location". You are free to keep or remove the old package version from your Library folder.

Edited December 6, 2022 by sedenion

[Tracer1]

Hey Sedenion, thanks so much for the fast reply and help.  I just finished a download and installed it manually as you suggested. It failed about 8 times on me during the download but I was able to start it again and it started where it left off.  What a stress reducer for someone like me on wireless.  I hope this helps someone else in the same situation. 

Thank you again

Tracer

[Elphaba]

On 7/9/2020 at 11:59 AM, sedenion said:

What is Open Mod Manager ?

Open Mod Manager is an open source and generic Mod manager.

Mod term come from Modification and refers to one or several unofficial files which are added to, or replace original editor's files of a software (usually a game) to change its behaviour, add features, components or items.

While these Mods's files can be manually installed and origina files backed by the user, Open Mod Manager provide a safe, automated and advanced environement to store, install, back and restore original files, and create Mods as encapsuled packages.

Modern package management

Cumulative installations, backup then restoration of original files are key feature, Open Mod Manager embed safe and smart automatic backup mechanism to garantish user can always and at any time restore editor's original files. Finally, as any modern package manager, Open Mod Manager support versioning and dependencies mechanisms.

Network oriented

Since most of mods are provided by users or communities, and downloaded by other, Open Mod Manager provides an open online repository mechanism allowing any community or individual to provides its encapsuled packages within public online repositories. Users can configure repositories to check for updates or new availables packages from their favorite communities.

Generic and versatile

Open Mod Manager is not focused to work with a specific game or software, it is in contrary designed to be generic, very flexible, and to adapt to the most configurations as possible and even for what was not though in the start. The configuration architecture is modular, stored as human readable XML files. Editing merging or deleting configuration modules can be as simple as - litteraly - moving subfolders from one location to another.

 

GitHub Repository

https://github.com/sedenion/OpenModMan

 

Key Features

Open Mod Mananager currently implements the following key features:

• Flexible and modular XML and folder configuration logic.
• Multiple installation destinations per configuration context.
• Custom folders for packages (Mods) library and backup per installation destination.
• Support for both folders (legacy) Mods and advanced zipped Packages.
• Smart installation and backup mechanism allowing overlapped installed files.
• Packages installation dependencies mechanism (advanced packages).
• Backup data compressed as zip archives to save space (optional).
• Batch mechanism for automatic Package installation sequences.
• Network repositories for remote packages distribution and download.
• Automatic package dependencies download and fix system.

 

Screenshot

 

Download:

Open Mod Manager - Latest Release

 

Version history:

1.0 (2022-05-16)

• Includes all cumulatives changes and fixes of 0.9.9.x hotfixes, including:
• Fix and optimize markdown rendering
• Fix loading JPEG files may cause application to crash
• Fix and optimized image processing
• Fix deleting package may crash application
• Fix Repository Package parse failing due to 'xxhsum' tag not properly handled
• New support of paths with non-ANSI characters for ZIP file I/O
• Fix download low performances on large files over high-speed network
• Added bypass of access denied for network folders which access cannot be properly evaluated
• Fixed newly created Software Context not properly selected after Wizard dialog closed
• Fix potential memory leaks when closing software context
• Update embedded libcurl library to version 7.83.1
• Update embedded miniz library to version 2.2.0

0.9.9 (2022-02-19)

• Fix command shortcuts still working when main dialog is not active.
• Fix scrolling for Overlap and Dependencies in Package Properties Dialog.
• Fix missing dialogs for package download errors.
• Fix Package Editor bad encoding of loaded/saved description text.
• Fix Package Editor not detected file extension when open an existing package.
• Fix Network Repository description never saved locally.
• Update embedded XXhash algorithm to the 0.8.1 version.
• Update embedded Pugixml library to the 1.12.1 version.
• New Uninstall tree - uninstall with dependencies - feature.
• New MD5 (md5sum) alogirthm support for repository files checksum.
• New Category field for Packages.
• New custom path or URL mechanism for repository files download.
• New improved message boxes and icons.
• New Installation Batch "Install-Only" execution mode.
• New ability to associate description and thumbnail for dev/folder packages.
• New improved UI with resizable frames.
• New Markdown parsing support for package description.

0.9.8 (2022-01-04)

• Add support and automatic follow of HTTP redirect responses.
• Fix Network ListView columns click wrongly pops up contextual menu.
• Fix Network ListView not properly redrawn after item sorting.
• Fix Network Abort button not properly enabled at download start.
• Fix Package Editor not properly clear properties of modified existing package.
• New menu and shortcut to load seleted package in Package Editor.
• Fix not working delete repository button of Network tab.
• Fix overly long warning messages with huge packages list.

Older version history:

  Reveal hidden contents

0.9.7 (2021-07-18)

• Developer mode back as enabled by default.
• Fix undo install not working with archive files backup.
• Package created folders no longer generate overlapping.

0.9.6 (2021-07-07)

• Overall optimization and various debug.
• Repaired broken Context Wizard dialog.
• Fix Load Contexts At Startup option dialog not saving properly.
• New Tools menu for editors.
• New improved Package editor dialog (moved in Tools menu).
• New support for .omp extension file as Open Mod Manager Package.
• Fix Batch properties crash if package no longer available.
• Batch properties now ask user to clean Batch in case of invalid package reference.
• Automatic fix Batch inconsistency in case of Context's Location changes.
• Fix Batch execution thread not properly terminated.
• Consolidated package algorithms for robust dependencies and overlaps management.
• Setup now configure the system-wide application files and icons association.
• Now only one running instance allowed to prevent conflicting usages.
• New ability to run application and open Context files (.omc) by double-click on it.
• Moved dev mode and warnings parameters from Manager to Location.
• New Network repositories feature.
• New Repository editor to create server side repository definition files.
• New Location's Network tab to setup client side repositories.
• New Main Network tab to query online repositories and download remote packages.
• Automatic dependencies download and fix system.

0.9.5 (2021-05-22)

• Fix Library list-view scroll position reset to top on refresh.
• New buttons and dialogs for Batches edition
• New Discard backups data feature for emergency situations
• Edit menu modified for quicker access properties

0.9.4 (2020-11-26)

• Modify Package creation function to add picture file as provided.
• Fix Package creation dialog crash if no Context loaded.
• Fix various typo for "Uninstall".
• Fix Load Contexts At Startup option dialog not saving properly.

0.9.3 (2020-07-21)

• Update pugixml API to version 1.10
• Fixed new Context Wizzard custom library and bakcup folder incorrectly created.
• Fixed multiple bugs in various dialogs.

0.9.2 (2020-07-15)

• Rewritten Package building algorithm.
• Fixed Package "Save As" button never enabling.
• Replace GPL text by credits in the "About" dialog.
• Rewritten file/directory Access-Control check mechanisms.
• Improved Unicode and non-ASCII characters support.
• Fixed incorrect packages list refresh after move to trash.

0.9.1 (2020-07-11)

• Fixed random string bug and crash caused by buffer overflow.
• Fixed Context creation wizard not properly reseted after cancel by user.
• Fixed missing application informations and icons within Windows Application list.
• Algorithm to check file and folder access permissions slightly modified

0.9.0 (2020-07-08)

• First public BETA release

 

 

Getting Started:

Tutorial video by Retrolux

( this video will show you two bugs that are now fixed... )

 

Basic Concepts

Open Mod Manager use a modular configuration system with freely movable and editable configurations files and environment. The main configuration entity is the Software Context.

The Softwate Context

The Software Context is the Manager related primary object. Since the Manager is due to apply and manage Mods (modifications) for a third-party softwares (or games), the primary objects it handle are the workspaces related to these third-party softwares, which here, are called Software Context or simply Context. So to say, like an image editor deals with images, Open Mod Manager deals with Software Context.

A simple way to understand Software Context is to view it as the root of a workspace related to a third-party software. This workspace is both abstract and concrete by the way a Software Context is located in its own standalone folder which will contains sub-elements related to this Context. As Software Context itself is more a container, most relevant things are its components, the main one is the Target Location.

The Target Location

The Target Location is the main sub-element of a Software Context and in some way, a key part of the Manager. Since the Manager is due to apply and manage Mods (modifications) for a third-party softwares (or games), the relation between the third-party software and Mods (modifications) to be installed is at center of its procedures. The Target Location is the entity that incarnate this relation, it is the route between the Manager and the third-party software.

A good way to understand Target Location is to view it as a port of the Manager that both serve as warehouse and make a route to the third-party software. The Target Location not only describes a route to the third-party software, it also hold - in tis default configuration - in its own folder the subfolders dedicated to store Packages (Mods) and backup data.

The Target Location embed many parameters such as Network repositories or how to store backup data, but the most important, it defines three key parameters to interact wit the third-party software:

The Target Destination folder

This is the folder where the Packages's (Mods) files are copied (installed) to modify the targeted third-party software. This is usually the third-party software root (or installation) folder.

The Library folder

This is the folder where the Manager seeks for available Packages to be installed into the Target Destination folder.

The Packages are (should be) created by developers in accordance to the third-party file tree and the Target Destination folder to be properly installed, this is why a Library folder is usually very specific to one particular Target Location and should never be shared between several ones.

The Backup folder

This is the folder where the Manager will store backup of third-party software's overwritten files and the related restoration informations so to be able to properly uninstall Packages and restore the third-party software files to their original state.

The Backup folder is a sensitive part, if this folder is deleted, or its content alterated, the Manager will no longer be able to restore the original third-party software files.

 

Creating a new Software Context and its Target Location

Open Mod Manager provides a Software Context creation Wizard which will guide you through the creation of a new Software Context and its first Target Location. This chapter will details each steps and parameters related to this procedure.

To launch the Software Context Creation Wizard, go to the File menu, select New then Software Context...

The Wizard will guide you in two steps to first create the Software Context, then the first Target Location of this Software Context. Notice that all parameters can be modified later.

 

Documentation

More detailled documentation can be found in the GitHub wiki of the project here. This documentation is not finished and currently "work in progress" state:

https://github.com/sedenion/OpenModMan/wiki

 

There is no doubting your skill at programming but honestly your UX/UI is utterly unintuitive. I understand you are going for complicated processes but that's where you need someone with UI/UX skills to come in and completely rewrite your entire interface and flow. This is so overly complicated and intricately complex that it's clear this is 'coder UI' and not a UI for the masses. 

[sedenion]

17 hours ago, Elphaba said:

There is no doubting your skill at programming but honestly your UX/UI is utterly unintuitive. I understand you are going for complicated processes but that's where you need someone with UI/UX skills to come in and completely rewrite your entire interface and flow. This is so overly complicated and intricately complex that it's clear this is 'coder UI' and not a UI for the masses. 

I understand and I am sorry for that. I think the problem is not the UI itself, but the general architecture (Software Context, Target Location,  etc.) which is overly complex for most usages. Long story short, while developping OvGME I took users comments and suggestion and everybody have their own usage with very various configurations, so I wanted to create something very modular and flexible so the software can fit very various usages. The counterpart is that the software now is more or less like a lego box you have to built yourself.

[Elphaba]

3 hours ago, sedenion said:

I understand and I am sorry for that. I think the problem is not the UI itself, but the general architecture (Software Context, Target Location,  etc.) which is overly complex for most usages. Long story short, while developping OvGME I took users comments and suggestion and everybody have their own usage with very various configurations, so I wanted to create something very modular and flexible so the software can fit very various usages. The counterpart is that the software now is more or less like a lego box you have to built yourself.

I appreciate the effort you've gone into and how you've made a one size fits all for almost any situation, but with respect, using that as an argument for unclear terminiology, a (no offence intended) overly complicated and poor UI/UX interface and verbiage that will confuse most casual users, isn't an excuse. Apple routinely makes very complicated software seem trivial and natural, by the clever use of UI/UX. 

As someone with a huge interest in UI/UX I'm just saying that if you had a non-coder work with you, you could have not lost any power or flexibility but made it really simple to use and clear. Most users won't read the instructions with their precription meds, let alone a 40min video tutorial that still leaves questions. 

If you have to go as far as to make that, your UX is clearly insufficient. 

I have worked out how to use it, and it's overcome the massive problem OVGME had of claiming errors when zipping up large zip files and it taking too long that it thinks it's timed out, but whilst I have it working as I need it - I know it's going to be almost impossible to support for my squad mates who have issues with winzip!?!

I hate that such a clever, powerful piece of software that's really crafted for a genuine use case being so badly let down because of it's UI/UX - something most programmers don't understand or even care about. But we all don't think like the coders do... 

[sedenion]

5 hours ago, Elphaba said:

I appreciate the effort you've gone into and how you've made a one size fits all for almost any situation, but with respect, using that as an argument for unclear terminiology, a (no offence intended) overly complicated and poor UI/UX interface and verbiage that will confuse most casual users, isn't an excuse. Apple routinely makes very complicated software seem trivial and natural, by the clever use of UI/UX. 

I don't use this as argument, I simply explain the why. I agree with you that it is confusing at first glance and I had hard time to name things that are very abstractive.  I well know Apple strategy,  they make software that do few things and don't let choice to user, in order to be simple for common users. OvGME was like that in some way (and many users told me: "I want to be able to do that, and that, and also that..."), Open Mod Manager opens potentialities, give more freedom and become confusing (and now, users tells me "why so complicated ?"). But I admit that the current design is not optimal, I know this is not optimal from the begining, since I myself had hard time to names things and organize menus and parameters dialogs...

5 hours ago, Elphaba said:

As someone with a huge interest in UI/UX I'm just saying that if you had a non-coder work with you, you could have not lost any power or flexibility but made it really simple to use and clear. Most users won't read the instructions with their precription meds, let alone a 40min video tutorial that still leaves questions.

I completely agree, I still open to suggestion, especially to properly name things... but it is now too late to completely re-design the software. But I can change names and modify menues.

5 hours ago, Elphaba said:

I hate that such a clever, powerful piece of software that's really crafted for a genuine use case being so badly let down because of it's UI/UX - something most programmers don't understand or even care about. But we all don't think like the coders do... 

I care of, because I know the problem. I know the Linux world, where many software lake of proper UI/UX. As I said, for Open Mod Man, I had hard time to combine "freedom" and "easy to understand/learn"...

Edited March 1, 2023 by sedenion

[Captain Orso]

Hi Sedenion, I love this software. If it didn't exist, I would not lack for wanting it. Too bad there's no link to a Patreon in Github, or else...

But... to quote Benjen Stark, "nothing ever said before the but counts"; well I think it does... but Elphaba has a point.

What I am writing is only to give practical examples of how users think and why OMM is difficult for them and maybe some ideas.

For me, the very first conundrum was, what is a "Software Context". I've tried to think of a more practical term to use, but Software Context does do the job, but only once you understand it.

The Software Context is the set of information OMM uses to manage mods for a single game, program, or app, and is based firstly on the the installation location of the game, program, or app to be modded. EG: the standard installation location for DCS World OpenBeta is 'C:\Program Files\Eagle Dynamics\DCS World OpenBeta\'. When creating a Software Context, you select this installation location and give the Context a name, such as 'DCS-OpenBeta Mods'.

That is enough to set the user on the right footing.

Here's something which only has to do with the UI/UX. I know I've asked at least twice over the years, how I can remove an Installation Batch. Why? Because the simplest and most logical solution would be, on the main window, in the Installation Batch window on the right, to right-click on an batch name to select it and open a context menu with a few options, such as 'delete' or modify. This would be so easy to use and what every user in the world is accustomed to. I think this must possible, because in the Packages Library window, one can right click on a package to get a context menu with numerous options, from which to choose.

Instead I have to remember that the way is through other menus, somewhere in the back... I still have to look for it, even now after having found it a half an hour ago - Edit -> Software Context properties... -> Installation Batches tab -> Installation Batches. This could have easily been a context menu on the main page in the Installation Batch window. It is the exact same thing.

Worst case, if the tools used for programing the main page don't allow for two different sets of context menus, you could at least change the Modify button to open the Installation Batch manager window directly. You would see it right on the main page and never have to look for it. 

Thank you for all your time and effort. It has made enjoying DCS much more accessible.

[sedenion]

12 minutes ago, Captain Orso said:

The Software Context is the set of information OMM uses to manage mods for a single game, program, or app, and is based firstly on the the installation location of the game, program, or app to be modded. EG: the standard installation location for DCS World OpenBeta is 'C:\Program Files\Eagle Dynamics\DCS World OpenBeta\'. When creating a Software Context, you select this installation location and give the Context a name, such as 'DCS-OpenBeta Mods'.

Notice that, actually, the Software Context is only an abstract container located in a folder. One single "Software Context" can relate to multiple games or program using several Target Location, and his "home" being located anywhere you want, can be saved, copied, duplicated and combined with other Software Context simply by transfering configuration files and folders... I even have the case of an user that use Software Context using shared locations over local network (to mention the variety of usage)... I never though of this possibility while coding. While I perfectly know the "Software Context" is only a container, is very flexible, can be used for what you want, I have even difficult to explain what it is...

26 minutes ago, Captain Orso said:

Here's something which only has to do with the UI/UX. I know I've asked at least twice over the years, how I can remove an Installation Batch. Why? Because the simplest and most logical solution would be, on the main window, in the Installation Batch window on the right, to right-click on an batch name to select it and open a context menu with a few options, such as 'delete' or modify. This would be so easy to use and what every user in the world is accustomed to. I think this must possible, because in the Packages Library window, one can right click on a package to get a context menu with numerous options, from which to choose.

It is indeed possible to create a second contextual menu, and pretty simply I think... I simply never thought of that, and if nobody tell me "hey, this would be cool to have a contextual menu for the installation batches list"... Notice that most users have many more complexe and intensive usage than me, so, many things are simply "ok like that" for me.

42 minutes ago, Captain Orso said:

Worst case, if the tools used for programing the main page don't allow for two different sets of context menus, you could at least change the Modify button to open the Installation Batch manager window directly. You would see it right on the main page and never have to look for it.

I do not use "tool"... the whole UI is hand-coded in C/C++ using plain old C WinAPI library... Advandage : This is highly compatible, very efficient, optimized and lightweight. The drawback is that I am limited to plain old Windows "controls" and this is very low-level programming, so it is long and boring to create a simple parameters dialog, I have to dig the MSDN yo find the proper C structure definition and interaction messages for each kind of control (lists, buttons, progress bar, etc)...

[sedenion]

Done

This will be available in next release, but I will not create a release only for that so, if you have other suggestions like that, do not hesitate.

[Elphaba]

Please, please, please would you allow OMM to remember the last used folders when making packages? 

I am trying to make 40 mod packages, and each one, I have to go back to the beginning and drill down for where the source folder is, and then drill down for where I want it to be built/saved.

Please make it so it remembers the last used ones.

And also not automatically change the 'Destination Folder' as soon as you change the 'Create from folder content' folder.

Edited March 11, 2023 by Elphaba

[sedenion]

12 minutes ago, Elphaba said:

Please, please, please would you allow OMM to remember the last used folders when making packages? 

I am trying to make 40 mod packages, and each one, I have to go back to the beginning and drill down for where the source folder is, and then drill down for where I want it to be built/saved.

Please make it so it remembers the last used ones.

The source folder is alread saved, either you ask for folder to be expanded, or dialog to be scrolled down right to the current selected folder. First can be fixed easly, be second is a bug from the API itself I did'nt managed to workaround, you'll have to scroll down each time, sorry.

1 hour ago, Elphaba said:

And also not automatically change the 'Destination Folder' as soon as you change the 'Create from folder content' folder.

This is easy to fix, yes.

As workaround for now, you can save time and manipulation by saving packages in the same folder as where source folders are stored, typically, the mod Library folder. This way you'll don't have to change the destination folder each time.

[sedenion]

Anyway... I decided to publish a new hotfix release with the latest correction:

 

https://github.com/sedenion/OpenModMan/releases/tag/1.0.4

[Elphaba]

4 hours ago, sedenion said:

Anyway... I decided to publish a new hotfix release with the latest correction:

 

https://github.com/sedenion/OpenModMan/releases/tag/1.0.4

Thank you. I never expected such an expeditious response. It's very much appreciated. 

[sedenion]

New 1.0.6 1.07 release that changes the default behavior for package download and upgrade, the behavior should now better fit use of the most users.

Changes Packages download and upgrade default behavior:

• "Upgrade" Button is removed as package upgrading is now part of the default behavior.
• New "Download without supersede" command menu for former download default behavior.
• By default, the downloaded package version now replace the previously installed one, either the version is greater or not.
• New icons for the remote package list:
  • "Star" Icon indicate remote package does not exists at all in local Library, download will add the package in the library.
  • "Up Arrow" Icon indicate remote package is of greater version than the one in local Library, download will do an upgrade.
  • "Down Arrow" Icon indicate remote package is of older version than the one in local Library, download will do a downgrade.
• When supersede a currently installed package, it is automatically uninstalled and the downloaded version is installed instead.

 

https://github.com/sedenion/OpenModMan/releases/tag/1.0.7

Edited March 25, 2023 by sedenion

[sedenion]

Hotfix 1.0.7 ... sorry for people who already downloaded the 1.0.6. I made a mistake that may produce wrong package restoration during upgrade/downgrade of package that is overlapped. Better use the 1.0.7 to avoid any problem.

See link in previous post.

[greyeagle787]

Going to attempt to set this up. Want to confirm that the “Destination Folder” should be the DCS install/root location and the  “Path where to create Software Context home folder” can be anywhere but could be in  DCS Saved Games?

[imacken]

Can someone remind me how to get the mod version number to show up? I thought it was taken from a VERSION.TXT file, but obviously not.

Thanks.

EDIT: It's OK, I found the info on page 2.  

Edited March 27, 2023 by imacken

[sedenion]

5 hours ago, greyeagle787 said:

Going to attempt to set this up. Want to confirm that the “Destination Folder” should be the DCS install/root location and the  “Path where to create Software Context home folder” can be anywhere but could be in  DCS Saved Games?

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.

[greyeagle787]

1 hour ago, sedenion said:

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.

Thanks!

[Mysty]

Sedenion (or whomever has the answer), I tried using your mod.  It doesn't work for me.  When I try to install a mod, it only installs the content of the mod folder in the target location, not the folder itself.  So when I try to install a second mod, it tells me that there is a package overlap.  Is there a way for each mod to keep its folder?  This issue was probably discussed elsewhere, but I can't find it unfortunately.

Thanks in advance for any help you can provide,

Edited April 4, 2023 by Mysty

[sedenion]

14 minutes ago, Mysty said:

Sedenion (or whomever has the answer), I tried using your mod.  It doesn't work for me.  When I try to install a mod, it only installs the content of the mod folder in the target location, not the folder itself.  So when I try to install a second mod, it tells me that there is a package overlap.  Is there a way for each mod to keep its folder?  This issue was probably discussed elsewhere, but I can't find it unfortunately.

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...

Edited April 4, 2023 by sedenion

[blihp]

Hi, i have tried to install this a few times with no luck. I am struggling to workout what goes where in each of the paths. I have a simple install (i think), with install locations at the following:

• Location A) D:\Eagle Dynamics\DCS World OpenBeta (this is main installation dir)
• Location B) C:\Users\xxxx\Saved Games\DCS.openbeta (this is where saved games are saved)
• Location C) D:\DCS Info (this is where i save other ancillary stuff, copies of info etc. ie where i save things to find them)

 

When doing the "Software Context Creation Wizard", which location above (A/B/C or other) goes into:

• "Software Context home folder"
• "Destination Folder, where Mods are to be installed"
• "Library Folder"
• "Backup Folder"

 

Thanks. 

 

[Captain Orso]

15 hours ago, blihp said:

Hi, i have tried to install this a few times with no luck. I am struggling to workout what goes where in each of the paths. I have a simple install (i think), with install locations at the following:

• Location A) D:\Eagle Dynamics\DCS World OpenBeta (this is main installation dir)
• Location B) C:\Users\xxxx\Saved Games\DCS.openbeta (this is where saved games are saved)
• Location C) D:\DCS Info (this is where i save other ancillary stuff, copies of info etc. ie where i save things to find them)

 

When doing the "Software Context Creation Wizard", which location above (A/B/C or other) goes into:

• "Software Context home folder"
• "Destination Folder, where Mods are to be installed"
• "Library Folder"
• "Backup Folder"

 

Thanks. 

 

Lots of this you should decide and organize yourself.

Principally I suggest you keep things OMM manages apart from things you manage. You don't want to mix up things you manipulate with things OMM manipulates.

Create 'D:\DCS Info\Mods'. This will be the root of all your modding files.

Create 'D:\DCS Info\Mods\OMM'. This will be for all the things OMM manages.

Create 'D:\DCS Info\Mods\DCS Mods'. This is where you put your modding files. I organize like this:

'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods' -- root for mods pertaining to the Hornet.
     I always start with 'DCS' and then the module, or 'DCS UI' for mods pertaining to the User Interface, or 'DCSW' for mods pertaining to the DCS world in general, for example, a fix for       Persian Gulf airfield beacons.
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods' -- mods for things in the cockpit, including controller bindings, and instrument panel graphics.
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Wallpapier Mods' -- for modded wallpapiers (background of the main menu).
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS' -- mods for bindings eg if an aircraft only has a button press defined for controlling the undercarriage, but you want to use an On/Off switch, I would put that here [I won't go into details of that here, but if you need help, let me know].
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods' -- this is the first folder level of a specific mod.
     'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS' is equivalent to 'D:\Eagle Dynamics\DCS Worlds OpenBeta' with regards to how files are copied.
     'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods' is therefor equivalent to 'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods'. If you put a file into 'D:\DCS Info\Mods\DCS Mods\DC000S FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods', when it is implemented by OMM, the file will be copied to 'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods', which is how mods are implemented.

When you create your the context for DCS OpenBeta, you give it recognizable name, like 'DCS Mods'. This will create 'D:\DCS Info\Mods\OMM\DCS Mods'. This will be the home folder for OMM to use for DCS OpenBeta mods. This is where OMM puts all the config files for the DCS Mods context.
When you create the context for DCS World OpenBeta, this will be the home folder.
     Target folder:
     Target Destination will be 'D:\Eagle Dynamics\DCS Worlds OpenBeta'
     Library Folder is where the mod packages go. I keep these separate from OMM, bc I package my mods myself, mostly out of habit. For you, I suggest using:
          'D:\DCS Info\Mods\DCS Mods\Z DCS Mods OMM Library' -- This is where to put all mod packages. The prefix 'Z ' it to insure the folder is last in the folders list, which makes it easier to find. 
          EG:
               'DCS FA-18C Cockpit - HOTAS\Mods\aircraft\FA-18C\Input\FA-18C\joystick\default.lua' -- My keybinds mod for the Hornet
               This gets zipped with the folder tree to 'DCS FA-18C Cockpit - HOTAS.zip' and copied to 'D:\DCS Info\Mods\DCS Mods\Z DCS Mods OMM Library folder'.
     Target Backup folder is managed by OMM so it goes to 'D:\DCS Info\Mods\OMM\DCS Mods\Backup'. I don't recall if I had to create this folder first or if OMM did it, but either way, this is where the backups of files you mod are copied.
          EG: When I implement my Hornet binds, first         
               'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods\aircraft\FA-18C\Input\FA-18C\joystick\default.lua' is copied to 'D:\DCS Info\Mods\OMM\DCS Mods\Backup'.
               Then 'DCS FA-18C Cockpit - HOTAS.zip' is unpacked into 'D:\Eagle Dynamics\DCS Worlds OpenBeta', but starting only with the Mods\ folder.

That seems like a lot, but organizing sensibly and sticking to a good organization will make you life a lot easier.

!! Attention !! before every DCS update, always de-implement all your mods! I have a batch defined just for this purpose with zero mods implemented.

If anything isn't clear, or you have any questions at all, please feel free to ask.

[sedenion]

18 hours ago, blihp said:

Hi, i have tried to install this a few times with no luck. I am struggling to workout what goes where in each of the paths. I have a simple install (i think), with install locations at the following:

• Location A) D:\Eagle Dynamics\DCS World OpenBeta (this is main installation dir)
• Location B) C:\Users\xxxx\Saved Games\DCS.openbeta (this is where saved games are saved)
• Location C) D:\DCS Info (this is where i save other ancillary stuff, copies of info etc. ie where i save things to find them)

 

When doing the "Software Context Creation Wizard", which location above (A/B/C or other) goes into:

• "Software Context home folder"
• "Destination Folder, where Mods are to be installed"
• "Library Folder"
• "Backup Folder"

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.

Edited April 17, 2023 by sedenion

[blihp]

4 hours ago, Captain Orso said:

Lots of this you should decide and organize yourself.

Principally I suggest you keep things OMM manages apart from things you manage. You don't want to mix up things you manipulate with things OMM manipulates.

Create 'D:\DCS Info\Mods'. This will be the root of all your modding files.

Create 'D:\DCS Info\Mods\OMM'. This will be for all the things OMM manages.

Create 'D:\DCS Info\Mods\DCS Mods'. This is where you put your modding files. I organize like this:

'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods' -- root for mods pertaining to the Hornet.
     I always start with 'DCS' and then the module, or 'DCS UI' for mods pertaining to the User Interface, or 'DCSW' for mods pertaining to the DCS world in general, for example, a fix for       Persian Gulf airfield beacons.
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods' -- mods for things in the cockpit, including controller bindings, and instrument panel graphics.
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Wallpapier Mods' -- for modded wallpapiers (background of the main menu).
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS' -- mods for bindings eg if an aircraft only has a button press defined for controlling the undercarriage, but you want to use an On/Off switch, I would put that here [I won't go into details of that here, but if you need help, let me know].
'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods' -- this is the first folder level of a specific mod.
     'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS' is equivalent to 'D:\Eagle Dynamics\DCS Worlds OpenBeta' with regards to how files are copied.
     'D:\DCS Info\Mods\DCS Mods\DCS FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods' is therefor equivalent to 'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods'. If you put a file into 'D:\DCS Info\Mods\DCS Mods\DC000S FA-18C Mods\DCS FA-18C Cockpit Mods\DCS FA-18C Cockpit - HOTAS\Mods', when it is implemented by OMM, the file will be copied to 'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods', which is how mods are implemented.

When you create your the context for DCS OpenBeta, you give it recognizable name, like 'DCS Mods'. This will create 'D:\DCS Info\Mods\OMM\DCS Mods'. This will be the home folder for OMM to use for DCS OpenBeta mods. This is where OMM puts all the config files for the DCS Mods context.
When you create the context for DCS World OpenBeta, this will be the home folder.
     Target folder:
     Target Destination will be 'D:\Eagle Dynamics\DCS Worlds OpenBeta'
     Library Folder is where the mod packages go. I keep these separate from OMM, bc I package my mods myself, mostly out of habit. For you, I suggest using:
          'D:\DCS Info\Mods\DCS Mods\Z DCS Mods OMM Library' -- This is where to put all mod packages. The prefix 'Z ' it to insure the folder is last in the folders list, which makes it easier to find. 
          EG:
               'DCS FA-18C Cockpit - HOTAS\Mods\aircraft\FA-18C\Input\FA-18C\joystick\default.lua' -- My keybinds mod for the Hornet
               This gets zipped with the folder tree to 'DCS FA-18C Cockpit - HOTAS.zip' and copied to 'D:\DCS Info\Mods\DCS Mods\Z DCS Mods OMM Library folder'.
     Target Backup folder is managed by OMM so it goes to 'D:\DCS Info\Mods\OMM\DCS Mods\Backup'. I don't recall if I had to create this folder first or if OMM did it, but either way, this is where the backups of files you mod are copied.
          EG: When I implement my Hornet binds, first         
               'D:\Eagle Dynamics\DCS Worlds OpenBeta\Mods\aircraft\FA-18C\Input\FA-18C\joystick\default.lua' is copied to 'D:\DCS Info\Mods\OMM\DCS Mods\Backup'.
               Then 'DCS FA-18C Cockpit - HOTAS.zip' is unpacked into 'D:\Eagle Dynamics\DCS Worlds OpenBeta', but starting only with the Mods\ folder.

That seems like a lot, but organizing sensibly and sticking to a good organization will make you life a lot easier.

!! Attention !! before every DCS update, always de-implement all your mods! I have a batch defined just for this purpose with zero mods implemented.

If anything isn't clear, or you have any questions at all, please feel free to ask.

Thank you Captain Orso, a very comprehensive and helpful response!

3 hours ago, sedenion said:

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.

 

Thanks Sedenion, this background is very helpul