Open Mod Manager

[VR Flight Guy in PJ Pants]

NOOB question: if two mods on the library report conflict, would it be fine to install and uninstall. For the time being, I notice no issue of running conflicted mods.

[sedenion]

5 hours ago, VR Flight Guy in PJ Pants said:

NOOB question: if two mods on the library report conflict, would it be fine to install and uninstall. For the time being, I notice no issue of running conflicted mods.

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.

Edited April 17, 2023 by sedenion

[zaelu]

Is there a tutorial or something with this tool. I tried it again 5 years later or something and is just too much for me sorry. I must be sooo old. I understand perfectly OVGME. I made mod packs even online repositories but this... Sorry. It's just... I don't even know what is suppose to do? I can only amuse of myself I guess.

[sedenion]

21 minutes ago, zaelu said:

Is there a tutorial or something with this tool. I tried it again 5 years later or something and is just too much for me sorry. I must be sooo old. I understand perfectly OVGME. I made mod packs even online repositories but this... Sorry. It's just... I don't even know what is suppose to do? I can only amuse of myself I guess.

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

[zaelu]

OK, I think I managed to understand it. If I can give you some feedback:

I am a non native English speaker probably like you (?) so a lot of expressions in PC world if are not "standard" or at least "familiar" for the context it becomes difficult to get a hold on the topic. I remembered the first time I used OvGME it was almost the same (see first screenshot) because the names used to describe the folders for example are just hard to understand fast as they are different to any other names used for other mod managers I've used (ModMan, GME or Nexus ModManager and its evolutions, etc). Maybe they are easy to understand for some but for me... they are "oops my brain just hit a bad sector". It was the sole reason my first try with OMM stopped at the installation few years ago.

So I think the program is OK but the names used should be improved. maybe do a survey or check if the adoption of the software is within the expectations to see if others find to have same difficulties. 

What I would say from the start is that:
--The "Software Context properties" structure not only deservers another name that would be more intuitive but should be simply incorporated (optionally at least) to main program folder in "Program files" or in "AppData" folder. Basically this step of creating that structure is redundant to be seen by the user and can be confusing. For example I ended building that structure once in the main DCS World folder and once in the Library Folder and then it was appearing like another mod and I was scratching my head of what was that? The destination where the mods will go??  All because I didn't understood what it was and what it wanted from me.
You can see in the first screenshot that I used very simple paths. Clear folders in root of the drive. Many people will just go for some complicated automatically generated paths that are just asking for trouble when needed to debug.
--Also once a mod is created (I did one for testing (second screenshot) it should be automatically (optionally not) added to the Library of mods for that game. Maybe ask for what "Software Context properties" that mod is to be build and add it there to remove one more hassle of searching where the mod went... oh... it was on Desktop where the files were...

Also maybe was a bug at some point I tried to edit a "Software Context properties" I made and the program simply refused to accept the backup folder because it was empty.

I hope you take this as constructive criticism.
 

 

Edited April 20, 2023 by zaelu

[sedenion]

12 hours ago, zaelu said:

I am a non native English speaker probably like you (?) so a lot of expressions in PC world if are not "standard" or at least "familiar" for the context it becomes difficult to get a hold on the topic. I remembered the first time I used OvGME it was almost the same (see first screenshot) because the names used to describe the folders for example are just hard to understand fast as they are different to any other names used for other mod managers I've used (ModMan, GME or Nexus ModManager and its evolutions, etc). Maybe they are easy to understand for some but for me... they are "oops my brain just hit a bad sector". It was the sole reason my first try with OMM stopped at the installation few years ago.

So I think the program is OK but the names used should be improved. maybe do a survey or check if the adoption of the software is within the expectations to see if others find to have same difficulties. 

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.

12 hours ago, zaelu said:

What I would say from the start is that:
--The "Software Context properties" structure not only deservers another name that would be more intuitive but should be simply incorporated (optionally at least) to main program folder in "Program files" or in "AppData" folder. Basically this step of creating that structure is redundant to be seen by the user and can be confusing. For example I ended building that structure once in the main DCS World folder and once in the Library Folder and then it was appearing like another mod and I was scratching my head of what was that? The destination where the mods will go??  All because I didn't understood what it was and what it wanted from me.
 

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.

12 hours ago, zaelu said:

You can see in the first screenshot that I used very simple paths. Clear folders in root of the drive. Many people will just go for some complicated automatically generated paths that are just asking for trouble when needed to debug.

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 ?

12 hours ago, zaelu said:

--Also once a mod is created (I did one for testing (second screenshot) it should be automatically (optionally not) added to the Library of mods for that game. Maybe ask for what "Software Context properties" that mod is to be build and add it there to remove one more hassle of searching where the mod went... oh... it was on Desktop where the files were..

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

12 hours ago, zaelu said:

Also maybe was a bug at some point I tried to edit a "Software Context properties" I made and the program simply refused to accept the backup folder because it was empty.

Ok, can you please be more precise, where did you go, what exactly you attempted to do, what exact error message did you get ?

Edited April 21, 2023 by sedenion

[zaelu]

I think "Software context" can be  synonym with "Game Profile" which might be intuitively clear what it is.

Also when you create this game profile its path should be automatically saved to a OMM folder in AppData like most programs do and only give as an option for user to activate personal choice for that destination. Like you have now for library and backups. Because User might be more inclined to alter the library and backup folders due to the sizes they can get but the "profile" should be a small size folder that nobody manually alter or care about. However when you create that game profile is another chore or another not so intuitive thing to do first time you use the program.
nullpicture 1
And when creating a package the little window should have a field where the game profile is selected  so you select also for what game you are doing the mod and automatically select the current selected game profile as it's most usually and  intuitively for that game you are going to do a mod in that moment. Do let user to tick an option to select a different game profile.
Also The path should be automatically select the path of the current library for the current game profile.
Picture 2
This way the workflow is streamlined, clearer and more intuitive.

As for the bug I will try to replicate it after work.
Thank you for your replies.

[sedenion]

31 minutes ago, zaelu said:

I think "Software context" can be  synonym with "Game Profile" which might be intuitively clear what it is.

Ok, OMM is not supposed to work only for games, but ok for "Game Profile"...  I will think about.

31 minutes ago, zaelu said:

Also when you create this game profile its path should be automatically saved to a OMM folder in AppData like most programs do and only give as an option for user to activate personal choice for that destination. Like you have now for library and backups. Because User might be more inclined to alter the library and backup folders due to the sizes they can get but the "profile" should be a small size folder that nobody manually alter or care about. However when you create that game profile is another chore or another not so intuitive thing to do first time you use the program.

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 ?
 

31 minutes ago, zaelu said:

And when creating a package the little window should have a field where the game profile is selected so you select also for what game you are doing the mod and automatically select the current selected game profile as it's most usually and intuitively for that game you are going to do a mod in that moment.

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 ?

Edited April 21, 2023 by sedenion

[zaelu]

1 hour ago, sedenion said:

Ok, OMM is not supposed to work only for games, but ok for "Game Profile"...  I will think about.

You could name it: "Game/Software Profile"

 

1 hour ago, sedenion said:

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 see this backwards I think. Most important from my perspective as a user of a software is to be less bothered and less confused especially in first interactions with the software. So yes If you have it set up now that Library and backups are to be saved to wherever the "Profile" is saved and that is in Appdata... it will be a little problem although most users have only C drive and couldn't care less if the library and Backups are in there (like with other softwares) just as they don't care the current mods in DCS are placed in My Documents/Saved games/DCS World.  Nobody cares My Documents have nothing to do with "Mods of airplanes of +3GB in size...
But... Everything can be kept as is with the option to activate personalization of Library and Backups and be moved to another place if user whishes. But most importantly from my perspective is that the profile folder should be by default automatically placed in AppData and user should not be bothered (by default) with what that means as the user would probably never mess with those folders and files and edit them in notpadd++ or somemthing.

So my suggestion was that just as Library and Backups have automatic placements but a tick to activated personalisation so Profile should have and by default should be unticked and a notice that it will be saved in Appdata.
 

 

1 hour ago, sedenion said:

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

I am a bit baffled by this. What?  
The package tool IS a mod creator. It doesn't matter what I am,  the greatest mod creator or a newbie that makes his first try. If I want to make a mod and package it to be used with OMM I want first and foremost to test if it works. So immediately after packing I would activate it. Why on Earth wouldn't I want to have it immediately placed in the Library so I can immediately activate it and test it? Why it would make more sense for it to be on Desktop or another random location?
And second thing... again... I am baffled.  So if I make a mod and pack it with OMM I don't plan to use that mod for myself? Why wouldn't I want it to be kept maybe in my library and maybe when I upload it to some site or online repository or give it to someone wouldn't want to pick it up from that library? Why would I want to have a second library maybe in another place?
And what I said was to be "by default" placed into the game library and have a tick (like above with profile/library/backup) where I could simply choose  another path just like you have it already but now it's in the working folder that could be whenever I had the space to work on the mod... maybe desktop... maybe a root of a drive or maybe Mods/Game directory itself. That is for user's preference. If the user wants different path than library he/she can just chose a different path.

And of course once this idea makes sense then obviously will make sense that OMM knows at least about which game profile it's about and suggests the correct library destination by default. It's not mandatory necessary to have something in the mod that points to the game but in that moment the workflow would suggest OMM should be aware of what is all about.

And finally, why is so irrelevant that OMM knows what game profile the mod is about to be created for? Especially since you want it to be used for multiple games/programs? Say someone likes ho the program works (I did mods for MSFS2020 with OGME fr example) and now after some years has a collection of mods that got mixed up or unclearly named (happens all the time... I have 400GB of mods for MSFS for example) why would be such a bad idea of knowing for what game/program that mod was made? We have so much info now available... picture, description etc but the name of the game is somehow tabou?  Again... baffled  . I don't think is a tragedy that OMM would append to the mod description the icon of the game (if chosen) and a name like: "This mod was made at date for this game". Who knows... maybe gets useful if someone wants to enable the mod later for the wrong game or something.

 

[sedenion]

1 hour ago, zaelu said:

So my suggestion was that just as Library and Backups have automatic placements but a tick to activated personalisation so Profile should have and by default should be unticked and a notice that it will be saved in Appdata.

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.
 

1 hour ago, zaelu said:

Why on Earth wouldn't I want to have it immediately placed in the Library so I can immediately activate it and test it? Why it would make more sense for it to be on Desktop or another random location?

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 ?
 

1 hour ago, zaelu said:

So if I make a mod and pack it with OMM I don't plan to use that mod for myself? Why wouldn't I want it to be kept maybe in my library and maybe when I upload it to some site or online repository or give it to someone wouldn't want to pick it up from that library? Why would I want to have a second library maybe in another place?

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.

1 hour ago, zaelu said:

And what I said was to be "by default" placed into the game library and have a tick (like above with profile/library/backup) where I could simply choose  another path just like you have it already but now it's in the working folder that could be whenever I had the space to work on the mod... maybe desktop... maybe a root of a drive or maybe Mods/Game directory itself. That is for user's preference. If the user wants different path than library he/she can just chose a different path.

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.
 

1 hour ago, zaelu said:

And finally, why is so irrelevant that OMM knows what game profile the mod is about to be created for? Especially since you want it to be used for multiple games/programs? Say someone likes ho the program works (I did mods for MSFS2020 with OGME fr example) and now after some years has a collection of mods that got mixed up or unclearly named (happens all the time... I have 400GB of mods for MSFS for example) why would be such a bad idea of knowing for what game/program that mod was made? We have so much info now available... picture, description etc but the name of the game is somehow tabou?  Again... baffled  . I don't think is a tragedy that OMM would append to the mod description the icon of the game (if chosen) and a name like: "This mod was made at date for this game". Who knows... maybe gets useful if someone wants to enable the mod later for the wrong game or something.

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.

Edited April 21, 2023 by sedenion

[zaelu]

1 hour ago, sedenion said:

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.

But you don't do that. And you already do that.
Let me explain. 
Since we already have what is in the picture 1 why not have same thing in previous screen (picture 2) only default goes to App Data?
Everybody will do a mistake at first at placing the folder regardless if chosen manually or automatically but they can be edited later. Also A simple text added in that place or a tool tip that explains what is each element and the fact it might grow in size to gigabytes will do. 
And again. The profile folder doesn't have to contain the Library and Backups. Is not "the natural way". It's like I save my work in Adobe folder from Appdata or Blender folder from AppData... No... I would never do that. I would never save my work where the settings and profiles of the program are.  Now if the program is small and benign maybe I wouldn't care if that saves me the hassle of reading manuals and watching a 40 minute youtube video that goes around and around some concepts I already know but they are named so different that are incomprehensible at first.

 

1 hour ago, sedenion said:

You want the field pre-filled so you don't have to click the button to browse location ?

Yes. I don't know if it sounds offensive to you but... YES!  The less clicks I have to do the more streamlined the workflow is and the more likable the program is. Maybe is just me. 


I know you can have the mod as a folder but that doesn't mean that once the mod is done I want to keep it that way because I am the creator... maybe I do but I would still want them archived  and placed in same location so I don't create a mess on drives. As I said. Any mod creator is also a mod user and first tester.

Also I don't think it needs to be complicated with a database. It just needs to use the list of the existing "program profiles" in the dropdown list and simply propose the current in use profile folders as default.

I also had the time to reproduce the bug. See picture 3. I created a dummy profile with empty folders and then once all done I tried to edit the backup folder and I used another empty folder when the program prompted me that it cannot be empty. Well... is empty at first isn't it? Also reverting back to first folder (also empty) was accepted. Maybe it believed the path was empty? Although it wasn't as it is clearly populated.

 

 

Edited April 21, 2023 by zaelu

[sedenion]

2 hours ago, zaelu said:

Everybody will do a mistake at first at placing the folder regardless if chosen manually or automatically but they can be edited later. Also A simple text added in that place or a tool tip that explains what is each element and the fact it might grow in size to gigabytes will do.

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 ?

2 hours ago, zaelu said:

And again. The profile folder doesn't have to contain the Library and Backups. Is not "the natural way". It's like I save my work in Adobe folder from Appdata or Blender folder from AppData... No... I would never do that. I would never save my work where the settings and profiles of the program are.

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.

2 hours ago, zaelu said:

Yes. I don't know if it sounds offensive to you but... YES!  The less clicks I have to do the more streamlined the workflow is and the more likable the program is. Maybe is just me.

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.

2 hours ago, zaelu said:

Also I don't think it needs to be complicated with a database. It just needs to use the list of the existing "program profiles" in the dropdown list and simply propose the current in use profile folders as default.

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

2 hours ago, zaelu said:

I also had the time to reproduce the bug. See picture 3. I created a dummy profile with empty folders and then once all done I tried to edit the backup folder and I used another empty folder when the program prompted me that it cannot be empty. Well... is empty at first isn't it? Also reverting back to first folder (also empty) was accepted.

Ok, I will look at this, maybe wrong field fill detection...

Edited April 21, 2023 by sedenion

[zaelu]

8 hours ago, sedenion said:

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 ?

Yes, I prefer not to save there that's why I said all fields should have as the last two have now an automated default setting but possibility to change it.
I simply don't see anything forcing the Library and Backups (but especially the library) to the profile folder where basically OMM is keeping some settings about that game. Maybe the user calls them by the same name but that is about it.
 

8 hours ago, sedenion said:

That is the OMM "Softwate Context" paradigm... Maybe you never encountered this paradigm, so OMM present it to you.

I don't know that paradigm, yes but I've seen many "ways" to skin PC-Cats along the years so... to each is own. However, I said my suggestions not only because of my frustrations while trying to use the software (which now that I know what it does is... fine) but because most moders here are either not packing the mods or are packing the mods for JSGME (Hesus that is what I was using back in the Il-2 of Oleg Maddox era) or rarely OvGME (and when they use OvGME most of the times the archives are bad or carelessly done so it needs repacking anyway) so I think I am not alone when I perceive the workflow and nomenclature (the paradigm) used in OMM a bit... difficult. And since it's a nice program intended to be used by these people I thought maybe the paradigm can be adjusted a little so I proposed my points. 

 

8 hours ago, sedenion said:

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.

Maybe even this could be an option in the settings. Something like:
Save new package in game Library or where the content folder is. And of course... have the tick present so if for some reason for one or several mods the user wants them packed in other place that place is available as a "browse to..." option. So everybody is happy.

 

 

8 hours ago, sedenion said:

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

Here I think you misunderstood my words. I never said OMM should keep such data base. I was just implying that the list of the games for which the user has made profiles is... obvious to the program and it should offer by default to save the package to the Library of the currently selected profile. Nothing more.

Like:
From where should know which game profile library to auto select for user to auto save the package into?
From the drop down list at the top and it can select the currently active one.
No need for some mysql server to run anywhere for that LOL. 

Edited April 22, 2023 by zaelu

[sedenion]

7 hours ago, zaelu said:

Yes, I prefer not to save there that's why I said all fields should have as the last two have now an automated default setting but possibility to change it.

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

8 hours ago, zaelu said:

I simply don't see anything forcing the Library and Backups (but especially the library) to the profile folder where basically OMM is keeping some settings about that game. Maybe the user calls them by the same name but that is about it.

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

8 hours ago, zaelu said:

I don't know that paradigm, yes but I've seen many "ways" to skin PC-Cats along the years so... to each is own.

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

8 hours ago, zaelu said:

However, I said my suggestions not only because of my frustrations while trying to use the software (which now that I know what it does is... fine) but because most moders here are either not packing the mods or are packing the mods for JSGME (Hesus that is what I was using back in the Il-2 of Oleg Maddox era) or rarely OvGME (and when they use OvGME most of the times the archives are bad or carelessly done so it needs repacking anyway) so I think I am not alone when I perceive the workflow and nomenclature (the paradigm) used in OMM a bit... difficult. And since it's a nice program intended to be used by these people I thought maybe the paradigm can be adjusted a little so I proposed my points.

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.

[Habu_69]

Wow! I am a native English speaker and engineer with vast experience writing technical reports for unsophisticated lay persons. Moreover, I have been a PC software user and flight sim enthusiast for about 30 years, so consider myself technically proficient. Now, I have been using OMM since near its inception, as I prefer it over OvGME; and I must admit I AM STILL CONFUSED over the package creation terminology and file storage procedure. I say this not to be highly critical, as I appreciate the efforts of mod developers and I know I could not cope well in another language.

I will try to digest all the foregoing discussion and offer suggestions for improvement.

[zaelu]

6 hours ago, sedenion said:

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.

Thank you for listening sedenion.
Also if you can maybe make it more clear how one can do a profile in the right panel... today I needed to deactivate all mods prior to update for Normanie 2.0 and... I couldn't save a preset with the mods I had activated. I had to deactivate them one by one (Ctrl+Click for multiple selection). OvGME had that disable ALL and a quick way to create a profile before patching and quickly reenable same profile after patch.
 

[Habu_69]

2 hours ago, zaelu said:

Thank you for listening sedenion.
Also if you can maybe make it more clear how one can do a profile in the right panel... today I needed to deactivate all mods prior to update for Normanie 2.0 and... I couldn't save a preset with the mods I had activated. I had to deactivate them one by one (Ctrl+Click for multiple selection). OvGME had that disable ALL and a quick way to create a profile before patching and quickly reenable same profile after patch.
 

Some time ago I created a profile "DCS Update" that disabled all the DCS Install folder mods. Sure can't remember how I did it, tho.

[sedenion]

3 hours ago, zaelu said:

I had to deactivate them one by one (Ctrl+Click for multiple selection). OvGME had that disable ALL and a quick way to create a profile before patching and quickly reenable same profile after patch.

 

41 minutes ago, Habu_69 said:

Some time ago I created a profile "DCS Update" that disabled all the DCS Install folder mods. Sure can't remember how I did it, tho.

 

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

3 hours ago, Habu_69 said:

nd I must admit I AM STILL CONFUSED over the package creation terminology and file storage procedure.

Please tell me what terminology you would prefer or seem more appropriate to you. Explain what shock you with storage procedure.

[zaelu]

I think the "batch" name although I know what it is since 25 years ago is just sending people to something more complicated that it is. 

"Create new Mods Installation profile" might be longer but clearer

Also to create a batch to uninstall mods... I know it works but people using these kind of apps have a button to "uninstall all". A button to "uninstall selected". A button to "uninstall  current tree" (in case there is a tree of folders or mods). So to create a batch that stays in the list of mods profiles to activate it when you want to uninstall it might be counter intuitive or simply unusual.
 

[sedenion]

2 hours ago, zaelu said:

"Create new Mods Installation profile" might be longer but clearer

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 ?

2 hours ago, zaelu said:

Also to create a batch to uninstall mods... I know it works but people using these kind of apps have a button to "uninstall all". A button to "uninstall selected". A button to "uninstall  current tree" (in case there is a tree of folders or mods).

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

Edited April 23, 2023 by sedenion

[zaelu]

3 hours ago, sedenion said:

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 ?

First I don't know if there is one user of the few of OMM that really uses that feature. Especially since DCS is moving away slowly from modding directly the game files and more to mods as separate file trees read on top of the original game files. And secondly I would separate them as they are functions of "different skill level" that should not be mixed and fused into the higher skill level as it will be yet another blocking stone to the program adoption by new people.

 

 

3 hours ago, sedenion said:

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

 

I am all for clean interface but clean and unfriendly is not useful. All programs have a "button bar" and everyone is expecting to find most useful commands there. At least in "Windows world of GUI and Mouse". would rather have such optional bar with configurable buttons (show/hide) than that panel on the right where you can basically build them your self.

[sedenion]

3 hours ago, zaelu said:

I am all for clean interface but clean and unfriendly is not useful. All programs have a "button bar" and everyone is expecting to find most useful commands there. At least in "Windows world of GUI and Mouse". would rather have such optional bar with configurable buttons (show/hide) than that panel on the right where you can basically build them your self.

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

[zaelu]

19 hours ago, sedenion said:

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

Oh, I didn't know. No Problem. Maybe menu options like OvGME had then.

[sedenion]

21 minutes ago, zaelu said:

Oh, I didn't know. No Problem. Maybe menu options like OvGME had then.

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

[Captain Orso]

3 hours ago, sedenion said:

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

To do "Uninstall All", simply de-implement all your mods, and then save that status as a Batch. Mine is named "None". Before every update, I simply double-click None, and the magic happens 

The funny thing is, and I'd never thought of it before, no matter how many new mods I add to my mod-set for DCS, my None batch always works on all of them, always - so cool.