Hey everyone,
Currently, my server's custom maps are 3.3G in size. But they're just 975M with LZMA compression. So one has to wonder, why doesn't KF2 support compression?
I speak for redirect servers for the most part here, because telling everyone to go to Steam workshop, search for x map, and click subscribe, and potentially restart the game is irritating compared to just having to do... nothing but wait until the map downloads with a properly set up redirect server. Yes, I know TW deprecated this functionality for whatever reason. But as you'll see, it's also beneficial for Steam map downloads.
Let me explain, it really only has advantages:
1. It saves monthly transfer (and thus potentially reduces the bill) on the redirect server.
2. It also saves a lot of disk space on the server, which is often scarce with a VPS instance.
3. Most importantly, it saves a lot of map download time for players who don't have the map yet.
4. Requires CPU time on the client to decompress, but I can't imagine a rig capable of playing KF2 having a hard time decompressing a few dozen MB file. Compressing the Asgard map (260MB, one of the biggest maps) takes around 17 secs on my comp, decompressing is around 4 secs. The good news is, you only gotta compress once, and decompress several times Now compare these 4 seconds to the several minutes it takes for players with a bad internet sub to download a new map
5. Not only redirect servers, but Steam subscriptions would also benefit from it, because the Steam client downloads the very same .kfm file, except from Valve's CDN instead of a random redirect server. But the mechanism in the background is the same. While Valve's CDN has more bandwidth than your random redirect server, that won't help with people on slow internet. The bottleneck is the client, not the server for the 99%.
6. It doesn't even need to be a breaking change. Say we introduce a new .kfmz extension. New clients would try to download that file first. Not there? Okay, fall back to .kfm. Old client will try .kfm in the first place, you're good to go, both new and old will work just fine. In this case, if we want to maintain compatibility with old clients, you can ignore point 2 of course, coz it will actually increase disk usage on the server (you gotta offer both the .kfm and .kfmz files for download), but that's the smaller problem here imo. Waiting for minutes till everyone downloads the maps is a major PITA compared to a few more gigs on the server. It totally kills the momentum.
7. For whatever reason, KF2 has this habit of crashing if the map download takes too long. Happened to me, also got it reported from other players. After a few attempts it will eventually succeed (I assume it resumes the download instead of restarting from scratch), but it's still a pain, especially when the server becomes full while you're busy struggling with your crashes.
8. Implementing LZMA, or a comparable compression seems relatively easy to implement to me. In fact, we also did this with a mobile benchmark app we're developing, I was responsible for the server side.
9. There's several royalty-free, open source implementations you could go for, LZMA, xz, even Google released some new algo some time ago IIRC.
It really is a win-win for everyone involved. So Tripwire, please consider this. Consider us who love custom maps Think of the children, stop wasting internet bandwidth What do you guys think?
Currently, my server's custom maps are 3.3G in size. But they're just 975M with LZMA compression. So one has to wonder, why doesn't KF2 support compression?
I speak for redirect servers for the most part here, because telling everyone to go to Steam workshop, search for x map, and click subscribe, and potentially restart the game is irritating compared to just having to do... nothing but wait until the map downloads with a properly set up redirect server. Yes, I know TW deprecated this functionality for whatever reason. But as you'll see, it's also beneficial for Steam map downloads.
Let me explain, it really only has advantages:
1. It saves monthly transfer (and thus potentially reduces the bill) on the redirect server.
2. It also saves a lot of disk space on the server, which is often scarce with a VPS instance.
3. Most importantly, it saves a lot of map download time for players who don't have the map yet.
4. Requires CPU time on the client to decompress, but I can't imagine a rig capable of playing KF2 having a hard time decompressing a few dozen MB file. Compressing the Asgard map (260MB, one of the biggest maps) takes around 17 secs on my comp, decompressing is around 4 secs. The good news is, you only gotta compress once, and decompress several times Now compare these 4 seconds to the several minutes it takes for players with a bad internet sub to download a new map
5. Not only redirect servers, but Steam subscriptions would also benefit from it, because the Steam client downloads the very same .kfm file, except from Valve's CDN instead of a random redirect server. But the mechanism in the background is the same. While Valve's CDN has more bandwidth than your random redirect server, that won't help with people on slow internet. The bottleneck is the client, not the server for the 99%.
6. It doesn't even need to be a breaking change. Say we introduce a new .kfmz extension. New clients would try to download that file first. Not there? Okay, fall back to .kfm. Old client will try .kfm in the first place, you're good to go, both new and old will work just fine. In this case, if we want to maintain compatibility with old clients, you can ignore point 2 of course, coz it will actually increase disk usage on the server (you gotta offer both the .kfm and .kfmz files for download), but that's the smaller problem here imo. Waiting for minutes till everyone downloads the maps is a major PITA compared to a few more gigs on the server. It totally kills the momentum.
7. For whatever reason, KF2 has this habit of crashing if the map download takes too long. Happened to me, also got it reported from other players. After a few attempts it will eventually succeed (I assume it resumes the download instead of restarting from scratch), but it's still a pain, especially when the server becomes full while you're busy struggling with your crashes.
8. Implementing LZMA, or a comparable compression seems relatively easy to implement to me. In fact, we also did this with a mobile benchmark app we're developing, I was responsible for the server side.
9. There's several royalty-free, open source implementations you could go for, LZMA, xz, even Google released some new algo some time ago IIRC.
It really is a win-win for everyone involved. So Tripwire, please consider this. Consider us who love custom maps Think of the children, stop wasting internet bandwidth What do you guys think?