sedenion

Yes, this is a quote from the movie.

"Kent, tu as les narines qui papillottent..." du moins c'est comme ça qu'ils traduisent dans le film.

Well, first feedbacks with current repositories feature implementation tells me that some things must be improved or changed. I brainstormed on how to make the feature both flexible and simple, so: 1) The Repositories configuration will allow to enable or disable any repository by a simple check-box, so, to easily choose what kind of "update" or "donwload" we will do. So, no need to remove or delete repositories if we, for example, want to donwload updates, or synchronize with the team repository 2) The check update will become a generic repository, showing mods who are either: - Allready present in local and up to date - Allready present in local, but with new version available - Allready present in local, but with older version available - Not present in local, so, downloadable User will have choice to download what he want, new version, older one, or, finaly a new mod to download. 3) The mod description will be supported within the "repositories" list, using the XML file to store mods descriptions. 4) The XML generator will let user to choose a custom folder to create the mod list, the XML generator will let user to edit the source, and will be implemented a "save as" to write the "ovgme.xml" where user want to. Implementing what i speak about above will take awhile... Anyway, currently, i have rewritten the network code in a more stable and simple way with way more error check and reports (it is now armored). The previous implementation was also buggy due to over-usage of imbricated threading, making threads synchronization a kind of Rubix's Cube.

That need a whole new dialog with new process and functions... so, please, use add and remove :D

Ok, i found the "Getting data from repository" never ending bug... This is aparently related to compilation optimization who "optimizes" a bit too much and skips some "if" test within thread function... Bug fixed in the last available 1.5.0 installer build.

You want to edit the URL in the Repository config ?... Why ? can't you simply add a new repos and delete the wrong one ? Well, i have replaced the installer binary, you can redownload it and reinstall it.. the comment return bug on Mod Make is fixed, and now the software output a log.txt during Mod Update check process... So: 1) you download the new version 2) you add the repos as befoe 3) you run the check mod update 4) if it freez, you kill the APP 5) Go to <user>\AppData\Roaming\OvGME and open the log.txt file 6) Copy-Paste the log.txt file content here...

Ok, can you let all as it is in your server and give me your server adress ? I have to try to debug and know what happen... hem... the path of what ? Haha ! funny bug... forgot that Windows takes the "IDOK" identifier as default button, and active it when press "Enter"...

New development 1.5.0 version released. For documentation related to the new Repositories feature, please see this post: http://forums.eagle.ru/showpost.php?p=2875105&postcount=95 So, this is the first implementation of the Repositories feature with Mod update donwload, now the question are: - What should be improved, changed ? - What is missing ? - What is good, what is not so good ? - Do you see a bug ?

Yes, i can... but don't ask me to implement i18n for OvGME... I will produce somme french help when the 1.5 will become stable.

Tomorrow I will implement a feature to create a "repository file" (xml) to help users to test the feature and releasing the first "1.5 alpha" version of OvGME (yes, i jumped to the 1.5 due to many changes in code structure + new network features). This is how that work for now: Server side (Repository Manager) The repository manager (either a moder or anyone who can host some file in a website) must make available a "repository file" (ovgme.xml file) on a web server. Adress and port does not matter, as long as this is an HTTP server. ovgme.xml Source Code the ovgme.xml file must be named "ovgme.xml" (for now) and have this structure: <mods> <mod name="Dummy - Mod A" version="1.1" url="http://www.toto.org/ovgme/Dummy - Mod A.zip"/> <mod name="Dummy - Mod B" version="1.2.2" url="http://www.youpla.net/ovgme/Dummy - Mod B.zip"/> </mods> OvGME provides a simple tool to generate the XML source code for the ovgme.xml file. This tool check all mods of the current Mods stock folder (for the selected game) and generate the XML code according what is found as valid Mod. To be included in the source code as "repository compliant Mod", Mods must be: - A valid zip Mod-Archive. - Containing a valid version.txt The version string must be only numbers separated by dots, up to three version number max, one for Major, one for Minor, and one for Revision... examples of valid version string: 2 1.5.0 1.2 Limitation: OvGME does not eat "Transfert-Encoded: chunked" HTTP response (this thing is hell to handle correctly), however, theorically, this HTTP transfert mode only occure when you ask for some complicated page like PHP or ASP... an HTTP server will never (as far as i know) provide a simple xml file in "Transfert-Encoded: chunked"... Client Side (user) A Mods can be checked for update if and only if: - It is a Zipped Mod-Archive (Directory-Mod version check and update not supported yet) - It has a "version.txt" in the root of the archive (like the description) with the version string, and ONLY the version string. The version string must be in the same form as in the xml file... (however, the original mod-achive can have a version "1.2" string, if the repository provide any "1.2.1" version, OvGME recognize it as an update, equaly, for "1.2.1" becoming "1.3" or even "2"... ) The client must enter one or several repository adress in the repository manager. Since i coded an URL parser, the provided repository adresse and port can be almost what you want. Examples of valid adress: www.prout.com http://klathu.net/folder1/folder2/ http://224.24.65.128:8080/toto/tata www.youplaboum.net:8081/repository/ Once you have that... you can Check for update... OvGME will interogates repository, comparing mod names and versions, and give you the list of mods who can be updated... Then, you can launch download (individually, or by group, depending what you want to update)... Rendez-vous tomorrow.

This is for moders, to create OvGME compliant archives... Os to say, this is a simple "zip tool" that create a zip file of given folder, properly named, with the description...

One detail: You can select several mods in the list (ike in any list, using Ctrl or Shift) to enable or disable all current selection, you are not limited to do a "one by one" enable or disable.

I doubt the LayaBox's .lm file are the same as the ones used for "old games"... anyway, since this is not an exchange format at all, no chance to found any converter i think... Try to post any file in joint piece, i will just check if it is an ASCII format.

What is an ".LM" file ? where did you get that ? never heard about this file format...

I think you already can use btsync or Synology to synchronize mod folders with peers if you want... What i'm about to implement is far more simple and rustic than these high-end p2p/cloud softwares. My experience in network programming is about... 4 day :D

reading help should be sufficient for now... nothing realy complex.

You'r welcome, i hope you will like the snapshot feature... i think it's more clear than the JSGME version.

Ok, i am at this stage: - We can enter several repositories to OvGME as http URL (ex: http://www.prout.com/azerty/ ) - We can query all repos, on a query, OvGME: -- for each repos adresse: --- 1) check for an "ovgme.xml" file at the given repo adress ( http://www.prout.com/azerty/ovgme.xml ) --- 2) if found it, parse it. The xml structure is very simple (for now), so it can be writen by an human (anyway an xml generator with GUI can be included later, this is easy to do): <?xml version="1.0" encoding="UTF-8"?> <mod_list> <mod version="1.0.5" url="http://www.toto.org/prout/test.zip">Dummy Mod C v1.0.5</mod> </mod_list>So one or more "<mod>" can be added within the "<mod_list>"... Ok, so, the repos can give this kind of data to OvGME from any website...The question is: What OvGME should do with this data as you see things ? As you can understand, i introduced the "version" attribute and "url" attribute for update checking and download (not yet implemented)... You also can understand that if we have a "version" in the repos, the "version" must exists in the local mod, so OvGME can compare version... this means: The moders must includ another file in his mod, kind of "manifest" with the current version... (this can be a simple version.txt with the version number)

I take the request, but this is far to be done, since network coding, to be well coded (asynchronously), need a lot threading with callbacks functions... getting a response from a server is easy... treating the response to be either a "file download" or simple "page download", all with proper "GUI dialogs" and progress bar without blocking the program... :

I will opt for HTTP... the FTP protocol require user/password request in client side (HTTP dialogs are boring enough to parse at low level, FTP would be hell), and / or a special anonymous account configuration in server side, and while most people know how to put some file in their website to be accessed via http, the configuration of an ftp server with anonymous account is more for "power users". So, the HTTP is easier for everybody.... I am currently playing with sockets and http request/response... this is instersting but spaghetti code as hell...

Well, this is not spectacular, 10% gain... the spectacular thing is that where i need 9mn, you only need 3mn...

Thanks, i'm in south too... :)

Version 1.2.1 fix available (uninstall previous before installing new version... you know...) Features / Changes (1.2.1) : - Fixed two ugly memory leaks. - New write error check for mod apply and backup. - Write performances slightly improved. - Auto text wrap disabled for snapshot output log. - New snapshot cheksum method based on xxHash (faster). - Source code: most functions renamed for better naming logic. - Help corrected. For the snapshot, i replaced the CRC-32 by the xxHash, the fastest open-source hash algorithm presently existing... the fact is that xxHash is, by my tests, 3x faster than CRC32 in term of pure data processing... However, the main bottleneck for snapshots still the hard drive, so, no miracle... but people using SSD will may be seeing a good difference (you'll tell me).

BREAKING !! I found an horrible and stupid memory leak in my mod apply algorithm for zip mod... please prefere using non-zip mod until i publish the fix... (i also do some improvement and write/copy file)

Ok, you and zaelu speaks about two different features...