sedenion

Right. don't know how this work... yes.

No, sorry... I will wait for a more "final" release of the module before twiking again (if needed)

What do you mean by 'keeps" ? It does not keep anything except backup data. You mean profiles ? for profiles, enabled state are saved in the order they were in the list: alphabetical order. (then restored the same order) if OvGME makes some listing, to save as profile, or to apply/disable several mods at once, the basis is the mods list order, from top (index=0) to bottom (index=N), which correspond to alphabetical order, since the list is alphabetically ordered. for all operation, the code is roughly (very simplified) this: To Enable or Disable list of selected mods, or all mods in the list: for(i = 0; i < mods_list.size(); i++) { if(mods_list[i].selected == true) Enable(mods_list[i].mod); }To Save a profile: for(i = 0; i < mods_list.size(); i++) { profil_list.add(mods_list[i]); } WriteToFile(profil_list);To Apply a profile: profil_list = ReadFromFile(); for(i = 0; i < profil_list.size(); i++) { if(profil_list[i].enabled == true) { Enable(profil_list[i].mod); } else { Disable(profil_list[i].mod); } }

The mods are applied in the order you apply them... If you enable several selected mods at once using "enable selected", they are applied sequentially 1 by 1 in the order they are in the list (which is alphabetically ordered, indeed).

I will look at that... EDIT: Fixed.

Almost everything is possible, but in this case, there is no easy and clean way to do that, this requires extra configuration files, with more tests and contrôls, for, you have to admit it, a single benefit useful only for one special case... Your case is an usage exception, i can't design OvGME for each usage exception. I suggest you to apply the workaround provided by Zaelu....

"Necessary" i guess (unfortunately) yes, "compatible" i guess no.... these mods need to be updated, but i will do that later

I replaced the custon method by a call to standard microsoft function... I am lazy to create a new version (editing readme, changelog etc..) for that, but i updated the binary + installers... the problem seem fixed (for date at least, if it was a date problem).

No... because currently i do not use the Microsoft's "Copy file" function which (i suppose) keeps/copy the creation/modifcation date... i use a raw "home made" copy function.

I think the key is modification date... DCS does not check any CRC or Checksum (too heavy test for quick update/repaire check), but only creation or modification date of the file.

What is this "Backup001" folder ?

Ok, anyway i answare your previous question: If your repository file is a static standard XML (ex: repository.xml) the url to provide must be the full URL to the file with or without the .xml extension, example: http://www.toto.com/repository or http://www.toto.com/repository.xml if the xml data is dynamicaly generated by some PHP or ASP page, you have to provide the full url with extension (and options if needed): http://www.toto.com/repository.php http://www.toto.com/repository.php?opt1=a&opt2=b ( All that is explained in the help :D )

well, i have double-triple-quadruple armored pointers allocation, avoided some of them... if you still have issues, the bug is really, really well hidden... please re-download the 1.6.5 version (build updated) no, i removed description encoding only for the temporary 64 bits debug build... I have some idea why the issue was (i hope WAS) random and probably amplified in 64 bits version... but not sure... anyway, i have rewritten many functions, and it is now nearly impossible to have a "segfault"... still some unarmored alloc, but only for some very simples routines.

In the version you donwloaded, the description encoding is disabled (description are empty), it seem to be the main bug generator... but if you have random bug even without that, i realy don't know where to search...

Not helpfull... i must reproduce the bug, or i will never understand what happen... can you test with only 2 or 3 mods and a stupid url like 'toto.net" ? Try to isolate the bug... test with only one mod without version nor description add a short description and test again add a version and test again add a big description and test again add a mod, and test again etc... try with this binary and tell me if the problem still here (i removed some part, for debug purpose): https://github.com/sedenion/ovgme/releases/download/1.6.5-debug/OvGME.exe

Work on my side... i think this is an binary update problem on Github... try redownload please.

This is called a segfault... Not related to any path or whatever, it was a stupid mistake in the code... pointers, memory and so on... Fixed in the new build, i don't have changed version, the new fixed build and installer are available to download as 1.6.5 version.

1.6.5 released, donwload link on the first page Features / Changes (1.6.5) - Added ability to keeps configuration files during uninstall. - Fix uninstall process don't clean backup data. - Fix some dialog text spelling and sentences. - "Game" is now a generic "Configuration". - Help updated and corrected.

I am currently on it... in the first times, a total configuration deletion was needed since the configuration data organisation would change from one version to another... but now the configuration structure is pretty stable and should not change, so deleting all config file is no more vital.

It delete all... If you want to save a configuration, before uninstalling, you must 1 - Disable all mods 2 - Save all the content of "C:\ProgramData\OvGME" including sub-folders When reinstalling, copy the saved content

Same as VTH, i wait for razbam to finish the VTH implementation to update the mod.

Probably, but i wait for razbam to finish the VTB implementation to update the mod.

Let be simple... 1) OvGME don't care where Mods to be installed are located : You can choose the folder you want on any disk for any game config. 2) OvGME allow you one game config per "root folder", this mean, if you have Mods who should be applyed in "D:\DCS World OpenBeta" and other mods who should be applyed in "C:\USER\DCS.openbeta", it is like you have two games, so you can create two "Game config": - One for the game installation folder: Root path="D:\DCS World OpenBeta" - One for the game user settings folder: Root path="C:\USER\Saved Games\DCS.openbeta" You name them and manage them as you want (maybe i should replace the "Game" by simple "Config", since, indeed, this is not specifically related ot ONE GAME, but only to Mod installation folder)

I just don't understand what you are attempting to do... what are "mods for the export file" ? Only one game config per game root folder is allowed (to prevent overlap and backup corruption). But i don't understand the strategy of Sobe...

No, no know bug, it was just a bad formulation, the good one is : "except if an ugly bug appear"... it was late, i was tired. I thought about codding a whole simulator (already coded a very simple demo in WebGL several years ago) but alone it is hard. For a DCS module, the Mirage 2000 is already made by Razbam, and it is probably the only module i wish to participate.