[0.11.16] [cube] Progress bar will not display correct information

[SHiRKiT]

So, I've found a bug on progress bar status. I don't know what's the faulty part, but it seems that something is broken.

I have a map that the savegame is less than 11MB. In the picture below, I loaded the map, and 5 seconds after my friend connected to the game.
For some reason, the game is doing one of the two:
- Uploading a map that's bigger than 11MB (????)
- Progress bar shows incorrect values

Either way, it seems like a bug to me.

[logris]

I'm just guessing, but I bet the unzipped size of your map is around 16MB, and this is the format the game is uploading.
That would make sense, as that would be how the game has it in memory.
Although this suggests that some improvement could be made to the map uploading performance by uploading the zip version of it.

[SHiRKiT]

Not really, the uncompressed size is way, way bigger. Current compression is around 60%.

Although, if I may suggest a thing: if I unzip the random save, and 7z that save using LZMA, I get a 30-40% reduction. Although it adds some slowdown, I think it's worth to transmit the 7zipped version instead of a zip version.
It's open source under LGPL and the SDK is under the public domain, so you should be able to use it.

[Rseding91]

Also note the modified time on that save file is far different from the time your computer is showing which means a lot could have changed in the game since then.

[SHiRKiT]

That was the last time we played the map, I saved and then quit. Then, I just loaded that file and the joined. We don't play every day cause of work.

[slpwnd]

The number shows uploaded amount. That might be correctly bigger than the size of the map. For instance if there are multiple players connecting. Even if only one player connects it can still get bigger because of the way how we continuously stream the map. However that would suggest quite an inefficiency in our streaming algorithm (half the size extra is imho a lot). Some difference would be caused by packet loss as well.

[ssilk]

Why even bother the user with the exact amount? A progress indicator and the "about amount" should be enough.

[SHiRKiT]

Although, if I may suggest a thing: if I unzip the random save, and 7z that save using LZMA, I get a 30-40% reduction. Although it adds some slowdown, I think it's worth to transmit the 7zipped version instead of a zip version.
It's open source under LGPL and the SDK is under the public domain, so you should be able to use it.

I'd like to quote this again, since I really really think this is important. Another 40% free compression is something nice to have.

[slpwnd]

Although, if I may suggest a thing: if I unzip the random save, and 7z that save using LZMA, I get a 30-40% reduction. Although it adds some slowdown, I think it's worth to transmit the 7zipped version instead of a zip version.
It's open source under LGPL and the SDK is under the public domain, so you should be able to use it.

I'd like to quote this again, since I really really think this is important. Another 40% free compression is something nice to have.

It is a good idea but it is not for free because we use a dedicated library that only supports zip format. However we might look into using a 7z in the future.

[quinor]

I guess that .tar.lzma is as good as 7z and more popular in libraries, so I'd recommend that.

[SHiRKiT]

7z is just the format, the LZMA is the actual compression algorithm.

[quinor]

I know, but 7z is more likely to be windows-only format - I guess that we're talking about compression of data stream, so let's just say lzma algorithm.