Re: [hlcoders] Server Plugin Client Plugin communication ?
-- [ Picked text/plain from multipart/alternative ] I would imagine that would be a huge security issue if that were possible. If a server could force feed me a plugin, and presumably load it, it could do all manner of evil stuff to my game or my system. That said, it would be very cool to have a communication option available between a server plugin and client plugin that was optional. The last patch for Enemy Territory added the capability for a user controllable pipe between client and server so raw data could be sent and could be process in callbacks on the client. Similar capability would be very cool IMO, but forcing the plugin on users is a big nono in my book. Alternately with the proper knowhow you could probably establish a seperate connection between a server plugin and client plugin with your own network code, if there is functionality to get the client ip in a server plugin. I wouldn't get my hopes up about something like this though. J On 11/16/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, thanks for your replay... I have tested it out now and have seen, that there is an block in the auto download system to download *.dll files... When i rename an dll to another format like *.wav there get the file downloaded but than i have the problem, that i cant rename the file on the client system... I have thinked, that i download the files on connecting and after accept the agreements the client plugin get checking for actions like make an screenshot or check for an running program like an anti cheat system... So there is no way to do it? Valve? it where nice, to add an funktion so that we can start downloading the client the plugin and the client get an message: This Server uses an Client Plugin to play on it... You like to download it? YES / NO So we can make thinks like an Game Server Radio station or other nice features... But when he have to install it manually, it dont give many players there do it... :( I hope anybody have an nice idea!!! Thanks for all tips!!! With friendly reguards from germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, November 17, 2006 7:35 AM Subject: Re: [hlcoders] Server Plugin Client Plugin communication ? Hey rat, i think the only way to get people to download plugins now is to give them a weblink, i know many people will be truning the download content off - even though it has been a valid convar for a long while. Adam --- Ratman2000 [EMAIL PROTECTED] wrote: Hello, i like to start a new way to communicat from server with clients... So my idea was it, to load an server plugin and then by connecting an client plugin is forced to download... Now when the player puts in the server, the plugin where loaded by server command... But i have tested it, so i found out, that i dont can force dll`s to download now... Is there a way to realise an plugin with this funktions? So i need an funktion, to force the client to download the files there are needed for the client plugin (like an War screenshot plugin or other...) Is there a way to do it? I hope you can help me! Thanks! Sorry for my bad english :) With friendly Reguards from Germany Ratman2000 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com Sponsored Link Mortgage rates near 39yr lows. $310k for $999/mo. Calculate new payment! www.LowerMyBills.com/lre ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Server Plugin Client Plugin communication ?
Ah i know what you mean now The .res format that plugins, and plain old servers use was intrdouced around 1.2 of Gold Source. If i can think back to a document i read by Jay Wilber about the format you could only allow map file formats, wav, txt, bsp, wad, etc, to stop servers sending unwated exe, com, and dll files that could be harmful to the clients system. If you can get enough clout behind the plugin like with CheatingDeath then you could setup a client/server hook. But no, mani mod, and un-modded servers will not send any 'code' files to the client. Adam --- Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I would imagine that would be a huge security issue if that were possible. If a server could force feed me a plugin, and presumably load it, it could do all manner of evil stuff to my game or my system. That said, it would be very cool to have a communication option available between a server plugin and client plugin that was optional. The last patch for Enemy Territory added the capability for a user controllable pipe between client and server so raw data could be sent and could be process in callbacks on the client. Similar capability would be very cool IMO, but forcing the plugin on users is a big nono in my book. Alternately with the proper knowhow you could probably establish a seperate connection between a server plugin and client plugin with your own network code, if there is functionality to get the client ip in a server plugin. I wouldn't get my hopes up about something like this though. J On 11/16/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, thanks for your replay... I have tested it out now and have seen, that there is an block in the auto download system to download *.dll files... When i rename an dll to another format like *.wav there get the file downloaded but than i have the problem, that i cant rename the file on the client system... I have thinked, that i download the files on connecting and after accept the agreements the client plugin get checking for actions like make an screenshot or check for an running program like an anti cheat system... So there is no way to do it? Valve? it where nice, to add an funktion so that we can start downloading the client the plugin and the client get an message: This Server uses an Client Plugin to play on it... You like to download it? YES / NO So we can make thinks like an Game Server Radio station or other nice features... But when he have to install it manually, it dont give many players there do it... :( I hope anybody have an nice idea!!! Thanks for all tips!!! With friendly reguards from germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, November 17, 2006 7:35 AM Subject: Re: [hlcoders] Server Plugin Client Plugin communication ? Hey rat, i think the only way to get people to download plugins now is to give them a weblink, i know many people will be truning the download content off - even though it has been a valid convar for a long while. Adam --- Ratman2000 [EMAIL PROTECTED] wrote: Hello, i like to start a new way to communicat from server with clients... So my idea was it, to load an server plugin and then by connecting an client plugin is forced to download... Now when the player puts in the server, the plugin where loaded by server command... But i have tested it, so i found out, that i dont can force dll`s to download now... Is there a way to realise an plugin with this funktions? So i need an funktion, to force the client to download the files there are needed for the client plugin (like an War screenshot plugin or other...) Is there a way to do it? I hope you can help me! Thanks! Sorry for my bad english :) With friendly Reguards from Germany Ratman2000 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com Sponsored Link Mortgage rates near 39yr lows. $310k for $999/mo. Calculate new payment! www.LowerMyBills.com/lre ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences,
Re: [hlcoders] Server Plugin Client Plugin communication ?
Hello, the Problem is, that i am thinking about an Anti Cheat Plugin to find Aimbots, Wallhacks and other like Punkbuster for CS 1.4? The problem was, that the cheater have hacked the Buster... Where there a way to modify the Client Plugin on every server (like random check intervalls or other) the Cheat coder cant hack the Buster so fast... So as theory: Client Anti Cheat Plugin Released and the client downloaded it on Server 1 Client Disconnects and connects on Server 2 but here the Plugin intervalls and routines are changed (automatically) He than connects on Server 3 and get an other version that changed too... So the coder have to find out what algorythm the plugin uses to make an safe cheat... But in this time the plugin can find hunderts of cheaters and log it to an global list... So when the algorythm is hacked, we only implement an new and put the plugin with an server plugin auto updater on every Server without restarting it so the cheaters dont know the new algorythm and the check find out that they cheat... So we can catch many cheaters but when the client have to download the client plugin all times, he dont connect to this servers So the Plugin where useless You know what i mean? The Client download can put up an popup with information like: === === The Server forced you to install the Plugin XXX === === You want to do it automatically?=== ===YESNO === === So the user can choose what to do... So when i have an Radio Server the player can hear it when he have the plugin... I think this is interessting for many players... (not all) Or an Plugin with Tutorials like an Taktik manager is an nice idea So one admin programms Taktiks in it and the plugin on client side make the thinks like lines to follow, special marks to find special points or points to check before go away and more... Thats gives the game the old look like Defusing Bombs and rescue Hostages... And dont only get nice stats... But your right... the risk is verry high... So he can format the harddrive or install trojans... So a way where to limited the rights to only the HL2 Folders... So we can make own Windows and other but cant do damage in the system... You know what i meen? I think an system like this what i have writen from are interesting many Plugin Coders becouse the Server Side funktions are verry verry small... So we can make own Windows on Client an can Show it with the server side plugin and other thinks... So, is there an example Client Plugin? (Like the Stub?) Thanks for your informations!!! With friendly reguards from germany Ratman2000 - Original Message - From: Jeremy Swigart [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, November 17, 2006 9:37 AM Subject: Re: [hlcoders] Server Plugin Client Plugin communication ? -- [ Picked text/plain from multipart/alternative ] I would imagine that would be a huge security issue if that were possible. If a server could force feed me a plugin, and presumably load it, it could do all manner of evil stuff to my game or my system. That said, it would be very cool to have a communication option available between a server plugin and client plugin that was optional. The last patch for Enemy Territory added the capability for a user controllable pipe between client and server so raw data could be sent and could be process in callbacks on the client. Similar capability would be very cool IMO, but forcing the plugin on users is a big nono in my book. Alternately with the proper knowhow you could probably establish a seperate connection between a server plugin and client plugin with your own network code, if there is functionality to get the client ip in a server plugin. I wouldn't get my hopes up about something like this though. J On 11/16/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, thanks for your replay... I have tested it out now and have seen, that there is an block in the auto download system to download *.dll files... When i rename an dll to another format like *.wav there get the file downloaded but than i have the problem, that i cant rename the file on the client system... I have thinked, that i download the files on connecting and after accept the agreements the client plugin get checking for actions like make an screenshot or check for an running program like an anti cheat system... So there is no way to do it? Valve? it where nice, to add an funktion so that we can start downloading the client the plugin and the client get an message: This Server uses an Client Plugin to play on it... You like to download it? YES / NO So we can make thinks like an Game Server Radio station or other nice features... But when he have to install it manually, it dont give many
Re: [hlcoders] Server Plugin Client Plugin communication ?
Hello, i know that no plugin send code files... But thinkin on an Trojan... he transforms itself so that Anti Virus cant find it... With te same shematic we can create an Anti Cheat by using an algorithym and change it all days... So Cheater have an hard live... But with the currently system there is nothin what we can do... And now with the server command block we cant not longer check for console commands like aimbot 1 So the update brokes now the last way we can detect cheaters What can we do now? Nothing... Nice work... :'( Why Valve release this updates? Like to kill al plugins? Or why he include this functions? With this commands we cant do anny carefull... We can close the game but thats all... He gives us the Helper and than put in the client an function to block it... Nice work :P I hope valve looks what he do... i find the game isnt more that what it was... Its only an Cheating and Fragging game... Nothing more :'( In CS 1.4 we cant do annythink what we want and nobody hase done carefull thinks... Jokes ok... but not more... and now? We cant do anythink... The Plugin system iss verry small, we cant do anythink with needed funktions like Bullet Count (Becouse there is no way to count the real shoots...) and other functions that the community need where dont included... But functions to cut plugins I dont understand what goes wrong here With friendly reguards Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, November 17, 2006 10:44 AM Subject: Re: [hlcoders] Server Plugin Client Plugin communication ? Ah i know what you mean now The .res format that plugins, and plain old servers use was intrdouced around 1.2 of Gold Source. If i can think back to a document i read by Jay Wilber about the format you could only allow map file formats, wav, txt, bsp, wad, etc, to stop servers sending unwated exe, com, and dll files that could be harmful to the clients system. If you can get enough clout behind the plugin like with CheatingDeath then you could setup a client/server hook. But no, mani mod, and un-modded servers will not send any 'code' files to the client. Adam --- Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I would imagine that would be a huge security issue if that were possible. If a server could force feed me a plugin, and presumably load it, it could do all manner of evil stuff to my game or my system. That said, it would be very cool to have a communication option available between a server plugin and client plugin that was optional. The last patch for Enemy Territory added the capability for a user controllable pipe between client and server so raw data could be sent and could be process in callbacks on the client. Similar capability would be very cool IMO, but forcing the plugin on users is a big nono in my book. Alternately with the proper knowhow you could probably establish a seperate connection between a server plugin and client plugin with your own network code, if there is functionality to get the client ip in a server plugin. I wouldn't get my hopes up about something like this though. J On 11/16/06, Ratman2000 [EMAIL PROTECTED] wrote: Hello, thanks for your replay... I have tested it out now and have seen, that there is an block in the auto download system to download *.dll files... When i rename an dll to another format like *.wav there get the file downloaded but than i have the problem, that i cant rename the file on the client system... I have thinked, that i download the files on connecting and after accept the agreements the client plugin get checking for actions like make an screenshot or check for an running program like an anti cheat system... So there is no way to do it? Valve? it where nice, to add an funktion so that we can start downloading the client the plugin and the client get an message: This Server uses an Client Plugin to play on it... You like to download it? YES / NO So we can make thinks like an Game Server Radio station or other nice features... But when he have to install it manually, it dont give many players there do it... :( I hope anybody have an nice idea!!! Thanks for all tips!!! With friendly reguards from germany Ratman2000 - Original Message - From: Adam amckern Mckern [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Friday, November 17, 2006 7:35 AM Subject: Re: [hlcoders] Server Plugin Client Plugin communication ? Hey rat, i think the only way to get people to download plugins now is to give them a weblink, i know many people will be truning the download content off - even though it has been a
RE: [hlcoders] Map not loading in mod, steams fault? :)
Some of the beta testers are having this issue as well, we have MDMPs of the event and it's crashing inside of HL2 with no trace-back into my code. Going into offline mode solved the issue only temporarily before Steam won't let them launch anymore This operation can't be completed while Steam is in offline mode. Of course they also couldn't join any other games ;) You can access the MDMP files at http://obike.thecodevault.net/forsaken_hl2_crashes.rar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Wednesday, November 15, 2006 7:28 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Map not loading in mod, steams fault? :) What happens if you put Steam in Offline mode and try to run the map? I realize that not a fix for a multi-player game but maybe it would be an interesting data point. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Wednesday, November 15, 2006 4:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) -- [ Picked text/plain from multipart/alternative ] I'm one of the people experiencing the problem. I'm not sure what I could be running to cause the problem. It's nothing different than what I run and play any other map just fine. Attempting to debug it with a forced breakpoint isn't proving very useful. It would appears to be something steam is doing, and I can't really debug steam. We've been playtesting several maps regularly and this is the first map that this problem has come up in. Not sure where to go next with this. The biggest annoyance of the problem is how it leaves the system in a jacked up state that only seems to be resolved by a reboot. Jeremy On 11/15/06, Nate Nichols [EMAIL PROTECTED] wrote: I'm experiencing a possibly related bug. I have experienced similar problems (map almost loads, then Steam goes to 99% CPU) when running other software. Specifically, Stani's Python Editor ( http://stani.be/python/spe/blog/ ) causes the problem regularly. My workaround is just exiting SPE before running my mod. Other Steam programs cause the same problem, I can't open Hammer when running SPE either. If I'm not running SPE, though, everything's fine. Is it possible that other members of your team happen to be running other software when testing that map? Nate On 15/11/06, Patrick O'Leary [sui4] [EMAIL PROTECTED] wrote: Well, these 4-5 people can run other maps just fine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Wednesday, November 15, 2006 08:27 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) Check what firewall software their using. Peerguardian2 with certain block lists will prevent Steam accessing Valve's servers. It's best to disable it while Steam loads. ZoneAlarm, if set in fire and forget mode blocks HL2.EXE from connecting and even if running a local listen server it stops it looping back on itself and it'll make things hang. It's often hard to notice if you're running in fullscreen as it covers the alert. It's best to put it into Game Mode with Allow as the default response. I've had similar problems experiences that came down to those two pieces of software. - Jed On 15/11/06, Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] We're having an issue in our mod where one of the maps won't load for like 5 of the mod members. Most of us can load it fine, but for about 5 members the map begins to load normally, at when the loading bar fills up, the game hangs, the computer becomes very unresponsive, and steam.exe chews up 99% cpu, while the hl2.exe sits idle. Shutting down hl2.exe through task manager is the only way to get out of this mess, and afterwards the system is screwed up, and running hl2 again won't even get to the main menu without doing the same thing, so we must reboot, even restarting steam doesn't fix this part. Seems that steam possibly gets stuck in an infinite loop doing something near the end of the loading process or something. As of yet we haven't identified any common traits among the people it happens to, but it's a serious problem that we can't really debug. Anyone hear of any issues like this and/or have any ideas as to what may be the problem? Thanks Jeremy -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:
Re: [hlcoders] Map not loading in mod, steams fault? :)
-- [ Picked text/plain from multipart/alternative ] Yall are actually getting crashes? After how long? After 10 or so minutes of near unresponsive computer with steam pegging at 99% I shut it down with task manager. J On 11/17/06, Ben Everett [EMAIL PROTECTED] wrote: Some of the beta testers are having this issue as well, we have MDMPs of the event and it's crashing inside of HL2 with no trace-back into my code. Going into offline mode solved the issue only temporarily before Steam won't let them launch anymore This operation can't be completed while Steam is in offline mode. Of course they also couldn't join any other games ;) You can access the MDMP files at http://obike.thecodevault.net/forsaken_hl2_crashes.rar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Wednesday, November 15, 2006 7:28 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Map not loading in mod, steams fault? :) What happens if you put Steam in Offline mode and try to run the map? I realize that not a fix for a multi-player game but maybe it would be an interesting data point. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Wednesday, November 15, 2006 4:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) -- [ Picked text/plain from multipart/alternative ] I'm one of the people experiencing the problem. I'm not sure what I could be running to cause the problem. It's nothing different than what I run and play any other map just fine. Attempting to debug it with a forced breakpoint isn't proving very useful. It would appears to be something steam is doing, and I can't really debug steam. We've been playtesting several maps regularly and this is the first map that this problem has come up in. Not sure where to go next with this. The biggest annoyance of the problem is how it leaves the system in a jacked up state that only seems to be resolved by a reboot. Jeremy On 11/15/06, Nate Nichols [EMAIL PROTECTED] wrote: I'm experiencing a possibly related bug. I have experienced similar problems (map almost loads, then Steam goes to 99% CPU) when running other software. Specifically, Stani's Python Editor ( http://stani.be/python/spe/blog/ ) causes the problem regularly. My workaround is just exiting SPE before running my mod. Other Steam programs cause the same problem, I can't open Hammer when running SPE either. If I'm not running SPE, though, everything's fine. Is it possible that other members of your team happen to be running other software when testing that map? Nate On 15/11/06, Patrick O'Leary [sui4] [EMAIL PROTECTED] wrote: Well, these 4-5 people can run other maps just fine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Wednesday, November 15, 2006 08:27 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) Check what firewall software their using. Peerguardian2 with certain block lists will prevent Steam accessing Valve's servers. It's best to disable it while Steam loads. ZoneAlarm, if set in fire and forget mode blocks HL2.EXE from connecting and even if running a local listen server it stops it looping back on itself and it'll make things hang. It's often hard to notice if you're running in fullscreen as it covers the alert. It's best to put it into Game Mode with Allow as the default response. I've had similar problems experiences that came down to those two pieces of software. - Jed On 15/11/06, Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] We're having an issue in our mod where one of the maps won't load for like 5 of the mod members. Most of us can load it fine, but for about 5 members the map begins to load normally, at when the loading bar fills up, the game hangs, the computer becomes very unresponsive, and steam.exe chews up 99% cpu, while the hl2.exe sits idle. Shutting down hl2.exe through task manager is the only way to get out of this mess, and afterwards the system is screwed up, and running hl2 again won't even get to the main menu without doing the same thing, so we must reboot, even restarting steam doesn't fix this part. Seems that steam possibly gets stuck in an infinite loop doing something near the end of the loading process or something. As of yet we haven't identified any common traits among the people it happens to, but it's a serious problem that we can't really debug. Anyone hear of any issues like this and/or have any ideas as to what may be the problem? Thanks
RE: [hlcoders] Map not loading in mod, steams fault? :)
These dumps are all from the same point in the Source engine (during initial client signon to the server), we will look into why/how this is happening. - Alfred Ben Everett wrote: Some of the beta testers are having this issue as well, we have MDMPs of the event and it's crashing inside of HL2 with no trace-back into my code. Going into offline mode solved the issue only temporarily before Steam won't let them launch anymore This operation can't be completed while Steam is in offline mode. Of course they also couldn't join any other games ;) You can access the MDMP files at http://obike.thecodevault.net/forsaken_hl2_crashes.rar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Wednesday, November 15, 2006 7:28 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Map not loading in mod, steams fault? :) What happens if you put Steam in Offline mode and try to run the map? I realize that not a fix for a multi-player game but maybe it would be an interesting data point. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Wednesday, November 15, 2006 4:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) -- [ Picked text/plain from multipart/alternative ] I'm one of the people experiencing the problem. I'm not sure what I could be running to cause the problem. It's nothing different than what I run and play any other map just fine. Attempting to debug it with a forced breakpoint isn't proving very useful. It would appears to be something steam is doing, and I can't really debug steam. We've been playtesting several maps regularly and this is the first map that this problem has come up in. Not sure where to go next with this. The biggest annoyance of the problem is how it leaves the system in a jacked up state that only seems to be resolved by a reboot. Jeremy On 11/15/06, Nate Nichols [EMAIL PROTECTED] wrote: I'm experiencing a possibly related bug. I have experienced similar problems (map almost loads, then Steam goes to 99% CPU) when running other software. Specifically, Stani's Python Editor ( http://stani.be/python/spe/blog/ ) causes the problem regularly. My workaround is just exiting SPE before running my mod. Other Steam programs cause the same problem, I can't open Hammer when running SPE either. If I'm not running SPE, though, everything's fine. Is it possible that other members of your team happen to be running other software when testing that map? Nate On 15/11/06, Patrick O'Leary [sui4] [EMAIL PROTECTED] wrote: Well, these 4-5 people can run other maps just fine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Wednesday, November 15, 2006 08:27 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) Check what firewall software their using. Peerguardian2 with certain block lists will prevent Steam accessing Valve's servers. It's best to disable it while Steam loads. ZoneAlarm, if set in fire and forget mode blocks HL2.EXE from connecting and even if running a local listen server it stops it looping back on itself and it'll make things hang. It's often hard to notice if you're running in fullscreen as it covers the alert. It's best to put it into Game Mode with Allow as the default response. I've had similar problems experiences that came down to those two pieces of software. - Jed On 15/11/06, Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] We're having an issue in our mod where one of the maps won't load for like 5 of the mod members. Most of us can load it fine, but for about 5 members the map begins to load normally, at when the loading bar fills up, the game hangs, the computer becomes very unresponsive, and steam.exe chews up 99% cpu, while the hl2.exe sits idle. Shutting down hl2.exe through task manager is the only way to get out of this mess, and afterwards the system is screwed up, and running hl2 again won't even get to the main menu without doing the same thing, so we must reboot, even restarting steam doesn't fix this part. Seems that steam possibly gets stuck in an infinite loop doing something near the end of the loading process or something. As of yet we haven't identified any common traits among the people it happens to, but it's a serious problem that we can't really debug. Anyone hear of any issues like this and/or have any ideas as to what may be the problem? Thanks Jeremy -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Engine Updates passed onto Source SDK Base?
Hey! I would like to know when the engine updates from last week will be applied to the Source SDK Base, becuase there is some stuff there - namely 'Large Packets' that i would like to apply to my own game. Packets range from 320KB to almost 2MB out side the 255Kb limit according to the console warnings. Adam Nigredo Studios http://www.nigredostudios.com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
RE: [hlcoders] Map not loading in mod, steams fault? :)
Sometimes it'll hang, and just mess up. Others it will crash just when loading is finishing. And the majority of the time it'll hang, and then it'll crash with those. Those MDMP files are from two different users. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Friday, November 17, 2006 5:25 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) -- [ Picked text/plain from multipart/alternative ] Yall are actually getting crashes? After how long? After 10 or so minutes of near unresponsive computer with steam pegging at 99% I shut it down with task manager. J On 11/17/06, Ben Everett [EMAIL PROTECTED] wrote: Some of the beta testers are having this issue as well, we have MDMPs of the event and it's crashing inside of HL2 with no trace-back into my code. Going into offline mode solved the issue only temporarily before Steam won't let them launch anymore This operation can't be completed while Steam is in offline mode. Of course they also couldn't join any other games ;) You can access the MDMP files at http://obike.thecodevault.net/forsaken_hl2_crashes.rar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Durand Sent: Wednesday, November 15, 2006 7:28 PM To: hlcoders@list.valvesoftware.com Subject: RE: [hlcoders] Map not loading in mod, steams fault? :) What happens if you put Steam in Offline mode and try to run the map? I realize that not a fix for a multi-player game but maybe it would be an interesting data point. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Swigart Sent: Wednesday, November 15, 2006 4:46 PM To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) -- [ Picked text/plain from multipart/alternative ] I'm one of the people experiencing the problem. I'm not sure what I could be running to cause the problem. It's nothing different than what I run and play any other map just fine. Attempting to debug it with a forced breakpoint isn't proving very useful. It would appears to be something steam is doing, and I can't really debug steam. We've been playtesting several maps regularly and this is the first map that this problem has come up in. Not sure where to go next with this. The biggest annoyance of the problem is how it leaves the system in a jacked up state that only seems to be resolved by a reboot. Jeremy On 11/15/06, Nate Nichols [EMAIL PROTECTED] wrote: I'm experiencing a possibly related bug. I have experienced similar problems (map almost loads, then Steam goes to 99% CPU) when running other software. Specifically, Stani's Python Editor ( http://stani.be/python/spe/blog/ ) causes the problem regularly. My workaround is just exiting SPE before running my mod. Other Steam programs cause the same problem, I can't open Hammer when running SPE either. If I'm not running SPE, though, everything's fine. Is it possible that other members of your team happen to be running other software when testing that map? Nate On 15/11/06, Patrick O'Leary [sui4] [EMAIL PROTECTED] wrote: Well, these 4-5 people can run other maps just fine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jed Sent: Wednesday, November 15, 2006 08:27 To: hlcoders@list.valvesoftware.com Subject: Re: [hlcoders] Map not loading in mod, steams fault? :) Check what firewall software their using. Peerguardian2 with certain block lists will prevent Steam accessing Valve's servers. It's best to disable it while Steam loads. ZoneAlarm, if set in fire and forget mode blocks HL2.EXE from connecting and even if running a local listen server it stops it looping back on itself and it'll make things hang. It's often hard to notice if you're running in fullscreen as it covers the alert. It's best to put it into Game Mode with Allow as the default response. I've had similar problems experiences that came down to those two pieces of software. - Jed On 15/11/06, Jeremy Swigart [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] We're having an issue in our mod where one of the maps won't load for like 5 of the mod members. Most of us can load it fine, but for about 5 members the map begins to load normally, at when the loading bar fills up, the game hangs, the computer becomes very unresponsive, and steam.exe chews up 99% cpu, while the hl2.exe sits idle. Shutting down hl2.exe through task manager is the only way to get out of this mess, and afterwards the system is screwed up, and running hl2 again won't even get to the main menu without doing the same thing, so we must reboot, even
[hlcoders] cl_restrict_server_commands fiasco
For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Your link is broken. The correct link is http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=3303.15; On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
I dont understand why you sending it to the coders mail list - if you want to talk to valve email them directly, you can find there contact addreses on the VDC. Adam --- Nick [EMAIL PROTECTED] wrote: Your link is broken. The correct link is http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=3303.15; On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders Nigredo Studios http://www.nigredostudios.com Sponsored Link Mortgage rates near 39yr lows. $510k for $1,698/mo. Calculate new payment! www.LowerMyBills.com/lre ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Frazer wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 For anyone who has'nt seen this, Valve have added the command : cl_restrict_server_commands Which makes it impossible for any plugin to carry out changes to client variables... This means rate hackers will now have free reign as we cannot change their rates, we probably won't even be able to detect what they are set to. It also means you cannot set sounds, skins or anything else which involves client exec. To me this seems analogous to blocking JavaScript in my web browser. If I don't want some server admin screwing with my settings, I should have the ability to control what someone else does to my machine. You, as a server operator, are free to prevent anyone from joining your server, so assuming you have the ability to retrieve the value of this cvar from the client, you would be able to control who plays on your server. It sounds like Valve gave customers the ability to restrict an exploit in their game. I would bet there are an order of magnitude more servers running straight vanilla CS or DoD code on them than there are servers running plugins that modify customer's settings. If Valve wants to protect a customer's machine from being modified by some unknown server that they connect to, why shouldn't that be the default option? People that want to connect to servers that modify the customer's settings can be told how to disable this cvar. -- Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
-- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] cl_restrict_server_commands fiasco
Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- - Benjamin Davison -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders ___ To unsubscribe, edit your list preferences, or view the list archives,
Re: [hlcoders] cl_restrict_server_commands fiasco
Hello, my biggest problem with the update is, that it brokes my Quake Sounds System... I have exect on the client the play command... But what can i now do??? =]-RS-[=Ratman2000 connected cl_restrict_server_commands (= 1) prevented server running command: play /ratmod/connect_sounds/tachmusik.mp3 Is there another way, to play the sound by the user??? I hope anybody can helps me! Thanks! With friendly reguards from Germany Ratman2000 - Original Message - From: David Anderson [EMAIL PROTECTED] To: hlcoders@list.valvesoftware.com Sent: Saturday, November 18, 2006 8:18 AM Subject: Re: [hlcoders] cl_restrict_server_commands fiasco Yes, good point, that's unfortunate but true. I can't say I'm a good person to ask which commands, as I'm not very familiar with the client :) But I can take a guess that anything having to do with binds/aliases or client-side settings (i.e. cl_*) is fair game. I just think that at the very least, things that are sent from the server and aren't handled by the client should be properly passed back to the server. Obviously, users can use IServerPluginHelpers to simulate this, but I'm a big stickler for preserving backwards compatibility. Especially in this case when we're not even dealing with binary hacks. ~dvander http://www.bailopan.net/ Nick wrote: You have mentioned some good points. I am curious though which commands you would restrict? About it being default on, the problem is that users that know enough to enable cl_restrict_server_commands 1, are not the ones that need the command the most. The users that do not know how to set cl_restrict_server_commands 1 are the users that need it enabled the most. On 11/18/06, David Anderson [EMAIL PROTECTED] wrote: I think you're missing a few of the important points. Yes, it's important to have this feature, but: a) It broke binary and source level backwards compatibility. That's a big no-no. b) It restricts all commands, which is unnecessary. A better solution would be to flag the commands which need to be protected, or to flag things registered in the client. This would plugins continue to register and trigger their own commands, preserving compatibility. c) It defaults to on, which going back to a), breaks expected functionality. d) Going back to a) again, for an update like this, forewarning would be nice. Those are the issues I have with it, at least. ~dvander http://www.bailopan.net/ Benjamin Davison wrote: -- [ Picked text/plain from multipart/alternative ] Yeah I love it when some 14 year old server admin fucks with my settings and sets my fire command to a suicide command. This is a good console command that was lng overdue. On 11/18/06, Paul Peloski [EMAIL PROTECTED] wrote: -- [ Picked text/plain from multipart/alternative ] I don't think cl_restrict_server_commands is a mistake or bug. If there are exploitable client cvars that need to be monitored by a server plugin, those exploits need to be fixed. Officially supported fixes (not Mani-mod client cvar enforcement) carry the benefit of games that are harder to exploit out of the box, and we don't have to worry about malicious server admins having unwanted access to client settings. Think of a web-page that has the ability to change your web browser settings. It might be nice for a web designer to stick his site in your bookmarks or make sure you don't set your font size too large and break his layout, but, it's your web browser and your browsing preferences shouldn't have anything to do with the web-page author. I wouldn't address Valve like morons or cowards, it's impolite. Your point has some merit but the new cvar is hardly an outrage: why can't admins just use Mani-mod to kick/warn users who set their rate too high, instead of setting the rate for them? Regards, Paul On 11/17/06, Frazer [EMAIL PROTECTED] wrote: For those who may not be following other forums - check this thread out on the mani forum. http://www.mani-admin-plugin.com/index.php?option=com_smfItemid=26topic=33 03.15 The growing consensus seems to be in favour of a mani mod update that kicks players with the default setting, which was applied for them courtesy of Valve. Posts in this forum seem to be landing on deaf ears - but I suspect that if this little movement picks up momentum - then its really going to get ugly fast. Valve: realize and admit the mistake and fix it. Admins are NOT your enemy - not yet, at least. If this auto-kicking thing takes hold, then your PAYING customers are going to feel it. And one more thing Valve - have the balls and courtesy to respond to the concerns being expressed here. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders -- ___ To unsubscribe, edit your
