sedenion

I guess the files are not copied due to access permission (files permission is hell under Windows). The Mod appear as "enabled" because OvGME probably successfully created backup data, and when there is backup, OvGME takes it as "mod enabled"... I could sure create a function to crc-checksum all mod's files to verify it is correctly applied in the game tree... but this kind of operation will increase considerably the time needed for mod's installation. EDIT: Well in fact, i forget the very simple thing: i could just verify if the CopyFile function fail... what i don't do currently... If CopyFile fail, this would throw you an error and, there will be no more ambiguity. The resizable window is hell... but i can avoid the line wrap. Also, think that you can copy-paste this output, the "wrap" is only a cosmetic for the text entry... if you copy-paste in a text editor, the line returns will be correct... also, the output "table" uses tab character, so it can be easily parsed by an Excell-like software.

what kind of "sync" are you looking for ?

The problem of what you want, is that all designs i can imagine needs web server... There is two ways i see this kind of feature: 1) The centralised one: You have a web server, with a database that deals both with moders and users. 2) the decentralised way: - Moders (must) have their own web server, or at least, a shared space with, for example, a formatted text in any URL which can be parsed by OvGME. - The user choose to subscribe on the moders's server he want by adding the proper url in OvGME - OvGME check all url, parse data, and give some "need update", and maybe (depending many things) a download. The clear thing is that i will NEVER develops the centralised way, even if i could. For several good reasons (to me). - I am against centralised things on the web (for a gouvernement it's ok, but not for MY Internet...). - I don't want to host and manage the server (i could) and i don't want the software to be linked to a particular server. - A centralised serveur, means: If the server is down, if a day, the server's owner decide to stop, the feature stops working... (this is the problem of centralized things).

Version 1.2 released... well, version number increase fast, but i think we are now very close to a first good final release. Changelogs for 1.2: - Added game snapshot feature (CRC-32 based). - Added Mods profile feature. - New threaded method for mod apply/restore to avoid "Not Responding" during heavy operations. - Overall mod apply/restore algorithm optimized and reinforced (faster, less memory usage). - Main menu logic improved (unavailable commands are grayed). - Overall memory management optimization. - Progress bar logic improved (now work correctly). - Cleaned code & several optimizations. - Help updated The "no enough memory" problem discussed few posts ago, is now a past history, even for the 32 bits version and even with zipped archives. The "mod apply" algorithm is, not totally, but much rewrited. I also have made a lot of write/read tests and benchmarks, even tested the famous (and boring) File Memory Mapping technic, i think we can't do better than what it is currently. So ok, i have to admit : on ~40000 entry file tree with about 20 Gio data, the Snapshot takes 11 minutes to be completed with the Microsoft file memory mapping, instead of 12 minutes with the standard read function...well... but since this pure Microsoft "chef d'oeuvre" API which use 4 functions for one thing with a bunch of "HANDLE", Flags, and things that you don't even know why that exists, is to me, as beautiful as rubbish scattered on the ground... i opted for the standard read... and "so be it" for the "one minute" better.

Still WIP, but will be released in a couple of houres... time to update help, readme etc...

Be informed the 1.2 version is on the way... current changelog is (aproximately): Improvements: - New file mod-apply algorithm for non-zipped mod (sightly faster, takes less memory) - Progress bar logic improved (now work correctly for all operations) New features: - Files tree snapshot and compare. I will work on the "profile" feature tomorow...

Robocopy is a shell command while CopyFile() or fwrite() are C libraries functions... so to say, Robocopy is just another compiled program who (i am pretty sure of that) uses the legacy WinAPI CopyFile(), CreateFile(), CreateDirectory() functions... so there is no benefit using Robocopy (this is like calling a taxi while you have your own car), i can code algorithm directly into OvGME, and this is what i do. Anyway, i modified algorithm to improve file copy performances and memory usage when the mod is not a zip archive, it is now comparable to JSGME.

Hmm, one profile per game would be sufficient ? ( please, say yes, i don't want to create a new bunch of dialog window :p )

problem solved but not solved... in fact, i guess JSGME always use the WinAPI CopyFile function. However, the WinAPI CopyFile works in some asynchronous way, so the program send a bunch of calls with quick returns, but the HDD still working for long time after function returns. In the other hand, the standard ANSI fwrite function is synchronous, and waits until all HDD operation finished to return... the real HDD work time is the same for both, but in the first case, the quick return of function give the illusion it's faster. For the second case, when the function return you are sure that all data is copied and ready for new operation. I now understand why under Windows, the HDD still working for long time for apparently no reason... crap asynchronous implementation, a false good idea...

The 64 bits is a norm for DCS users... but a lot of people still in 32 bits, and since Microsoft does not promote for 64 bits... brief, it's Microsoft... Yes 64 bits version solve it... but i don't like much use this amount of memory... i also noticed JSGME is faster, and, i think i know why. The copy function provided by Windows seem faster than the legacy C "fwrite" function, at least, in the MinGW implementation...

Ok, bug reason found... Before applying a mod, i create a miror image of all data in memory (yes, this is audacious, but based on what is needed for zip archives to avoid extracting all the archive on the disk), and here, with 2GB of data, the program reach up the maximum available memory address for 32 bits architecture... so, kaboom... I hesitate between two ways to solve the problem... The easy way : Compiling in 64 bits. The boring way : Creating a new algorithm to prevent this memory usage while the mod is already on the disk (not a zip archive). However, in this case, this limitation will exists for zipped archives... For now, i provide an optionnal 64 bits version (see first page for download), which solves this problem. Please uninstall previous version before installing the new version.

Indeed it is a bad alloc error... reason unknown... occured on files bigger than ~310Mb... Very interesting bug...

I don't think the issue is related to decompression... more probably a memory allocation issue, or a write issue... i finish to download the mod, i test, and tell you.

Ho my god... Starway Black Sea Map 2.4.rar, is that this 2GB file ?... 2GB (compressed)... i think i know why you have some issue...

Without the mod file to test, i will have much pain to found the issue origin... is it this non-free mod here ? http://forums.eagle.ru/showthread.php?t=164817 no way to get the mod file ?

There is not major changes in mod apply logic between 1.0 and 1.1... i think if you have a problem with 1.0, you will have the same with 1.1...

Can you provide some details AND the mod you found a problem please ? - You enabled the mod using OvGME (yes?) - Is it a zipped or directory mod ? - What problem appear exactly ? (missing texture ?)

Version 1.1 released... Please uninstall the previous version before installing the new one. See first page for download... Version 1.1 changelog: - Adding support for generic 'description.txt' or 'readme.txt' as description text file for mod archives. - Adding right-click pop-up menu for mod list with "open folder or archive" option for quick access to mod content. - Adding ability to choose a custom backup directory for a game. - Adding ability to choose absolute path for mods stock directory for a game. - Adding buttons to enable and disable mods in main dialog frame. - New mod list view with visible enable/disable icon. - Larger dialog window I will see for a game snapshort feature later in the week i think.

Ok, i see what you want... a kind of simplified git/svn for game files. As one say... RTFM :D Anyway i added two buttons + commands on right-click pop-up menu... This is done for the next version... mod stock folder was already an absolute path in game config logic, i just added ability to choose the full path in the GUI, so one can set the mod stock folder anywhere.

Ok, here you have to explain me how this kind of feature must act, because i never used this feature... what is needed to know, how should it be presented, etc.. This is implemented... and it works, as far as i tested... When you enable a mod, it check with all already installed mod to verify if files overlap those of already installed mods, if yes, it prompt you a warning window.. it even give you the list of overlaped files for each mod. You can double-click on mods to toggle enable/disable... but i can add buttons bellow the list (Toggle selected, Enable Selected, disable selected, disable all, enable all)... i even can add some right-click command. Ok Here i need explanation Ok, you mean, the ability to have the mods stock folder in other place than in the game root folder ? The most painful is the GUI, i hate GUI :D

And... no, this is not css/html... i searched for that, and the answer seem to be: with C/C++ standard WinAPI, we must code all algorithms with algebra to calculate ratios and positions each time window is resized, like a warior (which does not surprise me at all) ... not conceptually hard, but painful and boring. I heard somewhere that with MCF lib it's more easy, but MFC is another kind of labyrinthine system... I think .NET implements this kind of automatism, and i even guess that Microsoft sell a very expensive WYSIWYG software with their "Visual Studio pouet pouet" to makes this kind of super cool (and utra-heavy ) GUI, but here i use the good old legacy WinAPI with ResEdit...

Yes i thought of that problem of visibility, however, changing single item colour in the list-view is a kind of winapi-hacking... it is possible, but twisted (thanks to Microsoft)... i will see for that if i have some courage. For resizable dialog window, forgets... this is too painful to code, must implement resizing and placement of all items according window size (ho my god, i imagine the list of GetWindowRect and GetWindowPos to align elements toghether... i know some people do that, but they are paid for that :D )... but i can make the window larger once for all... GUI is the most boring thing to code...

* Support for generic "description.txt" and "readme.txt" in zip : done... * Right-click pop-up menu for "open folder or archive" : done... * Option for custom backup folder : wip... New version will probably be available tomorrow...

Ok, your problem is that the .txt file is in your mod folder, the .txt file must be at the root of the zip file, in parallel of the mod folder, like this: Controls ~~ Warthog_Custom_Controls.txt Controls ~~ Warthog_Custom_Controls - Mods - aircraft - ... ( think about that: if you put the description txt in your mod folder, the description txt is considered as mod file, so is copied to the game file tree, this is not the destiny of a description text :D ) I will considere a generic "description.txt" yes...this is not hell to code :)

OvGME is coded for full wide-char (unicode) support, and has no other name restriction than the system's (windows) name restriction... however, the zip library don't support wide-char, (so i have to convert each path name to 8bit ascii)... maybe the bug is here... (also .txt files are 8bit encoded) Can you give me your archive to take a look at the problem ? PS: the part of code you copied is the one for mod-directory type description (yes, folder mod can also have description, if you let a properly named text file in the mods stock dir), the zipped mod code use another function.