Yoma's Arma Addon Synchroniser

[Robalo 465]

Excellent app Yoma, thank you very much for developing it.

I have this suggestion - can you please not replace the server list every time the app is updated ? Unless you are changing it's format, there's no need to lose the user added servers with every update.

Otherwise we have to use the export/import feature which is very useful atm.

[Yoma 0]

Excellent app Yoma, thank you very much for developing it.

I have this suggestion - can you please not replace the server list every time the app is updated ? Unless you are changing it's format, there's no need to lose the user added servers with every update.

Otherwise we have to use the export/import feature which is very useful atm.

I'll look into it soon.

The problem is that i put the ServerSettings.dat in the application folder, which changes on every update (downside of clickonce update)

I do not intend to drop the updater as it's proving very handy.

I'll have to make a 'Program data folder' and put the settingsfile there, so it's location won't change on every update.

[Auss 208]

JUst a quick note for any player who downloaded the @OGNCTI mod folder in the last week. There was a small change to the crcti_buildings addon which may cause issues with the OGNCTI CTI missions. If you check your mod folder and find a pbo with the same name and it has capitals please delete. When i repackaged the newer addon, for some reason the XML didnt change the name accordingly.

[Yoma 0]

You could also use the 'Delete extra files button' so it will become exactly the same as on server.

Aussi could you give me some more info on what happened.

e.g. filename of original, filename of modified...

Just to check why the xml did not change...

You are absolutely positive you upped the xml also?

[Yoma 0]

**NEW VERSION**

-Added parameter Application Data Path (defaults to c:\Program Files\ArmaAddonSync\Data )

-Your serverSettingsfile is now saved in this directory instead of in the clickonce deployment folder.

In short this means:

UNLESS MAYOR CHANGES OCCUR IN SERVER SETTINGS:

YOU WON'T HAVE TO RESTORE YOUR SERVER SETTINGS FILE AFTER EVERY UPDATE

Of course this starts from updates following this one.

I have a question for everyone that's using it, especially server admins:

Do you need some kind of 'security'?

E.g. some kind of password that can be provided in order to 'secure' addons. I may be prepared to code something VERY BASIC (which will be easy to hack, but will allso stop allround public addon leachers)

[Robalo 465]

Yoma,

Thanks for making it happen. I have this new error unfortunately:

My OS is Vista64. On my system that path does not exist. It seems to be UAC related, perhaps you must choose a path within the user's appdata folder ?

[Yoma 0]

Hmm did you refuse to give it permission to create the folder?

Does it not ask to create a folder there? If the app can't create the folder, just create it yourself, you should be fine then. Else provide me with a full UAC-safe path so i can change it. (of course that would mean everybody will loose their settings again! lol)

I can't test stuff on vista because i don't have vista.

I wont have vista untill all games run decently on it.

I honestly don't know what security enhancement there is in refusing access to the bloody program files folder, and allowing it elsewhere. People will simply hack using the other folders...

[Yoma 0]

**New Version**

-For the Vista blokes that love UAC :-)

 => Server Settings will now be saved in Application    Data\ArmaAddonSync\

THIS MEANS THAT YOU WILL ALL HAVE TO IMPORT THE BLOODY SETTINGS ONE LAST TIME...

SORRY  

I hope it works for VISTA I am not able to test it. Do give me feedback please.

[Yoma 0]

I'm currently working on a new version where you will be able to supply a password for a modserver.

This is not very secure or anything, it's just so people can avoid the greater public from leaching their server with my tool.

[Robalo 465]

Works like a charm now Yoma, thanks a bunch !

(Vista64)

[[aps]gnat 28]

Lovely work Yoma !!

All worked fine on the OGN server except I got this error (see posted pic in thread)

http://forums.ogn.com.au/showthread.php?t=52055

Cheers.

[gonk 0]

it works fine on vista... just need to manually unzip and install.. the update your program part does not quite work... I guess it is permissions... and at this point in time I can live with manually updating.

Feature request.. if possible... Have one button to check and down load all addons for a site... rather than checking one addon at a time...yes I am lazy...

anyway great program...BIS....hint hint..

[Yoma 0]

it works fine on vista... just need to manually unzip and install.. the update your program part does not quite work... I guess it is permissions... and at this point in time I can live with manually updating.

Feature request.. if possible...  Have one button to check and down load all addons for a site... rather than checking one addon at a time...yes I am lazy...  

anyway great program...BIS....hint hint..

-Problems updating are a result of YOUR OWN SECURITY SETTINGS and not in the app. It works fine on about every pc out there, it's just Vista/outgoing firewalls that cause it to barf.This part of the config is in your own hands.

-The one button stuff is a bitch to implement, may happen some day if i have a lot of time, but won't happen soon I think.

[Yoma 0]

Gnat @ Nov. 24 2007,02:28)]Lovely work Yoma !!  

All worked fine on the OGN server except I got this error (see posted pic in thread)

http://forums.ogn.com.au/showthread.php?t=52055

Cheers.

Blablabla, file is in use by another process?

I think it's exactly what it says: file is in use by something else and cannot be accessed. May even be some slow antivirus that keeps it locked while scanning the zip.

Should not occur normally.

Another option is that you aborted a previous transfer by quitting the app. The download thread may then be floating somewhere on your os, keeping the file in use. I'm affraid all you could do then is reboot your system and retry.

Another theory would be that you clicked on COMPARE/Upload Create Packages WHILE it was downloading.

This would also barf download/packaging.

In short do it one at a time...

Some day i'll disable / reenable the buttons.

A final theory is that something went wrong when downloading one of the addons (connection probs etc).

Possibly the unzipper tries to access the file too early there.

The only solution then would be to retry.

[Yoma 0]

**New Version**

-Modserver admins can now put a password in modfolders.txt

(view settingstab, generate password for password string to put in modfolders txt)

-Users can save their password on a per server basis.

I will not go any further then this "security"-wise. I know it's not really secure at all, but it will keep normal users from downloading all your mods via the program.

[[aps]gnat 28]

Blablabla, file is in use by another process?

I think it's exactly what it says: file is in use by something else and cannot be accessed. May even be some slow antivirus that keeps it locked while scanning the zip.

Should not occur normally.

Another option is that you aborted a previous transfer by quitting the app. The download thread may then be floating somewhere on your os, keeping the file in use. I'm affraid all you could do then is reboot your system and retry.

Another theory would be that you clicked on COMPARE/Upload Create Packages WHILE it was downloading.

This would also barf download/packaging.

In short do it one at a time...

Some day i'll disable / reenable the buttons.

A final theory is that something went wrong when downloading one of the addons (connection probs etc).

Possibly the unzipper tries to access the file too early there.

The only solution then would be to retry.

Sorry, have to say not likely to all those theories, per the OGN thread I've tried it all sorts of ways, it actually errors 11% through downloading the zip file !!!!

No matter how many times I try it, this remaining file still errors.

Left it with Aussie to check that the zip file is not corrupt.

[Yoma 0]

**New Version**

-Added button "Download All Mods" for lazy people.

This downloads all missing/changed mods from a server automagically.

(yes i know you get a message box for each modfolder...)

(yes i know graphically it looks like shite)

[Yoma 0]

Gnat @ Nov. 24 2007,15:20)]

Blablabla, file is in use by another process?

I think it's exactly what it says: file is in use by something else and cannot be accessed. May even be some slow antivirus that keeps it locked while scanning the zip.

Should not occur normally.

Another option is that you aborted a previous transfer by quitting the app. The download thread may then be floating somewhere on your os, keeping the file in use. I'm affraid all you could do then is reboot your system and retry.

Another theory would be that you clicked on COMPARE/Upload Create Packages WHILE it was downloading.

This would also barf download/packaging.

In short do it one at a time...

Some day i'll disable / reenable the buttons.

A final theory is that something went wrong when downloading one of the addons (connection probs etc).

Possibly the unzipper tries to access the file too early there.

The only solution then would be to retry.

Sorry, have to say not likely to all those theories, per the OGN thread I've tried it all sorts of ways, it actually errors 11% through downloading the zip file !!!!

No matter how many times I try it, this remaining file still errors.

Left it with Aussie to check that the zip file is not corrupt.

Hmm tell me what file exactly it is.

(i just did some testing and got some errors on the MPmaps too, but after retry they were ok (these were obviously connection errors, which are normal (i connect from belgium to server on other side of wordl))

ack_dpd_units.pbo.zip: freshly downloaded here from OGN's server: the file IS NOT CORRUPT ON SERVER

By the way: the ZIPPING of the files just prevented you from having a CORRUPT addon file! The problem is not in the zips, the problem is in the downloads! (i suspect you have a bad connection to the server).

Unfortunately i'm having a hard time getting the filedownloader to RESUME downloads after broken connection, which could fix your problem

[Auss 208]

I have redownloaded all mod folders on 2 pc's Gnat I cannot replicate the problem here at my end.

[Yoma 0]

**New Version**

-Some buttons and stuff are now disabled while app is performing an operation (like downloading etc) to avoid people clicking on multiple buttons causing possible mayhem.

Gnat try this version. That said i'm still quite sure the problem you have is connection related. Do you have any other connection related problems on your pc? We used to have similar problem with a customer at work, where the problem was MTU on his firewall related. After downloading X Mb of data it would loose some packets barfing the connection.

After you get the message, if you look in the Zips folder, do you find the zipfile or not?

Are you testing with the latest version of the app?

[[aps]gnat 28]

Still the same problem with the update and I never have connection issues, BUT I found the issue.

I disabled the virus protection (Kaspersky) just before I started the download and it worked.

I believe the reason this is a problem for you is because you a building the ZIP file (in the temparary zip directory) as you download it. Hence, the AV sees a new ZIP file (half finished) and starts checking it.

I would normally expect that a downloading file would be cached or stored in memory UNTIL it has reached its final size and then and only then saved to the file system.

And I suspect it was only a problem for me on 1 and 2 files because of their size. Because they were large zip files the AV had a chance to see them and act on them before they were finished DL'ing.

You may need a slightly different method of downloading and storing the zip files as my AV setup is very standard.

One trick to avoid the issue could be to name the temporary zip file something like .tmp or .zzz until its finished downloading. Henc the AV should ignore it.

... still a very cool program so far Yoma !  

[Auss 208]

Perhaps it maybe easier to add the sites on yomas downloader as trusted sites, if your AV allows you to do that?

[[aps]gnat 28]

Perhaps it maybe easier to add the sites on yomas downloader as trusted sites, if your AV allows you to do that?

Read again Aus, it has nothing to do with trusted sites.

This is a conflict between 2 applications trying to access the same file at the same time.

The AV has no knowledge of the origin of the file, as far as its concerned its just a new zip file found in the file system. The problem arises when Yomas application goes back to the zip file to "add" more downloaded data.

Normally a new "opened" file shows as "0 bytes" until its finished, but I watched as Yomas application "grew" the zip file from zero right through to its ultimate size in MBs.

[Auss 208]

ah ok understand, had too many VB'S when i read your last post..lol

[Yoma 0]

Dumping the file to disk is a perfectly normal procedure.

Even IE does this, it downloads the file to a temporary location and then copies the file to the name/path you chose. (that's why it shows 0 bytes)

If you wouldn't do it like this you would be awfully limited in filesize for download now wouldn't you?

I'm glad to see that one of my initial guesses was correct.

The problem is that i can't do anything about it i think. The only thing i can think of is stuff like rename the file to something with a .tmp extension while downloading.

Maybe your AV gets some internal exceptions because it tries to scan the .zip file which obviously is corrupt while downloading. If that's the case using a tmp name might just do the trick. I think this could be done easily in my entire app.

There only is one big problem: it would require a full rename of all files on all servers that are using my app to .tmp instead of .zip :-)

I'll add it as a parameter to allow people to switch between zip/tmp extensions for now, just to check if that solves the problem.

Building a version as we speak.

You could then test it with aussie by renaming one of the bigger files to .tmp instead of .zip