Page 2 of 2

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 15:13
by RickHustle
I did uploaded pr-downloader to the host run it with parameters that you get and this is it! Now I'm sync when i enter at my host and [ACE] hosts too. YAHOO! Thanks for patience.

What conclusion we can do from this? There is the bug? pr-downloader download other data than file balanced_annihilation-v10.24.sdz or Spring using game from rapid and from file data in other ways. This trick as i wrote only with BA 10.xx Please investigate it with others.

If all game in future plans to downloading by repo - make changes in spads install docs and add pr-downloader to Spring version which spads automaticly downloads.

P.S. By my opnion rapid it's very incomfortable to using. It extract data to a lot of folders and impossible to check this data. Yes, it's supports resume downloading it's useful but disadvantages overlap advantages. I'm vote to remote it from project.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 17:38
by Silentwings
rapid ... extract data to a lot of folders and impossible to check this data ... Yes, it's supports resume downloading it's useful but disadvantages overlap advantages.
You misunderstand what rapid is for - its function is to support incremental downloading of (updates to) game versions. Some projects with large file size (750Mb+) require this for their stable releases. Every project requires this to make its per-commit testing versions available on the server, or else there would not be anywhere near enough disk space available on the file servers to store them all.

It is entirely possible to check the data; in fact (as you discovered) the lobby protocol requires that all clients do so every time they join a battle, regardless of whether they are locally storing the data in rapid archives or sdzs.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 17:56
by RickHustle
I'm understand about rapid but as you can see it works poor. Rapid is useful for developers with a lot of versions but is not so useful for users. Becouse they cannot to see what exactly games and versions they have. Cannot check their control sum, cannot delete something if they already don't need it.
Maybe it should be settings in SpringLobby - sync all via rapid or sync all via sdzs files. And all production versions should be testing exactly in sdzs format. Current bug wouldn't be happened if all before production checked only one main type of sync with easy checking (sdzs).

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 18:15
by Silentwings
RickHustle wrote:Rapid is useful for developers with a lot of versions but is not so useful for users
Wrong as said:
Silentwings wrote:Some projects with large file size (750Mb+) require this for their stable releases.
RickHustle wrote:Maybe it should be settings in SpringLobby - sync all via rapid or sync all via sdzs files
Users who picked "sync all via sdz" would quickly complain about excessive disk usage, especially SSD users. Also, as said, its impossible to "sync all against sdz files" for much the same reason:
Silentwings wrote:there would not be anywhere near enough disk space available on the file servers to store them all.
RickHustle wrote:Cannot check their control sum,
Wrong, its just more complicated than finding the md5 hash of a single file with some utility you downloaded.
And all production versions should be testing exactly in sdzs format.
http://repos.springrts.com/ba/builds/
Current bug wouldn't be happened if all before production checked only one main type of sync with easy checking (sdzs).
Complete rubbish. You don't even know the cause of your issue and can't eliminate your local setup.
What conclusion we can do from this? There is the bug? .... Please investigate it with others.
*You* should check if the sdz that you claimed was broken (and presumably got from SF) has the same md5 hash as the correct version of the file, which is on http://repos.springrts.com/ba/builds/. You should also compare it to a second download from SF.

Assuming the hashes match, there is nothing to fix. If they don't, post your results.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 18:36
by RickHustle
Silentwings wrote: 16 May 2019, 18:15 Already happens e.g. http://repos.springrts.com/ba/builds/
I downloaded this files then i did tested this issue - and it's don't help. files and rapid sync as you can see get seperate results. It's should not be happeds. It's should to give same results.
Silentwings wrote: 16 May 2019, 18:15 First thing to happen would be users who picked "sync all via sdz" complaining about excessive disk usage. Also, as said, its impossible for much the same reason:
If you worring about disk usage - solve situation that all Spring should to lay at drive C: under windows, that usually tiny SSD. If you install it into any other drive it will be download all files permanently to C:\Users\Rick\Documents\My Games\Spring\engine folders. It's don't disturb you?
I have 4Tb HDD and cannot use it for Spring, it always using tiny 120Gb SSD
Silentwings wrote: 16 May 2019, 18:15 Complete rubbish. You (and all others, since no one was able to reproduce your issue) don't even know what the cause was.
Forboding Angel detected roots of the bug. All hosts owners with BA 10.xx have it now. You can check cghislaiB host it have the same (except me and Fabs). You can install spads by yourself too by manual too. It's difficult to produce something if no one to try do this.

I checked 3-4 versions of 10.xx BA files.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 18:38
by Silentwings
It's should not be happeds. It's should to give same results.
This can be considered when you actually produce some info:
*You* should check if the sdz that you claimed was broken (and presumably got from SF) has the same md5 hash as the correct version of the file, which is on http://repos.springrts.com/ba/builds/. You should also compare it to a second download from SF.

Assuming the hashes match, there is nothing to fix. If they don't, post your results.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 18:47
by RickHustle
Silentwings wrote: 16 May 2019, 18:38
It's should not be happeds. It's should to give same results.
This can be considered when you actually produce some info:
*You* should check if the sdz that you claimed was broken (and presumably got from SF) has the same md5 hash as the correct version of the file, which is on http://repos.springrts.com/ba/builds/. You should also compare it to a second download from SF.

Assuming the hashes match, there is nothing to fix. If they don't, post your results.
How to get md5 hash of BA that i got via Rapid?

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 16 May 2019, 18:49
by Silentwings
You haven't been asked to do that, read more carefully.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 17 May 2019, 03:34
by Forboding Angel
RickHustle wrote: 16 May 2019, 18:36 Forboding Angel detected roots of the bug.
What I detected from the outset was that you are currently fairly incompetent when it comes to running a SPADS host and working with games and the engine in general. As a result I knew that your var dir was probably severely fucked up, which is why I had you delete everything in engines, so that I could have you verify step by step that the engine was correct then use rapid for grabbing the game because I trust rapid far more than I trust you to download something correctly. It's not a crime to be incompetent with these things, however, it is expected that you learn from your mistakes and get better. As bibim can attest, I too was very incompetent with SPADS at one point, whereas now I am quite good with SPADS for the most part.

However, you are taking that incompetence further in making suggestions without understanding the subject matter that you are referencing. This makes it very frustrating to help you, especially if you refuse to follow simple instructions. I understand that english is probably not your 1st language, so it's important to grant some leeway there, because it's a lot harder to learn any sort of technical terminology that is not expressed in your native language. So my overarching point here is that instead of telling the people who know what they are talking about how to use something that you don't really understand, you should listen to advice and, more importantly, ask questions. It doesn't matter if they are smart questions or dumb questions. Any question you ask whose answer gets you closer to learning or understanding a product, term or concept, is a question worth asking.

That said, people generally don't like repeating themselves, so it's a good idea to immediately point out if you do not understand an answer you are given, rather than ask the same question in 5 different ways, which will only serve to frustrate those who want to help you.

I'm glad you got it working, but there is something you need to understand...

This problem was caused by you and your lack of understanding what it is that you are doing. Do not blame others or spring's infrastructure for your own failings. Simply learn from them.

Edit: Also, this isn't a bug. This is spring's hashing working properly and as it was designed and preventing users from causing sync errors for other users.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 17 May 2019, 22:41
by RickHustle
Silentwings wrote: 16 May 2019, 18:38
It's should not be happeds. It's should to give same results.
This can be considered when you actually produce some info:
*You* should check if the sdz that you claimed was broken (and presumably got from SF) has the same md5 hash as the correct version of the file, which is on http://repos.springrts.com/ba/builds/. You should also compare it to a second download from SF.

Assuming the hashes match, there is nothing to fix. If they don't, post your results.
I didn't understand at first time that SF it's http://springfiles.com. I thought that it's Rapid.
What the sence to compare files from http://repos.springrts.com/ba/builds/ and http://springfiles.com? Yes i did it and yes they identical.
But it was ok with sdz files itself. It's could be actual to compare data downloaded by rapid with sdz.
Maybe pr-downloader download exactly BA 10.xx files with mistakes maybe SpringLobby interprets downloaded data with difference from sdz. So i wrote that it should be investigate.

I don't understand why you don't want to accept that it's obvious bug.

1) Sync it's only when spads and springlobby downloads BA 10.xx with same way. If different - unsync.
2) Spads have not pr-downloader from the box. It have instruction for installation https://springrts.com/wiki/SPADS:Installation and installation script spadsInstaller.pl that offers to put sdz file of the game in the games directory. There is no any words about pr-downloader and where i can get it.
3)
Forboding Angel wrote: 17 May 2019, 03:34 What I detected from the outset was that you are currently fairly incompetent when it comes to running a SPADS host and working with games and the engine in general.
I should not to know it well because i'm user. I should to follow the instructions which now do not lead to a working result.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 18 May 2019, 06:16
by Forboding Angel
RickHustle wrote: 17 May 2019, 22:41
Forboding Angel wrote: 17 May 2019, 03:34 What I detected from the outset was that you are currently fairly incompetent when it comes to running a SPADS host and working with games and the engine in general.
I should not to know it well because i'm user. I should to follow the instructions which now do not lead to a working result.
They do if you know what you're doing. Did you read any of the documentation? Spads Doc is very extensive.

Re: Spring v104.0.1+ BA10.24 unsync

Posted: 18 May 2019, 13:40
by RickHustle
Forboding Angel wrote: 18 May 2019, 06:16 They do if you know what you're doing. Did you read any of the documentation? Spads Doc is very extensive.
I suppose that i read it full.