[hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. If it can be exploited, it will be exploited and by a significant proportion of the community. I have asked for a pure server option that forced all content to be run out of the GCF files, which you could then protect with VAC. If somebody wants to use a 3rd party program to bypass the use of what is in the GCF files, once again, VAC's problem. I think Wim Barrelds could have something to say as to the extent to which you can enforce purity, I hope he chimes in. On 11/23/06, Jani Tiira [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] On 11/23/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. I Agree with you to some extent about this. But the truth is that there are alot of kids who like all the bells and whistles they can use. Admin skins and other nonsense. The admins that want to run a pure server know how to do it so I wouldn't mind if the sv_consistency would be as 0 as it has been before. I'd just be happy if it would actually check the files. Right now I play only on my own servers and in matches I think every league would support this and require it to be set to 1 on all matches. The sad thing is that you're right. If something can be exploited, in CS community it will be exploited and not by few but a majority of players. -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] You cannot run a pure server option: 1) It doesn't exist 2) sv_consistency bug 3) Have you seen what happens to your SRCDS processes when you try to enforce consistency on ALL files with a plugin like CVAR-X? On 11/24/06, Jani Tiira [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] On 11/23/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. I Agree with you to some extent about this. But the truth is that there are alot of kids who like all the bells and whistles they can use. Admin skins and other nonsense. The admins that want to run a pure server know how to do it so I wouldn't mind if the sv_consistency would be as 0 as it has been before. I'd just be happy if it would actually check the files. Right now I play only on my own servers and in matches I think every league would support this and require it to be set to 1 on all matches. The sad thing is that you're right. If something can be exploited, in CS community it will be exploited and not by few but a majority of players. -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
Widening the cvar would be a good idea, valid setup for 0,1,2,3,4 for forcing different setting what is said here or then creating new cvars for each class: models (already is), graphics and sounds. 3 basic class which could be forced and if user has one of them, giving a _proper_ message. Not just server is forcing consistency for blablalba. This really doesnt tell the player what really is wrong. I really think that wallhacks and other cheats are bigger problem than the changing game materials and sounds. Besides, using admin skins is not a problem on the server even if consistency would be on. They are downloaded to players machine on a separate folder and can be called upon use by the server itself only. User cannot get any problems by connecting other servers with the custom models which he has downloaded from the server to his comp. He only can get troubles with the models he himself installed to replace already existing model (same path in the GCF, like /models/player/t_phoenix.mdl) so in other words, if custom skins are used by the server and not the user itself, this isnt a problem. However, calling the server admins as kids who use these features you described is a problem. -ics the kid -- [ Picked text/plain from multipart/alternative ] On 11/23/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. I Agree with you to some extent about this. But the truth is that there are alot of kids who like all the bells and whistles they can use. Admin skins and other nonsense. The admins that want to run a pure server know how to do it so I wouldn't mind if the sv_consistency would be as 0 as it has been before. I'd just be happy if it would actually check the files. Right now I play only on my own servers and in matches I think every league would support this and require it to be set to 1 on all matches. The sad thing is that you're right. If something can be exploited, in CS community it will be exploited and not by few but a majority of players. -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
Jani Tiira schrieb: -- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux Any words from Alfred would be great. Im with you. This should be forced. Best regards -r99t ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] On 11/23/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] 3) Have you seen what happens to your SRCDS processes when you try to enforce consistency on ALL files with a plugin like CVAR-X? We check ALOT of textures from the map that is loaded at the time. Also the skin files. What happens? Wallhackers can't get in and we're very very happy. -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
I agree with this. People using custom data, still have servers that don't enforce this. Jani Tiira wrote: -- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Disable door bug on de_nuke
Hi all, does anybody know how can I disable the door bug on de_nuke? On my tickrate 100 Server the doors open very slowly. It would be very nice, if someone could help me Greetz Tobias Jordan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Feature Request/Bug Tracker
About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] RE: Feature Request/Bug Tracker
The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). - Alfred Erik Hollensbe wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
RE: [hlds_linux] RE: Feature Request/Bug Tracker
This sounds like a great idea and I personally would love to see this implemented. As Alfred said it really depends on the management of the system. Going through the Steampowered threads is crazy at the best of times. I would also like to help/code etc, so let me know how things go :) Cheers, Tristan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alfred Reynolds Sent: Friday, 24 November 2006 9:01 AM To: Erik Hollensbe; hlds_linux@list.valvesoftware.com Subject: [hlds_linux] RE: Feature Request/Bug Tracker The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). - Alfred Erik Hollensbe wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Disable door bug on de_nuke
-- [ Picked text/plain from multipart/alternative ] That's just a known problem with 100 tick. Switch to 66 tick if you don't want to have the door problem. On 11/23/06, Tobias Jordan [EMAIL PROTECTED] wrote: Hi all, does anybody know how can I disable the door bug on de_nuke? On my tickrate 100 Server the doors open very slowly. It would be very nice, if someone could help me Greetz Tobias Jordan ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] RE: Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] I think the signal to noise ratio is quite a bit worse than poor :) mostly it's just kids complaining about how things don't work the way they want. The idea I believe would be very beneficial to the community because it would allow Valve to see new ideas instead of the same exact bug report day after day. If it needs hosting or anything let me know, I've got a big empty webserver sitting here still. On 11/23/06, Alfred Reynolds [EMAIL PROTECTED] wrote: The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). - Alfred Erik Hollensbe wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Disable door bug on de_nuke
In Germany many hosting companies, said they fixed the problem with the door on a tickrate 100 server. But they do not say how. :-( So i think it`s possble to disable this bug. Greetz Tobias ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] The only problem I can foresee, is that the bug list could end up as a giant list of client side exploits and how to reproduce them, which although does not deal directly with HLDS/SRCDS, becomes our problem as server administrators, as we nearly always end up having to implement some sort of solution to fix it. Do you have a bug tracking solution in mind btw? If so, which one? I still have a rather long list of existing bugs. :) On 11/24/06, Erik Hollensbe [EMAIL PROTECTED] wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature Request/Bug Tracker
On Nov 23, 2006, at 3:31 PM, Whisper wrote: -- [ Picked text/plain from multipart/alternative ] The only problem I can foresee, is that the bug list could end up as a giant list of client side exploits and how to reproduce them, which although does not deal directly with HLDS/SRCDS, becomes our problem as server administrators, as we nearly always end up having to implement some sort of solution to fix it. EXCELLENT point. Obviously the system would need the ability to obscure certain information. This could also be accomplished by a external-internal bridge for valve, whereby moving things to their internal tracker, they could be removed from the external one (with an optional mark saying, we've heard about this, etc.) Do you have a bug tracking solution in mind btw? If so, which one? Personally I think bugzilla is a good solution for this. I have experience customizing the system, am (very) familiar with the implementation language, and bugzilla really has unprecedented flexibility (except for some of the Rational tools, perhaps). Obviously though, a lot of this is weighing in on my personal experience - if there are other parties interested that want to chime in on the condition that they are interested in developing such a system, I'm all ears. To translate: I don't think it's worth throwing in your $0.02 on software choice unless you're willing to help customize the system. I still have a rather long list of existing bugs. :) I imagine you're not alone, but such is the nature of software development. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] RE: Feature Request/Bug Tracker
On Nov 23, 2006, at 2:00 PM, Alfred Reynolds wrote: The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). (hlds_apps, sorry about the cross-post but I felt this was relevant.) Alright. I think what happened last time is, after you said this, someone threw up a tracker and it promptly fizzled. I don't think it was the fault of anyone in particular, it just didn't get enough momentum. So! Anyone, If you're interested in DEVELOPING or CUSTOMIZING a bug tracking system for the community and valve to use jointly, please email me personally. Given enough interest, I will setup a mailing list until our program becomes relevant enough to bother Alfred about putting up a related list. Put something like Valve Bug tracker in the subject so I can find it quickly. This is not necessarily something that requires pure programming effort: if you have ideas to contribute, or you're a HTML jockey, etc, we can use you. For those not following the hlds_linux thread, I'm personally leaning towards bugzilla (and will be exploring that ASAP) but have no reason to stick to it, given willing contributors to another system. Our current (tentative) requirements are a voting system to promote bugs to attention, the ability to have valve bring community bugs into an internal tracker, and the ability to have bugs with opaque descriptions (to protect valve and its users against the wanton posting of exploit information). -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] I can't help with the customisation, but I certainly can help with providing the bugs. On 11/24/06, Erik Hollensbe [EMAIL PROTECTED] wrote: On Nov 23, 2006, at 3:31 PM, Whisper wrote: -- [ Picked text/plain from multipart/alternative ] The only problem I can foresee, is that the bug list could end up as a giant list of client side exploits and how to reproduce them, which although does not deal directly with HLDS/SRCDS, becomes our problem as server administrators, as we nearly always end up having to implement some sort of solution to fix it. EXCELLENT point. Obviously the system would need the ability to obscure certain information. This could also be accomplished by a external-internal bridge for valve, whereby moving things to their internal tracker, they could be removed from the external one (with an optional mark saying, we've heard about this, etc.) Do you have a bug tracking solution in mind btw? If so, which one? Personally I think bugzilla is a good solution for this. I have experience customizing the system, am (very) familiar with the implementation language, and bugzilla really has unprecedented flexibility (except for some of the Rational tools, perhaps). Obviously though, a lot of this is weighing in on my personal experience - if there are other parties interested that want to chime in on the condition that they are interested in developing such a system, I'm all ears. To translate: I don't think it's worth throwing in your $0.02 on software choice unless you're willing to help customize the system. I still have a rather long list of existing bugs. :) I imagine you're not alone, but such is the nature of software development. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] RE: Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] Barelds Bump :) On 11/24/06, Alfred Reynolds [EMAIL PROTECTED] wrote: The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). - Alfred Erik Hollensbe wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] Barelds Bump :) On 11/24/06, Whisper [EMAIL PROTECTED] wrote: When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. If it can be exploited, it will be exploited and by a significant proportion of the community. I have asked for a pure server option that forced all content to be run out of the GCF files, which you could then protect with VAC. If somebody wants to use a 3rd party program to bypass the use of what is in the GCF files, once again, VAC's problem. I think Wim Barrelds could have something to say as to the extent to which you can enforce purity, I hope he chimes in. On 11/23/06, Jani Tiira [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] RE: Feature Request/Bug Tracker
-- [ Picked text/plain from multipart/alternative ] Well then, lets get to work on a properly managed bug tracker. On 11/24/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Barelds Bump :) On 11/24/06, Alfred Reynolds [EMAIL PROTECTED] wrote: The idea is an interesting one but the value would come from effective implementation. As I said last time, implement it and if managed properly I am sure we would fine it a valuable source (we already use Steampowered forum threads but the signal to noise ration can be quite poor). - Alfred Erik Hollensbe wrote: About 6 months ago this was being discussed, and never came to fruition. A *lot* of the questions/comments here these days have less and less to do with supporting the system as much as requests to modify it in some fashion. I think it would be not only wise, but prudent for valve or a secondary party to implement a bug tracker or feature request system that would allow people to effectively petition features/bug fixes assigning a priority to the things that are most important to the guys who run the servers. Obviously, it wouldn't be that bad of an idea to tackle this in the client as well. The advantages for valve would be several-fold - not only would you have a backlog of all the things that your constituents are complaining about, but a petitioning system would allow valve to see priority based on the number of people who are interested in seeing this fixed. Several techniques can be used to minimize inflation of voting for requests, but obviously won't eliminate the problem. The advantages for users would be several-fold as well - instead of clogging up the list with the 400th thread that starts with, Where is the 64-bit VAC2 support? One email gets out, and someone replies with a bug number and everyone can see that the bug is marked by valve administrators as WON'T FIX. Not only is it clear to everyone that the bug is already known, it's clear to everyone that valve has no intention of tackling this problem anytime soon (if at all). Obviously there's a relations issue here - people are undoubtedly going to get bent out of shape when they see something tagged as WON'T FIX, but in reality that's no different than the current situation. The above-described situation actually lends to clearing up confusion, simply because the lack of responses by staff has, in the past, caused more problems than is really necessary. This simply doesn't work unless Valve and the community participates - if one of them decides that it's not going to work, the whole point is lost. Undoubtedly, Valve has their own internal trackers and a way to ease the transition from moving to the public database to the private one would be a big bonus for them, I imagine. So, I'll offer again - if there is significant interest by Valve and the community, I'm willing to extend as much help as is attainable to make this happen, whether that be writing code, providing ideas, or administering/hosting the service. -- Erik Hollensbe [EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ Wim 'TheUnknownFactor' Barelds [EMAIL PROTECTED] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] While I'd love a pure setting, a lot could be gained from simply enforcing the material files, and leaving the textures customisable. On top of that the fact that plugins can enforce consistancy on files is nice, however this implementation is sadly broken, much like sv_consistancy used to be. On 11/24/06, Whisper [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Barelds Bump :) On 11/24/06, Whisper [EMAIL PROTECTED] wrote: When it comes to Counter-Strike players, DENY ougth to be the default or requires sv_cheats 1 enabled on the server. If it can be exploited, it will be exploited and by a significant proportion of the community. I have asked for a pure server option that forced all content to be run out of the GCF files, which you could then protect with VAC. If somebody wants to use a 3rd party program to bypass the use of what is in the GCF files, once again, VAC's problem. I think Wim Barrelds could have something to say as to the extent to which you can enforce purity, I hope he chimes in. On 11/23/06, Jani Tiira [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] Right now sv_consistency itself doesn't check that much. With an texture wallhack you can easily access the server. What we've done to solve this is use CVAR-X to check the consistency of these files. Since the new cvar cl_restrict_server_commands and it being set to 1 as default CVAR-X is harder to use. Since I know that Valve has already been informed about the cvars blocked in zBlock and about rate hacking (greets to Barrelds) it would be great that sv_consistency would also be brought up to date. What I'm suggesting that server admins could choose which files to check. The files being: sounds map textures (boxes, walls, doors, etc) player models (skins/models) weapon models Any or all above. I know there are people who love to use skins but right now we are blocking anyone using skins from our servers and we still have our servers full. So there are players who don't need nor wan't skins.There are also paranoid admins (like me) who wanna block custom content because they can be used to gain advantage over other players. Thanks.. -- Jani Tirppa Tiira A player and a server admin. -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ Wim 'TheUnknownFactor' Barelds [EMAIL PROTECTED] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] I mailed Alfred about this and he would like to hear from the developers of CVAR-X if sslice could help in this matter. Anyone got his contact? -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] I do have his contact, I'll give SSlice Alfred's email, and tell him to give it a nudge. On 11/24/06, Jani Tiira [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I mailed Alfred about this and he would like to hear from the developers of CVAR-X if sslice could help in this matter. Anyone got his contact? -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- ___ Wim 'TheUnknownFactor' Barelds [EMAIL PROTECTED] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Feature request: sv_consistency
-- [ Picked text/plain from multipart/alternative ] Thanks, that would be lovely :) -- Tirppa -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
