sedenion

1.6.4 release... and now, except if a new ugly bug appear, i will stop here for a while (see first page for download links) Features / Changes (1.6.4) - Added delete Mod on right-click menu - Added quick make Mod-Archive on right-click menu - Fixed need "Run As administrator" to write files So, no "write error" due to denied access anymore... it will ask you to have the super-power before launching... Note: The "delete" feature do not exterminate the folder or file, it move it into the Recycle Bin

zip is one big file with compressed data packed together and one "central directory" (i.e. a list of names [virtual file path], CRC and coordinates within the file)... So you can't easily remove or modify a "file", since this is only a portion of data within the whole data and this will shift the whole data organization (so you have to rewrite all)... except if this file, is by chance, the very last one in the "data blob", but this is an exception... Well, in fact, almost all in on the wiki : https://en.wikipedia.org/wiki/Zip_(file_format)#Design

After studying the case: I will not implements this. The zip library i uses don't allow easy / optimized way to remove/replace/edit files within an existing zip archive (i think this is in fact a Zip architecture limitation). To do this (apparently) simple manipulation, i need to implement an algo that extract the whole archive (either on HDD temporary folder or in memory (this can require huge memory usage with big mods)) then rewrite a whole new archive with the updated data. The algo itself is not hard to write, but, with big zip files, this process will be LONG (whole extract, whole re-write), and, because that will be long (which is already a problem), the GUI will need a progress bar with cancel mechanism (or users wouldn't understand why the window still open so long after clicking "apply")... To be breif... - This will be "not efficient", because the process is long. - This will be complexe with temporary disk usage or huge memory usage - This requiere another complex GUI with thread process. - All that to only edit... description... Conclusion: - You better use Windows native Zip manipulation within explorer or any Winrar/Winzip app to edit the text files... this will be safer, and maybe (but not sure) faster.

In fact i found the "magical thing" to make app automatically prompt the famous dialog "Do you want this software have all the right to destroy your system as he want just by clicking OK to this anoying Dialog box ?"... Will be available on the next release.

I will probably better help you with the content of the log.txt (C:\ProgramData\OvGME\Log.txt) [i should add this in the help with some troubleshooting FAQ] However, it seem many people have file access configuration that need OvGME to be launched "As Administrator"... since OvGME must copy Mod files to game folders, it need right to write files in game folder, and many people seem to does not have natively the right (as user) to do that. If the "Run as Administrator" does the trick, please confirm me... Many people report me the same problem, i will add this in a FAQ in the help. Don't know what "file" you talking about, but you can do (almost) all what you want, OvGME is open source...

Theses features are not too hard to implement.. Fill asked me for an option to delete mods from right-click too... I will see this for next release

( they "invaded" NATO, but shhhtt... this is a secret... https://www.youtube.com/watch?v=x5JoQT7XhW0 )

I think over the years, the Italy folder encountered some glitch in filename... how, why ? don't exactly know, but i have a beginig of reponse: MS

New 1.6.3 release (not pre-release), see first page for donwload link (both setup and binary .exe) There is many small or big fix and optimizations in this release.. this would probably resolve almost all problems with Mod-Archive... Also, an option was added to choose the compression level of the Mod-Archive. Features / Changes (1.6.3) - Fixed Make Mod-Archive bug when created in Mod stock folder - Fixed bad optimization on Mod overlap check - Fixed error on read or write 0 bytes - Fixed main progress bar not working - Fixed Directory-Mod has sam version than Mod-Archive - Fixed some Cancel button logic - Added compression level option for Make Mod-Archive - Fixed Undo Mod inconsistent warning log output - Backup cleaning optimization - Added Mod Process safe Cancel and Undo logic

I know why your zip Mod-Archive don't work... because a file in the archive has 0k size, and with the way i was handling file writing, writing 0 bytes was considered as a write error (this is now fixed, writing a 0 bytes file doesn't throw error anymore)... The question is: Is this file really have 0k size in the original mod files (before it was zip compressed). Send me private message... why do you want my email ?

The files withing this folder does have this "°", because a file name is a full path, and the full path include the famouse folder... but here, it is trucated, si we have a bunch of files with the same name, which is totaly buggy... The fact is that this "°" character does not exists in the original DCS files... i think this "°" has nothing to do here and is an artifact of unicode bug on the name. And this is probably the reason why: - OvGME produce an "end of string" during conversion process (from unicode to ascii). - You have problems with "phantomatic" character that exist but not shown by Windows Explorer in some file names. For this case, i think the problem is with the original files... and even if you don't get error with the Direcory version nor with JSGME, the Mod, as it is, with this strange byte sequence in names not working as it should (the files will not be writen in the proper game folder). Can i download this mod somwhere to see the original mod files, maybe to see where the "glitch" comme from and what is its form... (see exactly the bytes sequences in names, and why it produce an '0' at ascii conversion).

Ok, your error is not the sam as the fill error... Here, there is a problem of file access. The error say: "I can't open this file to write to"... i guess in fact this is not a file but a directory (and this is why he can't open it to write)... <snap> Ok, i checked original files in game, this "Bazar\Liveries\uh-1h\Italy 15" does not exists, it is in fact a directory named "Italy 15B Stormo S.A.R -Soccorso"... I see in WARNING log that even the "Italy E.I. 4B Regg. ALTAIR" was croped to "Italy E.I. 4"... It seem this "B" is magic, because it produce an "end of string"... (??!!!) Can you check in the Mod file tree if the "Italy E.I. 4B Regg. ALTAIR" and "Italy 15B Stormo S.A.R -Soccorso" are correctly named ? (i suppose yes, i realy don't know why this happen) EDIT: I tryed with the original game file, there is no problem, the path is not truncaded.. The "strange" thing is in the original Mod files it seem... Is this Mod donwloadable somewhere ?

Ok, i think i got the problem... fill, zaelu... if you look at the log.txt ( at the proper location :D ) you will see two lines like that at the begining : ERROR: GME_FileWrite :: Write error : D:\<long path>\custom.lua ERROR: GME_ModsApplyMod :: Unable to write file : D:\<long path>\custom.lua (Don't pay attention to the looong list of WARNING that follow, it is normal.) If you look at the zip file, you will probably find that the famous file that produce the error is empty, with a size of 0k Can you, please, verify that this file is actually REALY empty (0K) in the original mod files ? (i think no, but, that would make me happy) ( fact is: when you check if more than 0 bytes was written to determine if the function succeed.. and if the size to be written is 0 bytes, you have a problem)

Theorically, data size does not matter... (except if HDD is full)

The OvGME data are no longer in Roaming since the... 1.6.1 if i well remember... you can delete this folder. The OvGME home directory is now C:\ProgramData\OvGME or C:\Users\All Users\OvGME Here the log text should not be empty...

yes, i updated the binary.

( I just modified (now) one detail on how OvGME update mod list... updated the binary exe too... If some people sill had problem with the version downloaded one houre ago, retry with the new build now available )

Oh ok, again this Mod... yes, 3Go of data... it is a good "stress test" for OvGME, already had some problems with this one :D

Ok, i worked a bit on the "Make Mod-Archive" algo... You can download the binary pre-release of the 1.6.3 version here : https://github.com/sedenion/ovgme/releases/download/1.6.3-64/OvGME.exe Just overwrite the old OvGME.exe in the OvGME installation folder... I hope now, the Mod-Make work correctly: - I found ONE "bug" (the opened files for reading were not closed after use, which is bad)... but i am not sure this is the root of problems you encounter (i have no problems on my side, all work perfectly, even on huge archives). - I also changed some file creation logic to prevent access on archive while in creation process which could corrupt the archive... The zip file is first created as temporary file with .build extension, then, renamed ONLY when all is finished and finalized (zip central directory created)... So, normally, from now, while the file is not a ".zip" file, the file is not finished... Once it is a "zip" file, the file is (theorically) finished and valid. I can see an hypothesis on why the Mod creation is so strange and random, if the mod-archive is directly created in the Mod stock folder: When any change occur in the Mods stock folder, OvGME rebuilds the Mods list, and gathers data about available mods.. And so, it OPENS all zip archives to check if they are valid, gets description, version etc... I could imagine what can happen if an archive is both opened on a side for writing/compression, and in an other side for reading/extracting... Not good thing anyway...

!!! something asynchronous seem a bit too asynchronous... I think once you access to the archive, there is some access competition, so the file is not well finalyzed... i guess the bug is amplified with big mods (heavy archive), long to write...

Strange... where can i download this mod to test on my side ? Theorically, no...

I checked the zip generation code again, and i don't see how and why this error happen... Please download the last build (either setup, or update exe [to copy in installation folder]) I added some log output to have details about that kind of thing... If you encounter problem again, at the first error message, copy past log here.

Hmmmmm.....ok... so files are created on "random basis" in the zip file... i will look at that. Note, you should not have error on write config file (this mean OvGME failed to write into the ProgramData/OvGME/config.dat file, where it logically allways have write access)... when and how do you got this error ?

Ho that ugly messages... Extraction failled and Write error on config file is not the same error as fill... Fill have a simple write error, here, you have very dirty errors... Empty archive, you mean ? Nothing in, or folders but no files ? Don't understand the strategy here... please give details... (and logs if possible)

Ho shit... sorry, my bad... I correct that tomorrow as soon as possible, for now i (what is the correct translation for "cuver" in english ?) my delicious Corbières wine... (I switched Hard Disk, reinstalling systems, and some of my build confing "disapeared" with fresh compiler install... and then, you have this error because <guess here a long technical explanation>) EDIT: Finally rebuild the softwar full of wine... obliged to switch from Linux to Windows to do, but duty is duty... The new available build should not prompt you any "libgcc" or "libg++" missing anymore...