sedenion

Outch ! Indeed, here, even if it is possible, this become a very specifical behavior which imply even more dirty things... If Windows embeded something like Linux's Bash, with a security environment comparable to linux (which disallows scripts to traficate things everywhere), I probably would have included a way to automatically execute a custom shell script at mod install... But the Windows environement and average Windows user behaviors tell me "Ho no, man, don't do this, this would be a time bomb !". Ok, good argument. I keep that in mind and I will think about that.

For the new year, a bunch of "Work In Progress" screenshots with some configuration and settings dialog to help you understands the new Module / Context software paradigm... Remarks, comments and questions are welcomed, especially if you see something that appear to your as a "wrong idea"... Since things still in development, this is NOW or, maybe never...

Yes, this is the most obvious way to do : Adding another file in the mod, that the software will check and parse... But in your example, the mod maker manually defines the destination path where to modify the file, which is a problem because this break the software general paradigm, where destination path is defined by the user into its personal game/mod configuration. And why this paradigm is important ? : If I allow mod-makers to modify an arbitrary file with an arbitrary destination path, which is not the the destination path defined by user, then, I allow the mod-maker to traficate anything in the user's computer, this could becomes an huge security issue. So, I cannot validate this solution... However, ba happy, I know an alternative: - The mod-maker places the file to be "modified" in its mod, like any other mod file, but the file contain ONLY the "line" or "content" to be concatenated to the existing file, and the mod maker add an extra XML file with something like this inside: <exceptions> <[b]concat[/b] src="\config\autoexec.cfg"/> </exceptions> So the software is informed that this specific file, in the mod files tree, is to be "concatenated" to the already existing file instead of "overwrite". Notice that the path is completely relative, and depend on the target destination folder the user choosed for this mod... this way the user cannot be fooled by a malicious mod-maker, and this is even simpler to write for the mod-maker. HOWEVER: The problem remain, that is that this remain an pure exception usage, which needs another file to be checked and parsed, but more important : a full new conditional branching in the installation, backup and restoration algorithms, for only ONE exception usage: That is obvious, but this is not as simple as that. In fact, this exception feature would impacts ALL the installation, backup and restoration algorithm, because we would need to check for each mod files if the file is to be "copied" or "concatenated" at installation (depending the exception list), storing the appropriate backup info, then at the restoration, same mechanism again. You said it, this is a "needed feature for DCS Liveries", but nothing else... Haha ! And maybe you also want to allow mod-makers to automatically execute a virus while enabling a Mod ? :D Sure this is possible... But I Am sorry, I know this kind of "huge security hole" is a common behavior in the Microsoft world (see also: ActiveX*), but I came from a world where this kind of thing is simply forbiden by principle. Do you want me I request $20 to each mod-makers to give them an "authentic signature" with their promise that they don't did malware with mods ? Interesting business model... :D Ok, lets be serious again: I can implement such "exception" feature, with an extra XML where some exceptional behaviors are described by the mod-maker. But, since this would needs an installation / backup / restore algorithm refactoring, I Need that this feature to have a more general purpose, something that can be usefull for other things that only "edit the autoexec.cfg" of the "DCS specific" liveries management... I need a good reason, something that tell me "Ho yeah, this feature will make this software greater for many many people, and not only DCS's liveries mod-makers", can you understand this ? So, I ask to others users and mod makers... how this "feature" can be enhanced, to become more general, and provide a real good deal for mod makers and users, not only for DCS's autoexec.cfg file ? That is the only thing I ask : A real GOOD reason to implement this...

Hahaha ! This appears always so simple when people ask for features :D From now, when somebody ask me for a new feature, we will play a game: Be the software-concept architect, while I stay the programmer. As a programmer, I can tell you: Adding some text at the end of an existing file, this is very easy, i know how to do. But, dear software-concept architect, how do you want your feature to appear in the software ? Where is the "line to add" ? How the Mod Maker should build its mod so that the software know that "this line" must be added "here" ? Be sure I have some ideas, be sure i know what are the problems, but I want you to explore yourself the puzzle. And maybe you would have a good and elegant idea about how to implement as design an "exception feature" for an "exception case".

Some news for you... The development of OvGME is now stopped until new order. I am currently working on its successor, this is far to be finished, but this is on the good way. Don't jump of joy now, nothing is aboutished and still many work to achieve. However, some words about what this successor should be. What is currently implemented: - The backend program is totally new, massively object-oriented, much much more modular, to allow extending features more easily. - Decentralized configurations, it is now possible to locate all configuration where we want, creating separate folders (some details bellow). - All configuration and data files in XML, more flexible, and transparent (users can read them, understand them, maybe manually edit or create them if they need to) - The software now works around what I called "Modules" and "Contexts": One Module is, for example, a full configuration for one or several games or application. Inside each module, you can create several Contexts. One Context, corresponds to what is called "One configuration" in OvGME. This mean, for example, you can create a Module "DCS 1.5 Beta", with two Contexts : One for the game root, and another for the "Saved game" folder... - As cherry on the cake, Modules are planned to show a banner (picture) of your choice on the main window, this way, you feel at home. - Mods are now called "Package", and you will understand why. - Package overlap is now supported and managed smartly (but not magically). - Backups are now zipped, the default is to create zip backup with 0 compression to increase speed, but it will be allowed to choose a compression level. What is planned (non exhaustive): - Packages dependency management, which mean, mod-makers could be able to declare in some config file, that a package need another one to be installed first. This allow to create "mods of mods", or "patch of mods"... The dependency mechanism is already here as potential. - The ability to include a logo or picture (only one) for packages in addition to the usual description. - A new GUI, with tab controls, to allow a more flexible and quick access to sub-features such as mod profiles, online repository, etc.. But, I don't have a clear vision of the GUI organization for now, all is subject to change. - Mod profiles will now be called "batches", and are planned to have a customizable installation order. - An HTTPS compatible online repository management, using libcurl, but I have a lot of things to acheive before that. - A 'Module Template' mechanism, to allow people to create pre-architectured Modules with some presets (banners, names, network repository, etc), so other people can donwload and open the "Module Template", specify some parameters corresponding to its specific local config, and then : all is ready to go !

And paid... because software like Visual .NET are not free... The fact is, if you want to develop an efficient and optimized software, you need low access on file system, permission control, etc... And this is not the hard part to code. Even a sorting algorithm is not hell to implement. The real problem is the GUI... THAT is hell to implement smartly. Do you really think CSS is fast ? My own "resize" function is fast... CSS is a spaghetti monster, in fact, I don't understand how this thing is able to run without explodinh. As i said, take a look at chrome memory usage, you'll see the cost of "CSS"... Yes, the RAM is also here to be sold by manufacturers... like the Core 8 duo 4.0Ghz and the liquid azote cooling system that come with (fictionnal)... This is not a question of "restriction", this is a question of optimization. the purpose of any software should be to be fast, efficient and optimized, not to don't care about memory usage or CPU ressource because "it is available". Many laptop computer still have only 2GB of RAM... when users opens 4 chome tabs, the computer switch to swap disk memory, and calls me "I don't understand, my computer is so slow !"... "yes, it's because you dared to open 4 Chome tabs... computer industry want you to buy a new computer, that's life !" As I said, I am an extrimist... I saw the computer industry evolving, may be like many here, since the first Intel 80/86... One day I decided to be against some logics, I switched to Linux, I use Windows only because some things like DCS still under Windows... Even under Linux, I am agaist the new "GTK 3.0" and other "Unity" windowing systems, which are kind of monster between C# and CSS that use a lot of ressources for... nothing... I am against many recent direction taken by developpers and corporations... like .NET, C#, Swift, CSS... because yes, nobody seem to care anymore about ressources and optimization, we have GHZ and GB, so "don't care !". I can understand the logic of buying a new graphic card to display very beautifull grapgics at high speed, but I am against the logic of buying RAM and GPU because Microsoft or GTK team decided that "Well, we have GHZs, let's write some dirty and stupid code, we don't care, the CPU is here to compute it !"

And I want to add : I hear your requests, and i understand them... I am like you all, I like well designed software, and I hate that kind of small misdesign that force you to workaround... I really would to create a good software, with a smart GUI and features, and as I said, I am currently thinking about creating a new software to replace OvGME, not so much more sophisticated, but a little bit, and more "clean". I don't know if i will, but I am studiying the concept and the "how to"...

I don't seek for remplacement of the C WinAPI... I will make some off topic here (but this is mine, so...), this is not an attack, i only explain my point of view. I have to admit I am a little bit extremist and have special developpment ideology... Did you noticed how many application now requiere an additionnal installation of "C++ Redistribuable blah blah" or the "Net Framework Redistribuable blah blah" ? Don't you noticed how GUI are slower and slower despite the fact you have a Core 2 Duo 2.5Ghz with 16Gb of RAM ? One day, I installed the famous Visual Studio .NET Pouet-Pouet last version (evaluation version) to test... Even the installer, created using the very last .NET super last version, was not able to corretly align two frames, displaying graphical glitchs, and was slow as hell... Electron... This is a Node.JS backend, interpreted javascript, running on chromium engine... this is a totaly differet development environement, and I don't even know how this work once "packed": is there compiled code or interpreted using external engine or "virtual machine" ? I don't know... One thing I am sure, is that this is again a "layer over a layer over a layer over a layer"...The only advantage, is that this is "cross-platform"... Did you noticed how much memory Chrome take, only with one blank page ? 500MB... opens 2 tabs, this take 1.5GB... Holly Sh*** ! Nowaday, we have now so much layers over layers that even displaying a rectangle on the screen take more computing than resolving physics rigid body collisions equation, soon, you'll need to a Core 2 Duo 4.0Ghz to run a simple calculator... Ok, now, did you see how OvGME is running ? Except if you enable or disable a 2Gb mod (and here, this is hardware limitation, nothing to do), this is almost as fast as an UFO... This take 2MB on the disk, take 1 second to install, this works everywhere, everytime, without any additionnal library, package or virtual machine... And i did some mistakes, some things can be optimized, designed in more efficient way... So yes, the GUI is simple and even rustical, and certainly not perfect, because this is root-low-level technology, dealing almost directly with the system's kernel, and this is boring to code because I have to implement almost all things myself... But, this is my programming standard: Highly compatible, fast, close to the low-level, without any additionnal things... If I have to rewrite OvGME in a more sophisticated fashion, I will use the same standard, but, this will surely take time, more time...

Ok guys, don't starts to fight... I understands the the problem with "remember the path". I totally agree that this is boring to pick the good path again and again. So to this specific request: First, you have to admits this is a detail, for example, you can use ctrl+c to copy the path string in the clipboard and paste it again into the entry, this works fine, you are not forced to click on the browse button again and again. Secondly, technically, this "remember feature" is not formaly hard to implement. The main problem is that, this would add another ad hoc variables and processes along what already look like spaghetti code. I also received a request to implement the more modern "choose folder" pop-up. Now, about OvGME and its evolution: The fact is that I developped the root architecture of OvGME in somewhat 1-2 weeks, so to say: extremely quickely. It was designed as a small gadget, additional features was added like you put a lego piece over another one, not really anarchically, but close. The fact is that this is my first application with GUI, I am more used to developps around OpenGL, in abstract paradigms, object trees, mathematics, etc, so to say: what is behind what the user view. You see plenty of details in GUI that does not fits the standard fluent GUI of modern applications, because OvGME was developped as mentionned before: adding some feature here and here, only as gadjets, and it is based on the good old C WinAPI of Windows XP (and even Window 98), all is hands made, nothing is automated. The GUI would requiere an program architecture for itself, which is currently not the case. I am facing now to a dilemm, in fact, I am thinking about developping an entirely new application, because I think OvGME is now close to its limits, I see my own code and I tell myself "Oh crap, what a spaghetti code, if I modify this, I have to modify this as well, and Oh, what is this shit ? pfiouu...". I really would to create a super GUI, with a toolbar, etc. but the tools I have don't allow me to create this easily, and some apprently simple things are in fact a real brain teaser to implements.

I think not... but I don't even understand the request. remember where, from where, to where, to achieve what ?

To be precise, OvGME warns if a mod need to backup a file that was already backuped by another mod. That is, if a mod add a file that does not exists in the vanilla game, you wouldn't have a warning, except if you overwrite the file a second time using a third mod. OvGME is designed with for prioritary objective to prevent game original file to be lost... but not to manage mods overlapping (this is not considered as good practice, and this should be avoided as possible)

The new build is online, for who already downloaded the "bugged" version, you can redownload the fixed one using same links (version not changed).

I will make a new build, but there is too few changes for new version. Python is probably more flexible, but, Python itself is written in C and can't compete with C/C++ in term of performance, not the same purpose :) (ok, performance for sorting a list of 5-6 string entries is not critical, but to hash 2 GB of data, it is...)

You will be happy to know that I fixed the sorting function for config combo list... that was in fact very easy... For curious people, here is how that work:

The description and versioning does not work for standard directory-mods, precisely because they would have to be outside the mod directory, which is not clean. You can put the readme within the mod folder, but in this case it will be copied into the game folder when mod is enabled... This is not what is supposed to happen.

The description file is intended to be in the zip file. OvGME natively support zipped mods and read them directly, so you simply have to copy or move the zip file... maybe this is the part you missed.

You talk about OvGME or JSGME ? OvGME warns you if a mod overlap another one... At least, it should, it was programmed this way. This is an old request of some people, but this is hell to implement right now... maybe I will do that a day, but I am a bit lazy.

Hem, no, I can't... using an exe program to achieve such thing withing a C++ program would be like making a coktail by contacting the NASA to launching a rocket with some water to the dark side of the moon to congelate water, to waits the NASA mission returns, to be delivered the ice using an special UPS shipping, then finaly putting the ice in the drink... It's better using your freezer :D

OvGME is writen in C/C++ not C#, and, be ready: no, there is no STL function to sort strings alphabetically, or if such thing exists, i don't found it. Like many apparently simple things, in low-level language, you have to "MacGyverize" it yourself, and this is sometimes more convenient to "MacGyverize" it yourself than using a library. There is a std::set object that exists in STL, which can be used for this purpose, but it does not supports the array subscript operator [ ], so you have to "for_each" to rebuilt the list in std::vector, etc... so I decided to implement my own sort function. I will see if this exception of equal strings but with non-equal lenght can be fixed easily, but I will not take this as an emergency...

I have to admit my sorting algorithm is pretty simple and rustical, i don't have considered all exceptions. I surely could achieve a better sorting algorithm, but, do I really have to implements a bulletproof sorting algorithm to prevent that, or can you survive with this glitch ? :D

OvGME 1.7.4 released No major changes, but some debug and details: OvGME 1.7.4, 2017-13-11 - Fix crash when pressing Esc key in configuration window. - Config combo list is now alphabetically sorted. - Fix window restored as minimized at startup.

Yep, this occurs when the app is closed while at minimized state. This will be fixed in the next release.

Unfortunately, I think I can do nothing for this. I use a third-party library to pack into zip file, this is probably this third-party lib that add this offset. The "why" is totally out of my knowings. It is out of the question to implement an automatic "choose the root folder according X, Y, Z conditions/parameters". - OvGME is intended to be generic, not specific for DCS. If I implement such feature for DCS, I have to implement it for ALL other games: NO-WAY :D - This requier to maintain a kind of data-base, with existing game, giving them an ID, and manage it whithin the mod generator, or in chage to the mod maker to place the right ID... Whowoo, you love problems, no ? :)

Ok, I think I got it... For some unknow reason (but I can guess some), it probably stored its window size with 0 width and height (OvGME stores its window size on quit, to restore it after). Can you try to simply right click on the mini window toolbar, or icon in task bar, then select "resize"... then, resizes... For the "why" it did this... Is it possible that you exited OvGME when it is minimized in the task-bar ? For example, by quit windows while OvGME is running in minimized (so it is closed by the system) ? Anyway, i have to implements a test to prevent this behavior... If I am right, can you please add an issue describing the problem here ? : https://github.com/sedenion/ovgme/issues/new

Stop here... did you said that OvGME is actually running but in minimized window ?