sedenion

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.

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