Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Claudio Beretta]

Mods _now_ add one path at the time, but they do it because it's the only
way they can do it :)
Mod authors will just have to make mods add an archive to the downloads
table instead of several files
The client downloads the archive and decompress all the files in it
the client also remembers the archive name, to not download it anymore

each model is composed by at least 7 model files + at least 2 material
files (player models may even come with 16 material files). Packing models
in a single archive will help a lot. Packing all the required files for a
mod such as "advanced weaponizer"  in an handful of archives would be great.


On Thu, Jan 26, 2012 at 1:05 AM, Ross Bemrose  wrote:

> From my understanding, mods add one path at a time to the downloads table,
> and the client has no idea that they're part of a larger package.
>  Therefore, it'd be impossible to aggregate files like this without
> completely overhauling how the downloads table works on the client and
> server.
>
>
> On 1/25/2012 3:32 PM, Claudio Beretta wrote:
>
>> A related request: allow multiple resource files to be packed in a single
>> (LZMA?) compressed archive.
>>
>>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Andre Müller]

On the same way you can update the bzip2 implementation to a newer version
which supports pbzip2.

http://compression.ca/pbzip2/

Here are some gaphs to compare compression ratio and compression time.
http://handyfloss.net/2009.07/plzma-py-a-wrapper-for-parallel-implementation-of-lzma-compression/
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Kyle Sanderson]

What we've done is just distribute map packs outside of the game.

The issue is well known in CS:S. I'm surprised it exists in TF2 as well,
and has gone this unnoticed. The error happens with/without compression
(contrary to what the thread you've linked states).
Kyle.

On Wed, Jan 25, 2012 at 6:34 PM, Russell Smith wrote:

> Improved compression features for custom downloads would be a welcome
> change.
>
> However, I would rather they first fix the custom download feature on the
> OS X fork before adding any of these suggestions.  Any time my server
> switches to custom maps my regular players using Macs are often unable to
> play because they get CRC errors from the download almost every time.  As
> far as I know this has been an issue since support for OS X was added and
> it has still yet to be addressed.
>
> The only solution is to ask them to go gamebanana or tf2maps and manually
> download/extract the file into the appropriate location.  This is a big
> inconvenience for them.
>
> Related thread on SPUF:
> http://forums.steampowered.**com/forums/showthread.php?t=**1303328
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Russell Smith]

Improved compression features for custom downloads would be a welcome 
change.


However, I would rather they first fix the custom download feature on 
the OS X fork before adding any of these suggestions.  Any time my 
server switches to custom maps my regular players using Macs are often 
unable to play because they get CRC errors from the download almost 
every time.  As far as I know this has been an issue since support for 
OS X was added and it has still yet to be addressed.


The only solution is to ask them to go gamebanana or tf2maps and 
manually download/extract the file into the appropriate location.  This 
is a big inconvenience for them.


Related thread on SPUF:
http://forums.steampowered.com/forums/showthread.php?t=1303328

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[doc]

I'm sure something like this is coming (a universal policy or sorts), but
TF2 is a perfect place to do their "testing". The game is free, the
userbase is large, and by now they are used to changes coming monthly.

On Wed, Jan 25, 2012 at 4:40 PM, James Puckett <
jamesrichardpuck...@gmail.com> wrote:

> If only this applied to other games, most notably Counter-strike 1.6 where
> the server list is full of fake servers all redirecting to Chinese servers
> etc.
>
> On Wed, Jan 25, 2012 at 4:23 PM, doc  wrote:
>
> > They have brought up the fact that they don't like servers who cheat the
> > system or provide unfun experiences to players. I know this was discussed
> > in brief (with a fun graph!) on the TF2 blog. This updated "Policy of
> > Truth" hasn't been posted anywhere but I would like to think it's kind
> of a
> > common sense deal.
> >
> > If you want to dupe players and provide incorrect data - then you
> probably
> > shouldn't worry about showing up on the server browser, you clearly don't
> > want to play by the rules anyways.
> >
> > So yes please post this somewhere public - but in saying that who cares,
> if
> > you are a server that gets removed (for legitimate reasons) then you had
> to
> > have been doing something "wrong" in the first place. I cannot see a case
> > where any actual (non cheating/misrepresenting) servers will be affected
> by
> > this.
> >
> > On Wed, Jan 25, 2012 at 3:31 PM, Robert Paulson  > >wrote:
> >
> > > You'll have to keep in mind that most of the people here are competing
> > > server owners, so they don't really care if anything is done properly
> > > as long as it doesn't affect them.
> > >
> > > More servers banned = less competition for them.
> > >
> > > On Wed, Jan 25, 2012 at 1:48 PM, Yuki  wrote:
> > > > Valid points, but I really don't see what the harm is in doing it
> > > anyway? If
> > > > you're going to announce it at all, why not do it properly?
> > > >
> > > >
> > > > On 25/01/2012 21:40, James Puckett wrote:
> > > >>
> > > >> Its their fault for abusing the games general populous into
> believing
> > > >> their
> > > >> joining a full server, when in reality they arent. This is a good
> set
> > of
> > > >> regulations.
> > > >> However announcing it won't catch everybody, its similar to people
> not
> > > >> reading EULA's, and people break them on a daily basis but nobody
> > > >> cares(especially valves retarded technology sanctioning on states
> > > labeled
> > > >> as evil by the US)
> > > >> ___
> > > >> To unsubscribe, edit your list preferences, or view the list
> archives,
> > > >> please visit:
> > > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > > >
> > > >
> > > >
> > > > ___
> > > > To unsubscribe, edit your list preferences, or view the list
> archives,
> > > > please visit:
> > > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[James Puckett]

If only this applied to other games, most notably Counter-strike 1.6 where
the server list is full of fake servers all redirecting to Chinese servers
etc.

On Wed, Jan 25, 2012 at 4:23 PM, doc  wrote:

> They have brought up the fact that they don't like servers who cheat the
> system or provide unfun experiences to players. I know this was discussed
> in brief (with a fun graph!) on the TF2 blog. This updated "Policy of
> Truth" hasn't been posted anywhere but I would like to think it's kind of a
> common sense deal.
>
> If you want to dupe players and provide incorrect data - then you probably
> shouldn't worry about showing up on the server browser, you clearly don't
> want to play by the rules anyways.
>
> So yes please post this somewhere public - but in saying that who cares, if
> you are a server that gets removed (for legitimate reasons) then you had to
> have been doing something "wrong" in the first place. I cannot see a case
> where any actual (non cheating/misrepresenting) servers will be affected by
> this.
>
> On Wed, Jan 25, 2012 at 3:31 PM, Robert Paulson  >wrote:
>
> > You'll have to keep in mind that most of the people here are competing
> > server owners, so they don't really care if anything is done properly
> > as long as it doesn't affect them.
> >
> > More servers banned = less competition for them.
> >
> > On Wed, Jan 25, 2012 at 1:48 PM, Yuki  wrote:
> > > Valid points, but I really don't see what the harm is in doing it
> > anyway? If
> > > you're going to announce it at all, why not do it properly?
> > >
> > >
> > > On 25/01/2012 21:40, James Puckett wrote:
> > >>
> > >> Its their fault for abusing the games general populous into believing
> > >> their
> > >> joining a full server, when in reality they arent. This is a good set
> of
> > >> regulations.
> > >> However announcing it won't catch everybody, its similar to people not
> > >> reading EULA's, and people break them on a daily basis but nobody
> > >> cares(especially valves retarded technology sanctioning on states
> > labeled
> > >> as evil by the US)
> > >> ___
> > >> To unsubscribe, edit your list preferences, or view the list archives,
> > >> please visit:
> > >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> > >
> > >
> > >
> > > ___
> > > To unsubscribe, edit your list preferences, or view the list archives,
> > > please visit:
> > > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[doc]

They have brought up the fact that they don't like servers who cheat the
system or provide unfun experiences to players. I know this was discussed
in brief (with a fun graph!) on the TF2 blog. This updated "Policy of
Truth" hasn't been posted anywhere but I would like to think it's kind of a
common sense deal.

If you want to dupe players and provide incorrect data - then you probably
shouldn't worry about showing up on the server browser, you clearly don't
want to play by the rules anyways.

So yes please post this somewhere public - but in saying that who cares, if
you are a server that gets removed (for legitimate reasons) then you had to
have been doing something "wrong" in the first place. I cannot see a case
where any actual (non cheating/misrepresenting) servers will be affected by
this.

On Wed, Jan 25, 2012 at 3:31 PM, Robert Paulson wrote:

> You'll have to keep in mind that most of the people here are competing
> server owners, so they don't really care if anything is done properly
> as long as it doesn't affect them.
>
> More servers banned = less competition for them.
>
> On Wed, Jan 25, 2012 at 1:48 PM, Yuki  wrote:
> > Valid points, but I really don't see what the harm is in doing it
> anyway? If
> > you're going to announce it at all, why not do it properly?
> >
> >
> > On 25/01/2012 21:40, James Puckett wrote:
> >>
> >> Its their fault for abusing the games general populous into believing
> >> their
> >> joining a full server, when in reality they arent. This is a good set of
> >> regulations.
> >> However announcing it won't catch everybody, its similar to people not
> >> reading EULA's, and people break them on a daily basis but nobody
> >> cares(especially valves retarded technology sanctioning on states
> labeled
> >> as evil by the US)
> >> ___
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
> >
> >
> >
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Adam Nowacki]

Client could use http pipelining, it is widely supported by web servers. 
It works by issuing multiple http requests over a single connection 
without waiting for the replies. Server can then send data without any 
breaks effectively eliminating all round-trip issues.

ref: http://en.wikipedia.org/wiki/HTTP_pipelining

On 2012-01-26 01:05, Ross Bemrose wrote:

 From my understanding, mods add one path at a time to the downloads
table, and the client has no idea that they're part of a larger package.
Therefore, it'd be impossible to aggregate files like this without
completely overhauling how the downloads table works on the client and
server.

On 1/25/2012 3:32 PM, Claudio Beretta wrote:

A related request: allow multiple resource files to be packed in a single
(LZMA?) compressed archive.



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Ross Bemrose]

From my understanding, mods add one path at a time to the downloads 
table, and the client has no idea that they're part of a larger 
package.  Therefore, it'd be impossible to aggregate files like this 
without completely overhauling how the downloads table works on the 
client and server.


On 1/25/2012 3:32 PM, Claudio Beretta wrote:

A related request: allow multiple resource files to be packed in a single
(LZMA?) compressed archive.




___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Ross Bemrose]

Then you run into the problem of "how does it determine which maps is next?"

In most Source games, it's the next map in the mapcycle.  In TF2, it's 
the value of the nextmap cvar if set and voting is enabled, or the next 
map in the mapcycle if it isn't.


SourceMod can override the next map in all games its supports.

On 1/25/2012 4:15 PM, lwf wrote:

A similarly similar request, although this is already getting a bit
deeper than just adding support for better compression; it would be
great if custom content needed for the next map (in most or all cases
that would be map itself) could be downloaded at a slow rate in the
background, much like how the replay system does.

That way the time waiting could be further reduced to nothing at all
or at least being shorten if the download doesn't get enough time to
complete.

On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
  wrote:

A related request: allow multiple resource files to be packed in a single
(LZMA?) compressed archive.

Modded servers may require several files to be downloaded by new players,
especially if non stock models are used. These files may be small in size
but there are a lot of them, so the round trip time is the biggest factor
slowing the transfer.
Adding support for archives with better compression will improve the user
experience, and make admins happier too (the stats for my fastdownload site
report ~55GB of transferred files and 200K hits every day, 70GB and 250K
hits on saturday/sunday)


On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowackiwrote:


As of now custom content (custom maps mostly) on the server can be
compressed with bzip2 to reduce the time clients have to wait on the
loading screen. While the compression ratio of bzip2 is already quite good
there is a far better alternative: LZMA (see http://en.wikipedia.org/wiki/
**LZMA). Decompression code is very
simple, small and free/open-source libraries are available.

Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3 times
larger than LZMA compressed ones:
1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)

__**_
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Yeef]

I second this. At the very least, add in the hooks so that modders can make
this a reality. I don't know too much about what goes on behind the scenes,
but I'd think, given that the replay system already allows for client
downloads during play, it would be relatively simple to implement the same
feature for custom content.

The fewer hurdles there are to getting people to play custom maps, the
better, in my opinion.

On Wed, Jan 25, 2012 at 4:15 PM, lwf  wrote:

> A similarly similar request, although this is already getting a bit
> deeper than just adding support for better compression; it would be
> great if custom content needed for the next map (in most or all cases
> that would be map itself) could be downloaded at a slow rate in the
> background, much like how the replay system does.
>
> That way the time waiting could be further reduced to nothing at all
> or at least being shorten if the download doesn't get enough time to
> complete.
>
> On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
>  wrote:
> > A related request: allow multiple resource files to be packed in a single
> > (LZMA?) compressed archive.
> >
> > Modded servers may require several files to be downloaded by new players,
> > especially if non stock models are used. These files may be small in size
> > but there are a lot of them, so the round trip time is the biggest factor
> > slowing the transfer.
> > Adding support for archives with better compression will improve the user
> > experience, and make admins happier too (the stats for my fastdownload
> site
> > report ~55GB of transferred files and 200K hits every day, 70GB and 250K
> > hits on saturday/sunday)
> >
> >
> > On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki  >wrote:
> >
> >> As of now custom content (custom maps mostly) on the server can be
> >> compressed with bzip2 to reduce the time clients have to wait on the
> >> loading screen. While the compression ratio of bzip2 is already quite
> good
> >> there is a far better alternative: LZMA (see
> http://en.wikipedia.org/wiki/
> >> **LZMA ). Decompression code is very
> >> simple, small and free/open-source libraries are available.
> >>
> >> Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
> >> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3
> times
> >> larger than LZMA compressed ones:
> >> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> >> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> >> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> >> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> >> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> >> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> >> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> >> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> >> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> >> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> >> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> >> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> >> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> >> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> >> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> >> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> >> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> >> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> >> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> >> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> >> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> >> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> >> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> >> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> >> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
> >>
> >> __**_
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >>
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Kyle Sanderson]

LZMA2 (xz is pretty easy to embed) or lrzip would be preferable. Maps are
getting larger and larger. I know we have 87 maps that are over 80mB, 24 of
which are over 120mB. I was wondering why we were hurting for space on our
SSD.

Also, if we could get something similar to the HL1 loading screen (Shows
progress for individual files and Overall), that would be superb.
Kyle.

On Wed, Jan 25, 2012 at 3:12 PM, Eli Witt  wrote:

> True that.
>
> I can watch people start downloading files off my FastDownload server and
> complete them in times given only by the gigabit line it's on, and then
> have the clients take 3x longer to decompress it and connect than it took
> to download it in the first place.
>
> Perhaps a more verbose download screen in-game while we're at it... the
> current one is so un-informative a-la Steam client day 1 patch progress
> screen that I know it seems to a lot of people that it's locked up because
> the bar moved so fast through the download phase, now it's stuck on in the
> decompressing stage and they don't have the savvy to realize that. Then
> think about all the users who don't have at least a quad core.
>
> On Wed, Jan 25, 2012 at 4:52 PM, Bruno Garcia  >wrote:
>
> > I second this request, and I add, bzip2 is known to be difficult in CPU
> > usage to decompress.
> > Perhaps alternative methods doesn't sound bad at all.
> >
> > On Wed, Jan 25, 2012 at 6:15 PM, lwf  wrote:
> >
> > > A similarly similar request, although this is already getting a bit
> > > deeper than just adding support for better compression; it would be
> > > great if custom content needed for the next map (in most or all cases
> > > that would be map itself) could be downloaded at a slow rate in the
> > > background, much like how the replay system does.
> > >
> > > That way the time waiting could be further reduced to nothing at all
> > > or at least being shorten if the download doesn't get enough time to
> > > complete.
> > >
> > > On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
> > >  wrote:
> > > > A related request: allow multiple resource files to be packed in a
> > single
> > > > (LZMA?) compressed archive.
> > > >
> > > > Modded servers may require several files to be downloaded by new
> > players,
> > > > especially if non stock models are used. These files may be small in
> > size
> > > > but there are a lot of them, so the round trip time is the biggest
> > factor
> > > > slowing the transfer.
> > > > Adding support for archives with better compression will improve the
> > user
> > > > experience, and make admins happier too (the stats for my
> fastdownload
> > > site
> > > > report ~55GB of transferred files and 200K hits every day, 70GB and
> > 250K
> > > > hits on saturday/sunday)
> > > >
> > > >
> > > > On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki <
> > nowa...@platinum.linux.pl
> > > >wrote:
> > > >
> > > >> As of now custom content (custom maps mostly) on the server can be
> > > >> compressed with bzip2 to reduce the time clients have to wait on the
> > > >> loading screen. While the compression ratio of bzip2 is already
> quite
> > > good
> > > >> there is a far better alternative: LZMA (see
> > > http://en.wikipedia.org/wiki/
> > > >> **LZMA ). Decompression code is
> > very
> > > >> simple, small and free/open-source libraries are available.
> > > >>
> > > >> Below is a comparison of bzip2 and LZMA for the custom maps hosted
> on
> > my
> > > >> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3
> > > times
> > > >> larger than LZMA compressed ones:
> > > >> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> > > >> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> > > >> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> > > >> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> > > >> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> > > >> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> > > >> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> > > >> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> > > >> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> > > >> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> > > >> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> > > >> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> > > >> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> > > >> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> > > >> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> > > >> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> > > >> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> > > >> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> > > >> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> > > >> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> > > >> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> > > >> 1.3x pl_problematique_a3.bsp (

Re: [hlds_linux] The policy of truth is still in effect

[Robert Paulson]

You'll have to keep in mind that most of the people here are competing
server owners, so they don't really care if anything is done properly
as long as it doesn't affect them.

More servers banned = less competition for them.

On Wed, Jan 25, 2012 at 1:48 PM, Yuki  wrote:
> Valid points, but I really don't see what the harm is in doing it anyway? If
> you're going to announce it at all, why not do it properly?
>
>
> On 25/01/2012 21:40, James Puckett wrote:
>>
>> Its their fault for abusing the games general populous into believing
>> their
>> joining a full server, when in reality they arent. This is a good set of
>> regulations.
>> However announcing it won't catch everybody, its similar to people not
>> reading EULA's, and people break them on a daily basis but nobody
>> cares(especially valves retarded technology sanctioning on states labeled
>> as evil by the US)
>> ___
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
>
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Eli Witt]

True that.

I can watch people start downloading files off my FastDownload server and
complete them in times given only by the gigabit line it's on, and then
have the clients take 3x longer to decompress it and connect than it took
to download it in the first place.

Perhaps a more verbose download screen in-game while we're at it... the
current one is so un-informative a-la Steam client day 1 patch progress
screen that I know it seems to a lot of people that it's locked up because
the bar moved so fast through the download phase, now it's stuck on in the
decompressing stage and they don't have the savvy to realize that. Then
think about all the users who don't have at least a quad core.

On Wed, Jan 25, 2012 at 4:52 PM, Bruno Garcia wrote:

> I second this request, and I add, bzip2 is known to be difficult in CPU
> usage to decompress.
> Perhaps alternative methods doesn't sound bad at all.
>
> On Wed, Jan 25, 2012 at 6:15 PM, lwf  wrote:
>
> > A similarly similar request, although this is already getting a bit
> > deeper than just adding support for better compression; it would be
> > great if custom content needed for the next map (in most or all cases
> > that would be map itself) could be downloaded at a slow rate in the
> > background, much like how the replay system does.
> >
> > That way the time waiting could be further reduced to nothing at all
> > or at least being shorten if the download doesn't get enough time to
> > complete.
> >
> > On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
> >  wrote:
> > > A related request: allow multiple resource files to be packed in a
> single
> > > (LZMA?) compressed archive.
> > >
> > > Modded servers may require several files to be downloaded by new
> players,
> > > especially if non stock models are used. These files may be small in
> size
> > > but there are a lot of them, so the round trip time is the biggest
> factor
> > > slowing the transfer.
> > > Adding support for archives with better compression will improve the
> user
> > > experience, and make admins happier too (the stats for my fastdownload
> > site
> > > report ~55GB of transferred files and 200K hits every day, 70GB and
> 250K
> > > hits on saturday/sunday)
> > >
> > >
> > > On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki <
> nowa...@platinum.linux.pl
> > >wrote:
> > >
> > >> As of now custom content (custom maps mostly) on the server can be
> > >> compressed with bzip2 to reduce the time clients have to wait on the
> > >> loading screen. While the compression ratio of bzip2 is already quite
> > good
> > >> there is a far better alternative: LZMA (see
> > http://en.wikipedia.org/wiki/
> > >> **LZMA ). Decompression code is
> very
> > >> simple, small and free/open-source libraries are available.
> > >>
> > >> Below is a comparison of bzip2 and LZMA for the custom maps hosted on
> my
> > >> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3
> > times
> > >> larger than LZMA compressed ones:
> > >> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> > >> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> > >> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> > >> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> > >> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> > >> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> > >> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> > >> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> > >> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> > >> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> > >> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> > >> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> > >> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> > >> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> > >> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> > >> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> > >> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> > >> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> > >> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> > >> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> > >> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> > >> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> > >> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> > >> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> > >> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
> > >>
> > >> __**_
> > >> To unsubscribe, edit your list preferences, or view the list archives,
> > >> please visit:
> > >> https://list.valvesoftware.
> **com/cgi-bin/mailman/listinfo/**hlds_linux<
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> > >>
> > > ___
> > > To unsubscribe, edit 

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[px]

Здравствуйте, Andre.

Вы писали 26 січня 2012 р., 0:46:45:

> 2012/1/25 Claudio Beretta 

>> A related request: allow multiple resource files to be packed in a single
>> (LZMA?) compressed archive.
>>
>> Modded servers may require several files to be downloaded by new players,
>> especially if non stock models are used. These files may be small in size
>> but there are a lot of them, so the round trip time is the biggest factor
>> slowing the transfer.
>> Adding support for archives with better compression will improve the user
>> experience, and make admins happier too (the stats for my fastdownload site
>> report ~55GB of transferred files and 200K hits every day, 70GB and 250K
>> hits on saturday/sunday)
>>
>>
>> Nope, this is not a good idea. Lzma can only compress single files. Maybe
> you can use tar or 7zip.
> The best was is to realize same thing like with bzip2 but be compatible.

> First the client is trying to download the compressed ressource as bzip2,
> then lzma and last uncompressed. So you can choose between 3 formats and
> can mix it like you want.

7zip uses lzma/lzma2


-- 
С уважением,
 px  mailto:p...@i.kiev.ua


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Andre Müller]

2012/1/25 Claudio Beretta 

> A related request: allow multiple resource files to be packed in a single
> (LZMA?) compressed archive.
>
> Modded servers may require several files to be downloaded by new players,
> especially if non stock models are used. These files may be small in size
> but there are a lot of them, so the round trip time is the biggest factor
> slowing the transfer.
> Adding support for archives with better compression will improve the user
> experience, and make admins happier too (the stats for my fastdownload site
> report ~55GB of transferred files and 200K hits every day, 70GB and 250K
> hits on saturday/sunday)
>
>
> Nope, this is not a good idea. Lzma can only compress single files. Maybe
you can use tar or 7zip.
The best was is to realize same thing like with bzip2 but be compatible.

First the client is trying to download the compressed ressource as bzip2,
then lzma and last uncompressed. So you can choose between 3 formats and
can mix it like you want.
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[E3pO]

I support this!
On Jan 25, 2012 5:14 PM, "James Puckett" 
wrote:

> Support this
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[James Puckett]

Support this
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Bruno Garcia]

I second this request, and I add, bzip2 is known to be difficult in CPU
usage to decompress.
Perhaps alternative methods doesn't sound bad at all.

On Wed, Jan 25, 2012 at 6:15 PM, lwf  wrote:

> A similarly similar request, although this is already getting a bit
> deeper than just adding support for better compression; it would be
> great if custom content needed for the next map (in most or all cases
> that would be map itself) could be downloaded at a slow rate in the
> background, much like how the replay system does.
>
> That way the time waiting could be further reduced to nothing at all
> or at least being shorten if the download doesn't get enough time to
> complete.
>
> On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
>  wrote:
> > A related request: allow multiple resource files to be packed in a single
> > (LZMA?) compressed archive.
> >
> > Modded servers may require several files to be downloaded by new players,
> > especially if non stock models are used. These files may be small in size
> > but there are a lot of them, so the round trip time is the biggest factor
> > slowing the transfer.
> > Adding support for archives with better compression will improve the user
> > experience, and make admins happier too (the stats for my fastdownload
> site
> > report ~55GB of transferred files and 200K hits every day, 70GB and 250K
> > hits on saturday/sunday)
> >
> >
> > On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki  >wrote:
> >
> >> As of now custom content (custom maps mostly) on the server can be
> >> compressed with bzip2 to reduce the time clients have to wait on the
> >> loading screen. While the compression ratio of bzip2 is already quite
> good
> >> there is a far better alternative: LZMA (see
> http://en.wikipedia.org/wiki/
> >> **LZMA ). Decompression code is very
> >> simple, small and free/open-source libraries are available.
> >>
> >> Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
> >> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3
> times
> >> larger than LZMA compressed ones:
> >> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> >> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> >> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> >> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> >> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> >> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> >> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> >> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> >> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> >> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> >> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> >> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> >> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> >> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> >> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> >> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> >> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> >> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> >> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> >> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> >> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> >> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> >> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> >> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> >> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
> >>
> >> __**_
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >>
> > ___
> > To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Yuki]

Valid points, but I really don't see what the harm is in doing it 
anyway? If you're going to announce it at all, why not do it properly?


On 25/01/2012 21:40, James Puckett wrote:

Its their fault for abusing the games general populous into believing their
joining a full server, when in reality they arent. This is a good set of
regulations.
However announcing it won't catch everybody, its similar to people not
reading EULA's, and people break them on a daily basis but nobody
cares(especially valves retarded technology sanctioning on states labeled
as evil by the US)
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[James Puckett]

Its their fault for abusing the games general populous into believing their
joining a full server, when in reality they arent. This is a good set of
regulations.
However announcing it won't catch everybody, its similar to people not
reading EULA's, and people break them on a daily basis but nobody
cares(especially valves retarded technology sanctioning on states labeled
as evil by the US)
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Yuki]

That's not the point. Whether you read it or not, you agree to it. I 
don't get what the harm is in adding it somewhere. I'm sure it'll save 
Valve some problems in the future.


On 25/01/2012 21:20, Eric Riemers wrote:

I am pretty sure that if you are a normal server operator that you have no
issues. If you are fooling people with plugins then you already know your
crossing the line.

And informing all server operators is like asking people to "read and agree
to the terms of use" which nobody reads ;p

-Original Message-
From: hlds_linux-boun...@list.valvesoftware.com
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Yuki
Sent: woensdag 25 januari 2012 22:04
To: Half-Life dedicated Linux server mailing list
Subject: Re: [hlds_linux] The policy of truth is still in effect

If Valve had this attitude, where would they be now?
It's Valve's duty to inform *ALL* server owners what they can and can't do.
It's almost like VAC banning people without even explaining what VAC is.

On 25/01/2012 20:18, Andre Müller wrote:

Thier problem, not our problem!

2012/1/25 Yuki


Will this ever be officially stated outside of the mailing list? I'm
sure there's a few server owners out there that don't follow the list
and could be punished for simply not knowing.


On 24/01/2012 20:08, Fletcher Dunn wrote:


Yesterday the Team Fortress team took further action pursuant to the
"policy of truth" that was announced in December of last year.  We
delisted some servers that were reporting inaccurate information in
server-browser-related communications.

Our goals are for players to be able to find the server they are
looking for quickly and easily, and for server operators to compete
solely on the basis of the quality of the experience they provide.
Any plugins that modify server browser communications (or modify the
information contained in those packets) are counter to those goals.

The following guidelines are self-evident:

* All of the data you report to clients and to Steam must be
accurate.

* You must use the Source engine, using the steam libraries, to
send all server-browser-related communications.

* Do not modify or manually send any packets to Steam.

* Do not modify or manually send any client ping replies.

(Those

that convey server browser info, player counts, etc.)

* Do not to set any values that are sent in these communications
outside the legal range.

* The data reported to the master server and to clients must
match.


If you aren't running any plugins that do any of these sorts of
things, you can disregard this post.  If you are, please stop.  If
you feel that you have a real reason to make these modifications to
your server, then communicate with us and help us understand!  We'll
try to work out a solution that fits everybody's needs.

Thanks,
The Team Fortress Team

__**_
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_lin
ux


__**_
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linu
x


___
To unsubscribe, edit your list preferences, or view the list archives,

please visit:

https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Eric Riemers]

I am pretty sure that if you are a normal server operator that you have no
issues. If you are fooling people with plugins then you already know your
crossing the line.

And informing all server operators is like asking people to "read and agree
to the terms of use" which nobody reads ;p
 
-Original Message-
From: hlds_linux-boun...@list.valvesoftware.com
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Yuki
Sent: woensdag 25 januari 2012 22:04
To: Half-Life dedicated Linux server mailing list
Subject: Re: [hlds_linux] The policy of truth is still in effect

If Valve had this attitude, where would they be now?
It's Valve's duty to inform *ALL* server owners what they can and can't do.
It's almost like VAC banning people without even explaining what VAC is.

On 25/01/2012 20:18, Andre Müller wrote:
> Thier problem, not our problem!
>
> 2012/1/25 Yuki
>
>> Will this ever be officially stated outside of the mailing list? I'm 
>> sure there's a few server owners out there that don't follow the list 
>> and could be punished for simply not knowing.
>>
>>
>> On 24/01/2012 20:08, Fletcher Dunn wrote:
>>
>>> Yesterday the Team Fortress team took further action pursuant to the 
>>> "policy of truth" that was announced in December of last year.  We 
>>> delisted some servers that were reporting inaccurate information in 
>>> server-browser-related communications.
>>>
>>> Our goals are for players to be able to find the server they are 
>>> looking for quickly and easily, and for server operators to compete 
>>> solely on the basis of the quality of the experience they provide.  
>>> Any plugins that modify server browser communications (or modify the 
>>> information contained in those packets) are counter to those goals.
>>>
>>> The following guidelines are self-evident:
>>>
>>> * All of the data you report to clients and to Steam must be
>>> accurate.
>>>
>>> * You must use the Source engine, using the steam libraries, to
>>> send all server-browser-related communications.
>>>
>>> * Do not modify or manually send any packets to Steam.
>>>
>>> * Do not modify or manually send any client ping replies.
(Those
>>> that convey server browser info, player counts, etc.)
>>>
>>> * Do not to set any values that are sent in these communications
>>> outside the legal range.
>>>
>>> * The data reported to the master server and to clients must
>>> match.
>>>
>>>
>>> If you aren't running any plugins that do any of these sorts of 
>>> things, you can disregard this post.  If you are, please stop.  If 
>>> you feel that you have a real reason to make these modifications to 
>>> your server, then communicate with us and help us understand!  We'll 
>>> try to work out a solution that fits everybody's needs.
>>>
>>> Thanks,
>>> The Team Fortress Team
>>>
>>> __**_
>>> To unsubscribe, edit your list preferences, or view the list 
>>> archives, please visit:
>>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_lin
>>> ux>> x>
>>>
>>
>> __**_
>> To unsubscribe, edit your list preferences, or view the list 
>> archives, please visit:
>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linu
>> x
>>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[lwf]

A similarly similar request, although this is already getting a bit
deeper than just adding support for better compression; it would be
great if custom content needed for the next map (in most or all cases
that would be map itself) could be downloaded at a slow rate in the
background, much like how the replay system does.

That way the time waiting could be further reduced to nothing at all
or at least being shorten if the download doesn't get enough time to
complete.

On Wed, Jan 25, 2012 at 21:32, Claudio Beretta
 wrote:
> A related request: allow multiple resource files to be packed in a single
> (LZMA?) compressed archive.
>
> Modded servers may require several files to be downloaded by new players,
> especially if non stock models are used. These files may be small in size
> but there are a lot of them, so the round trip time is the biggest factor
> slowing the transfer.
> Adding support for archives with better compression will improve the user
> experience, and make admins happier too (the stats for my fastdownload site
> report ~55GB of transferred files and 200K hits every day, 70GB and 250K
> hits on saturday/sunday)
>
>
> On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki 
> wrote:
>
>> As of now custom content (custom maps mostly) on the server can be
>> compressed with bzip2 to reduce the time clients have to wait on the
>> loading screen. While the compression ratio of bzip2 is already quite good
>> there is a far better alternative: LZMA (see http://en.wikipedia.org/wiki/
>> **LZMA ). Decompression code is very
>> simple, small and free/open-source libraries are available.
>>
>> Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
>> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3 times
>> larger than LZMA compressed ones:
>> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
>> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
>> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
>> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
>> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
>> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
>> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
>> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
>> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
>> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
>> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
>> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
>> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
>> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
>> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
>> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
>> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
>> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
>> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
>> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
>> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
>> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
>> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
>> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
>> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
>>
>> __**_
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>>
> ___
> To unsubscribe, edit your list preferences, or view the list archives, please 
> visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Aaron, M]

I second the request of LZMA compression support.

On Wed, Jan 25, 2012 at 2:32 PM, Claudio Beretta
wrote:

> A related request: allow multiple resource files to be packed in a single
> (LZMA?) compressed archive.
>
> Modded servers may require several files to be downloaded by new players,
> especially if non stock models are used. These files may be small in size
> but there are a lot of them, so the round trip time is the biggest factor
> slowing the transfer.
> Adding support for archives with better compression will improve the user
> experience, and make admins happier too (the stats for my fastdownload site
> report ~55GB of transferred files and 200K hits every day, 70GB and 250K
> hits on saturday/sunday)
>
>
> On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki  >wrote:
>
> > As of now custom content (custom maps mostly) on the server can be
> > compressed with bzip2 to reduce the time clients have to wait on the
> > loading screen. While the compression ratio of bzip2 is already quite
> good
> > there is a far better alternative: LZMA (see
> http://en.wikipedia.org/wiki/
> > **LZMA ). Decompression code is very
> > simple, small and free/open-source libraries are available.
> >
> > Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
> > server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3
> times
> > larger than LZMA compressed ones:
> > 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> > 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> > 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> > 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> > 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> > 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> > 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> > 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> > 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> > 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> > 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> > 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> > 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> > 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> > 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> > 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> > 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> > 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> > 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> > 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> > 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> > 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> > 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> > 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> > 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Yuki]

If Valve had this attitude, where would they be now?
It's Valve's duty to inform *ALL* server owners what they can and can't 
do. It's almost like VAC banning people without even explaining what VAC is.


On 25/01/2012 20:18, Andre Müller wrote:

Thier problem, not our problem!

2012/1/25 Yuki


Will this ever be officially stated outside of the mailing list? I'm sure
there's a few server owners out there that don't follow the list and could
be punished for simply not knowing.


On 24/01/2012 20:08, Fletcher Dunn wrote:


Yesterday the Team Fortress team took further action pursuant to the
"policy of truth" that was announced in December of last year.  We delisted
some servers that were reporting inaccurate information in
server-browser-related communications.

Our goals are for players to be able to find the server they are looking
for quickly and easily, and for server operators to compete solely on the
basis of the quality of the experience they provide.  Any plugins that
modify server browser communications (or modify the information contained
in those packets) are counter to those goals.

The following guidelines are self-evident:

* All of the data you report to clients and to Steam must be
accurate.

* You must use the Source engine, using the steam libraries, to
send all server-browser-related communications.

* Do not modify or manually send any packets to Steam.

* Do not modify or manually send any client ping replies.  (Those
that convey server browser info, player counts, etc.)

* Do not to set any values that are sent in these communications
outside the legal range.

* The data reported to the master server and to clients must
match.


If you aren't running any plugins that do any of these sorts of things,
you can disregard this post.  If you are, please stop.  If you feel that
you have a real reason to make these modifications to your server, then
communicate with us and help us understand!  We'll try to work out a
solution that fits everybody's needs.

Thanks,
The Team Fortress Team

__**_
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux



__**_
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux


___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Kaspars]

I haven't followed the list lately (and I don't know if the following 
issue is fixed), however I have a question - does this mean we cannot 
use query caching plugins any more to prevent ddos attacks?


On 2012.01.24. 22:08, Fletcher Dunn wrote:

Yesterday the Team Fortress team took further action pursuant to the "policy of 
truth" that was announced in December of last year.  We delisted some servers that 
were reporting inaccurate information in server-browser-related communications.

Our goals are for players to be able to find the server they are looking for 
quickly and easily, and for server operators to compete solely on the basis of 
the quality of the experience they provide.  Any plugins that modify server 
browser communications (or modify the information contained in those packets) 
are counter to those goals.

The following guidelines are self-evident:

* All of the data you report to clients and to Steam must be accurate.

* You must use the Source engine, using the steam libraries, to send 
all server-browser-related communications.

* Do not modify or manually send any packets to Steam.

* Do not modify or manually send any client ping replies.  (Those that 
convey server browser info, player counts, etc.)

* Do not to set any values that are sent in these communications 
outside the legal range.

* The data reported to the master server and to clients must match.

If you aren't running any plugins that do any of these sorts of things, you can 
disregard this post.  If you are, please stop.  If you feel that you have a 
real reason to make these modifications to your server, then communicate with 
us and help us understand!  We'll try to work out a solution that fits 
everybody's needs.

Thanks,
The Team Fortress Team

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Claudio Beretta]

A related request: allow multiple resource files to be packed in a single
(LZMA?) compressed archive.

Modded servers may require several files to be downloaded by new players,
especially if non stock models are used. These files may be small in size
but there are a lot of them, so the round trip time is the biggest factor
slowing the transfer.
Adding support for archives with better compression will improve the user
experience, and make admins happier too (the stats for my fastdownload site
report ~55GB of transferred files and 200K hits every day, 70GB and 250K
hits on saturday/sunday)


On Wed, Jan 25, 2012 at 8:26 PM, Adam Nowacki wrote:

> As of now custom content (custom maps mostly) on the server can be
> compressed with bzip2 to reduce the time clients have to wait on the
> loading screen. While the compression ratio of bzip2 is already quite good
> there is a far better alternative: LZMA (see http://en.wikipedia.org/wiki/
> **LZMA ). Decompression code is very
> simple, small and free/open-source libraries are available.
>
> Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3 times
> larger than LZMA compressed ones:
> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[daniel jokiaho]

would be good to announce. Im changing ip on my servers atm and some users
would think my servers are affected.

But im changing because of other reasons.
On 25 Jan 2012 21:18, "Andre Müller"  wrote:

> Thier problem, not our problem!
>
> 2012/1/25 Yuki 
>
> > Will this ever be officially stated outside of the mailing list? I'm sure
> > there's a few server owners out there that don't follow the list and
> could
> > be punished for simply not knowing.
> >
> >
> > On 24/01/2012 20:08, Fletcher Dunn wrote:
> >
> >> Yesterday the Team Fortress team took further action pursuant to the
> >> "policy of truth" that was announced in December of last year.  We
> delisted
> >> some servers that were reporting inaccurate information in
> >> server-browser-related communications.
> >>
> >> Our goals are for players to be able to find the server they are looking
> >> for quickly and easily, and for server operators to compete solely on
> the
> >> basis of the quality of the experience they provide.  Any plugins that
> >> modify server browser communications (or modify the information
> contained
> >> in those packets) are counter to those goals.
> >>
> >> The following guidelines are self-evident:
> >>
> >> * All of the data you report to clients and to Steam must be
> >> accurate.
> >>
> >> * You must use the Source engine, using the steam libraries, to
> >> send all server-browser-related communications.
> >>
> >> * Do not modify or manually send any packets to Steam.
> >>
> >> * Do not modify or manually send any client ping replies.
>  (Those
> >> that convey server browser info, player counts, etc.)
> >>
> >> * Do not to set any values that are sent in these communications
> >> outside the legal range.
> >>
> >> * The data reported to the master server and to clients must
> >> match.
> >>
> >>
> >> If you aren't running any plugins that do any of these sorts of things,
> >> you can disregard this post.  If you are, please stop.  If you feel that
> >> you have a real reason to make these modifications to your server, then
> >> communicate with us and help us understand!  We'll try to work out a
> >> solution that fits everybody's needs.
> >>
> >> Thanks,
> >> The Team Fortress Team
> >>
> >> __**_
> >> To unsubscribe, edit your list preferences, or view the list archives,
> >> please visit:
> >> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >>
> >
> >
> > __**_
> > To unsubscribe, edit your list preferences, or view the list archives,
> > please visit:
> > https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux<
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux>
> >
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Andre Müller]

Thier problem, not our problem!

2012/1/25 Yuki 

> Will this ever be officially stated outside of the mailing list? I'm sure
> there's a few server owners out there that don't follow the list and could
> be punished for simply not knowing.
>
>
> On 24/01/2012 20:08, Fletcher Dunn wrote:
>
>> Yesterday the Team Fortress team took further action pursuant to the
>> "policy of truth" that was announced in December of last year.  We delisted
>> some servers that were reporting inaccurate information in
>> server-browser-related communications.
>>
>> Our goals are for players to be able to find the server they are looking
>> for quickly and easily, and for server operators to compete solely on the
>> basis of the quality of the experience they provide.  Any plugins that
>> modify server browser communications (or modify the information contained
>> in those packets) are counter to those goals.
>>
>> The following guidelines are self-evident:
>>
>> * All of the data you report to clients and to Steam must be
>> accurate.
>>
>> * You must use the Source engine, using the steam libraries, to
>> send all server-browser-related communications.
>>
>> * Do not modify or manually send any packets to Steam.
>>
>> * Do not modify or manually send any client ping replies.  (Those
>> that convey server browser info, player counts, etc.)
>>
>> * Do not to set any values that are sent in these communications
>> outside the legal range.
>>
>> * The data reported to the master server and to clients must
>> match.
>>
>>
>> If you aren't running any plugins that do any of these sorts of things,
>> you can disregard this post.  If you are, please stop.  If you feel that
>> you have a real reason to make these modifications to your server, then
>> communicate with us and help us understand!  We'll try to work out a
>> solution that fits everybody's needs.
>>
>> Thanks,
>> The Team Fortress Team
>>
>> __**_
>> To unsubscribe, edit your list preferences, or view the list archives,
>> please visit:
>> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>>
>
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Andre Müller]

++ A nice to have feature.

2012/1/25 Adam Nowacki 

> As of now custom content (custom maps mostly) on the server can be
> compressed with bzip2 to reduce the time clients have to wait on the
> loading screen. While the compression ratio of bzip2 is already quite good
> there is a far better alternative: LZMA (see http://en.wikipedia.org/wiki/
> **LZMA ). Decompression code is very
> simple, small and free/open-source libraries are available.
>
> Below is a comparison of bzip2 and LZMA for the custom maps hosted on my
> server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3 times
> larger than LZMA compressed ones:
> 1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
> 1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
> 1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
> 2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
> 1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
> 1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
> 2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
> 1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
> 1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
> 1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
> 1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
> 1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
> 1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
> 1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
> 1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
> 1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
> 2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
> 1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
> 1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
> 1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
> 2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
> 1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
> 2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
> 1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
> 1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)
>
> __**_
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> https://list.valvesoftware.**com/cgi-bin/mailman/listinfo/**hlds_linux
>
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

[hlds_linux] request for LZMA compression support for custom content downloads (maps)

[Adam Nowacki]

As of now custom content (custom maps mostly) on the server can be 
compressed with bzip2 to reduce the time clients have to wait on the 
loading screen. While the compression ratio of bzip2 is already quite 
good there is a far better alternative: LZMA (see 
http://en.wikipedia.org/wiki/LZMA). Decompression code is very simple, 
small and free/open-source libraries are available.


Below is a comparison of bzip2 and LZMA for the custom maps hosted on my 
server (team fortress 2), bzip2 compressed files are from 1.3 to 2.3 
times larger than LZMA compressed ones:

1.4x cp_antiquity_rc1.bsp (bzip2: 31.6MiB, lzma: 22.1MiB)
1.9x cp_crossroads_b5.bsp (bzip2: 20.4MiB, lzma: 10.9MiB)
1.3x cp_glacier_rc6.bsp (bzip2: 33.8MiB, lzma: 26.5MiB)
2.3x cp_mainline_rc5.bsp (bzip2: 22.8MiB, lzma: 10.0MiB)
1.7x cp_snakewater.bsp (bzip2: 31.6MiB, lzma: 18.4MiB)
1.7x cp_upland_rc2.bsp (bzip2: 39.7MiB, lzma: 23.7MiB)
2.2x cp_vertigo_beta3.bsp (bzip2: 21.6MiB, lzma: 9.8MiB)
1.8x cp_zinkenite_b3a.bsp (bzip2: 73.5MiB, lzma: 41.8MiB)
1.5x ctf_converge_b3.bsp (bzip2: 35.3MiB, lzma: 23.6MiB)
1.8x ctf_haarp.bsp (bzip2: 39.4MiB, lzma: 22.1MiB)
1.9x ctf_landfall_rc.bsp (bzip2: 22.8MiB, lzma: 11.7MiB)
1.5x ctf_premuda_b1b.bsp (bzip2: 53.2MiB, lzma: 36.5MiB)
1.8x ctf_vector_v1.bsp (bzip2: 23.4MiB, lzma: 13.1MiB)
1.5x ctf_wildfire_rc.bsp (bzip2: 21.1MiB, lzma: 14.1MiB)
1.3x koth_namicott_rc1.bsp (bzip2: 12.8MiB, lzma: 9.7MiB)
1.8x pl_borneo_v1.bsp (bzip2: 21.7MiB, lzma: 12.2MiB)
2.0x pl_boundary_final.bsp (bzip2: 20.9MiB, lzma: 10.7MiB)
1.3x pl_cashworks_prefinal.bsp (bzip2: 42.1MiB, lzma: 31.3MiB)
1.6x pl_manngrove_rc5.bsp (bzip2: 29.8MiB, lzma: 18.8MiB)
1.3x pl_mill_b5.bsp (bzip2: 32.4MiB, lzma: 25.5MiB)
2.0x pl_outback_rc4.bsp (bzip2: 27.7MiB, lzma: 14.1MiB)
1.3x pl_problematique_a3.bsp (bzip2: 4.7MiB, lzma: 3.6MiB)
2.1x pl_yamashiro_b3.bsp (bzip2: 16.2MiB, lzma: 7.8MiB)
1.9x plr_panic_b2.bsp (bzip2: 37.1MiB, lzma: 19.7MiB)
1.7x tc_meridian_rc3.bsp (bzip2: 42.1MiB, lzma: 24.1MiB)

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Re: [hlds_linux] The policy of truth is still in effect

[Yuki]

Will this ever be officially stated outside of the mailing list? I'm 
sure there's a few server owners out there that don't follow the list 
and could be punished for simply not knowing.


On 24/01/2012 20:08, Fletcher Dunn wrote:

Yesterday the Team Fortress team took further action pursuant to the "policy of 
truth" that was announced in December of last year.  We delisted some servers that 
were reporting inaccurate information in server-browser-related communications.

Our goals are for players to be able to find the server they are looking for 
quickly and easily, and for server operators to compete solely on the basis of 
the quality of the experience they provide.  Any plugins that modify server 
browser communications (or modify the information contained in those packets) 
are counter to those goals.

The following guidelines are self-evident:

* All of the data you report to clients and to Steam must be accurate.

* You must use the Source engine, using the steam libraries, to send 
all server-browser-related communications.

* Do not modify or manually send any packets to Steam.

* Do not modify or manually send any client ping replies.  (Those that 
convey server browser info, player counts, etc.)

* Do not to set any values that are sent in these communications 
outside the legal range.

* The data reported to the master server and to clients must match.

If you aren't running any plugins that do any of these sorts of things, you can 
disregard this post.  If you are, please stop.  If you feel that you have a 
real reason to make these modifications to your server, then communicate with 
us and help us understand!  We'll try to work out a solution that fits 
everybody's needs.

Thanks,
The Team Fortress Team

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux



___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux