Author Topic: Compressed Data transfer.  (Read 1773 times)

Well, I saw something that just sucks.

Just a few examples:

basic flatlands = 257 -> 8
bedroom = 321 -> 13
bedroom dark = 321 -> 13
dark flatlands = 257 -> 8
DM Torched = 257 -> 81
flatland classic v2 = 257 -> 1
green holes = 257 -> 30
kitchen = 385 -> 20
kitchen dark = 385 -> 20
office = 321 -> 14
plane valley = 578 -> 72
simple island = 257 -> 8
simple islandv2 = 257 -> 8
slopes = 578 -> 101
wizzislands = 579 -> 86

the terrain files got ~35 times smaller.
that means, 35 times less data to transfer.

and you can almost see the same effect when you try it with the dts (shapes).

You really should  give it a thought if you don't allow external sources (like giving adresses to the files at a http or ftp server).

Think about it Badspot ;D

So when you're downloading terrain/shapes/whatever, it gets compressed, sent to the client, then uncompresses itself?
Or maybe just the game can run files from inside a zip directory or something similar.

Anyway, why would you need this to download like 200kb files?

So when you're downloading terrain/shapes/whatever, it gets compressed, sent to the client, then uncompresses itself?
Or maybe just the game can run files from inside a zip directory or something similar.

Anyway, why would you need this to download like 200kb files?
It would uncompress itself on the client.

And about the 200kb files, well, sometimes it takes up to 30 seconds and more for a file that is that "big".
That just sucks. Even with my upload it should normaly just take about 5 seconds, and I'm not speaking about a maximum speed, I'm talking about a speed so the other clients won't get lags.

It would certaintly help with music files, and anything that has the possibility of cutting down loading times is worth looking into.

It would certaintly help with music files, and anything that has the possibility of cutting down loading times is worth looking into.
it won't be effective to compress music files, cause they are already compressed.

It's effective for the following file types:
 .blb (bricks)
 .dts (shapes)
 .wav (sounds)
 .dif (map difference files)
 .bls (save files)
 maybe .ml (??)

well, that seem to be all files where it's worth to compress them when they are transfered.

I don't really think it's worth the effort to design a way for this to work, who need to compress BLB or BLS files, they're text files, they're so small compressing them would just be plain silly. BLB files are probably only 7/8kb max, and BLS don't even get transferred to the client (Or do they?) they just get loaded from the server, or something (I'm not very familiar at all to how blockland saving works), but anyway, they're too small to worry about.

And you don't really download DTS or DIF files all that much, unless you're on a server that's testing a new map/mod.

It would certaintly help with music files, and anything that has the possibility of cutting down loading times is worth looking into.
it won't be effective to compress music files, cause they are already compressed.

It's effective for the following file types:
 .blb (bricks)
 .dts (shapes)
 .wav (sounds)
 .dif (map difference files)
 .bls (save files)
 maybe .ml (??)

well, that seem to be all files where it's worth to compress them when they are transfered.
.ml arent sent your comp makes one its a mission lighting file it just helps loading by taking outthe lighitng loading and map difference? its an interior lol

We've got a solution for this in the next RTB, just an FYI. :)

God... i want RTB so much D:

I don't really think it's worth the effort to design a way for this to work, who need to compress BLB or BLS files, they're text files, they're so small compressing them would just be plain silly. BLB files are probably only 7/8kb max, and BLS don't even get transferred to the client (Or do they?) they just get loaded from the server, or something (I'm not very familiar at all to how blockland saving works), but anyway, they're too small to worry about.

And you don't really download DTS or DIF files all that much, unless you're on a server that's testing a new map/mod.
okay, put away theese files, there are still the other files. And they are a bunch.
Well, DTS files are download much, sometimes up to 5 times (cause of ........ server admins that aren't able to install add-ons in a proper way)
And as the community is growing the servers will also grow.

We've got a solution for this in the next RTB, just an FYI. :)
Sounds good, let's see what coming :D

Badspot

  • Administrator
.dif stands for Dynamix Interior Format
text files are a prime candidates for compression because they're very inefficient

There might be problems on the server side of things.  You would have to either compress the files on-demand or have compressed versions of all of the files stored on the disk.  Having all of the add-ons and maps in their own zip archives on the web server and then redirecting downloads to that would probably be a better solution all around.

What would that mean to the host? Would the available bandwidth decrease if the host has to send a large quantity of files, which can be within a range of sizes? If the bandwidth requirements were to be compensated for, would this increase loading times?

Having all of the add-ons and maps in their own zip archives on the web server and then redirecting downloads to that would probably be a better solution all around.

Booya.

Having all of the add-ons and maps in their own zip archives on the web server and then redirecting downloads to that would probably be a better solution all around.

I think so too. External sources are the best way to loose the weight on the game servers.
This would be a perfect solution (and was already suggested by me :P)

Having all of the add-ons and maps in their own zip archives on the web server and then redirecting downloads to that would probably be a better solution all around.

Booya.
Sounds like Skull tag to me, VERY useful.