Jager

I can simply nuke PB from orbit and leave it til last to update if you all prefer. I have more then enough on my plate, and PB isnt playing nice with Sourcemod so I was up until noon today from 6pm last night working on it. yeah thats 18 hours straight on getting pb to some semblance of working order. I want those hours of my life back. I certainly don't mind. you do realize that since you are doing ZERO work and spent a week or more complaining that mute did not work anymore and "ZOMG PB IS TEH BROKES /slashwrist" That i could care less if you get a console message when each player is unmuted when mani cant get simple cvars to work right in PB. I found a work around as requested anyway even though its a waste of goddamned time. since Valve borked 98% of the plugins out there. PB can be the redheaded stepchild again and left to rot til I am done with 3+ pages of other work/conversions of plugins as was recommended by most people. Take your pick I personally have no qualms about hitting the delete server button and restarting the damn thing when I have even the time much less the energy to turn my pillow to the cold side and deal with that festering herpes blister of mishmashed plugins and bad code. TL:DR if you are doing no work and have complained that your X plugin isnt Y perfect as it used to be, blame valve take a chill pill and let me finish my 1 man complete overhaul of the communities backend services. (not including you testers, thank you for your help)

due to it being event script based there are limits to how it can read who is exempt from mute. I can add steamid's to the mute immunity, but that is well over 300 ppl to add :\. but standard admin chats still work, as does text in SM, but just not voice. if we run into issues where it is necessary I can add the admins who request it to the addon when I am less swamped.

I have loaded a new ES script that works within sourcemod and mani to mute people correctly within PB. In Mani it will ma_mute any Terrorist for 15 seconds every round start, and will mute you when you die for both sides. (CT's are un-muted at round start) Please note on sourcemod the script will mute your voice, but NOT your text and the commands are separate. Should be live soon after this is posted.

also soy beans dont have teets so soy juice, not soy milk.... i know its udderly pedantic... xD

to bypass the issue try hitting shift+tab to open the steam ui overlay. that generally forces the graphics engine to start functioning correctly.

We are moving the Website to our new host within the next 24-48 hours. While we are doing this move, we are going to be installing sourcebans into the site. This means we will be setting up Sourcemod on the servers as well, and migrating away from Globalbans While we are working on this move, we need to migrate all the users over (supporters+) this will take some time, but I hope to have it setup in a week. We will be either tracking you down in Vent/ private messaging you on the forums to get your steam id, email, and preferred password or just asking you to log into the site with a lost password request once we transfer your data over from Gbans. This is due to Gbans not looking to be capable of updating to orangebox. More info as well as server commands and such for the SA's and additional Admins training will be posted as necessary. also servers such as TTT gmod will be added into the sourcebans site and not stand alone bansystem. Please note that if you are banning anyone permanently, to save the information and add it to the globalbans site (or post so a higherup can) so we can transfer that data over to the SB site. Thanks

oh herro

ok so due to some more current information about globalbans and eventscripts working with CSS now, we may be moving to SM/SB sooner then expected. seems SM/SB is already working on CSS already, so we may be swapping over to get a global system back online. that being said I will update when We have made some decisions on what we are doing.

well as I said I am not rolling this out unexpectedly, nor going to leave the admin groups high and dry on what their commands and options are, the biggest shift can be mitigated by changing @ in mani when we are closer to rollout with ! so admins can get used to it (since !gtfomenu hasn't been an issue). but swapping admin systems isnt the end of the world, neither is swapping ban systems. just because Sourcebans goes live at some point doesn't mean I am deleting Gbans. i will probably keep it updated for a while until we are confident in sourcebans working as intended even when we roll out SB.

it learns the Cyrillic or it gets the vodka bottle to the head again

well thats why i put the j/k, but atarian was more a behind the scenes bd, which was easier then trying to outdo henda for announcement and ban threads. I dont remember seeing atarian on the servers much either, except when he was testing something. And why am I not surprised jen wants to add atarian to her tech support closet. be careful atarian first its the random errors, then the bsod cry for help, and then the drugged thermal paste and you wake up in her basement.

as far as the "clunkiness" of SM it uses the same menu system and popup as mani, so trying to say one is "better" then the other is difficult to do. as far as our current setup, banning someone from the server means they are only banned on Gbans until I transfer over the banlists to the specific server. Sourcebans(SB) (sourcebans is not sourcemod, though they mesh) removes the standard SM ban options, and puts in its own. namely that a ban via SB is also written to the local banlist, and automatically defaults to storing the ban locally if communications with the SB site are down, and will then upload the bans to the site when it can get back in. IE no more losing admins or fubared bans when the site goes down for w/e reason. SM is fairly easy to hack, as is mani, and any other plugin based admin system. SM's vulnerabilities are somewhat mitigated by SB as the site sets admin and a base protected user which on server start or map change is refreshed, so while SM_ban #all can work if your immunity is not higher then the other people playing, then you will succeed at best in banning people without ban powers. and since bans are deletable and unbannable ingame (for certain user levels) we can easily fix the issues if someone goes haywire with a few clicks actually easier to fix then Gbans atm since our version of GB doesn't support deleting bans. again I do not plan to just roll Sourcemod and sourcebans out randomly (Hi valve, this jabs for you newell)) and the base commands are accessed the same way ingame. either sm_admin or !chat etc the only thing people may get confused with is that admin only chat is teamchat then !chat rather then Y @chat as it is atm with mani. and i can change the mani @ cmd to ! if people are that worried about switching over. We alo have a highly capable staff of higherups who can or have used SM as much as Mani, so there is no real learning curve here other then swapping some binds to add SM_ to them

holy fuck you are a newfag :O j/k welcome back atarian, gonna stay around or you in and out again?

mmm i love the smell of bacon in the morn..... oh shi

you probably got yourself banned from your own site. put in a ticket to your host with your ip address and request that they see if you were banned or not. 9times outa 10 something borked and your ip gets locked out for flooding the site.

yep, valve knows their standard maps are borked (de_inferno,dust2 etc), and they are not doing anything about it. and regardless of what you see in your game FOV, the game engine is giving the graphics data to you from every client in game within a certain defined area around you. its why demos allow you to see third person in a first person game and spectator works as you are viewing the graphics data of another client that is also being sent to you. Valve stated this years ago that the way the servers function is that instead of balancing who is sending the data and keeping x number of streams separated, (tech at the time couldn't handle that kind of cpu at the requirements valve was keeping to) that they would take all the client data, combine it and then send it to every client. no need to manage streams and less server lag the more players you added. That decision while for the time a good idea, is what allows the Game to be so easily cheated with/on. aimbots, wallhacks,radar hacks,sound ESP hacks, all rely on that data to be shown to you when otherwise you wouldn't see or hear it normally. and that is the stream they hook into. Valve knows and short of a server side recoding, VAC is valves answer to the issue. cable/dsl >768k is ok to use. but try going to http://www.speedtest.com and seeing what speeds you get, whatever you get as an average download speed is what you can use.

our server fps is set via cmd line, but as you like to point to whispers wiki list of source info, what he doesnt cover is how your fps and the engine renders objects you cannot see when you are playing and you toss a bunch of flash bangs, each "bang" drops your fps, for a fraction of a second regardless of the fact that your screen is white, the graphic engine is rendering everything there(the main reason why many visual hacks work, valve was part lazy, and part tech wasnt capable of rendering that stuff on and off on the fly when the original cs was rolled out.), which the more congested the server, and the more explosions or graphical entities to render appear, the more your fps drops, which is something net_graph can only show you when its a consistent hit over the course of at least its polling time (1 sec or so per update.) my 4890 ati card is more then capable of handling CS:S maxxed out, but if we do something as simple as give everyone a para on more then one round, the fps drops precipitously as the graphics engine attempts to render data it says should be there (spectators having para's) but aren't always visible to the client when you are alive. In extreme cases you will see that in netgraph, but if you round a corner and several plaers and spectators are there, the instant choke hit from the fps drop is not noticeable other then as a "felt" lag spike until you are dead yourself and you can see the para's in everyones hands or "floating " behind whomever is being spectated. the game itself renders beyond what the client sees, so forcing your fps to be set to a number removes two issues. one that the game defaults to your hardware settings and can default vsync on (without the options menu showing it) which chokes you to hell and back. and two forces your game to override whatever happened to be saved in your standard cfg, which if you have been toying with your settings or got new hardware it default to wonky crap til you manually set it. other than that forcepreload is a decent idea to try as well. It force the game to load all the game assets before you get into the map. takes you longer to get in game , but you wont have as much potential lag from an overworked HDD loading objects, textures, sounds, etc. You and I can go back and forth on this all we want, but what i am trying to nail down with him is the short and to the point fixes for the engines various issues without losing anyone in explanations like this. if he is playing escape and lags on nade throws that is something besides his bog standard rates. fps_max is one step in that fix, dropping graphical options, turning off rendering of skyboxes and other non essential assets is another. edit: nls check your graphical settings and see if you have vsync on, if so, disable it. and put fps_max 200 or so in your console. even with slow internet, you shouldnt be artificially limited to 60 out without your grapics card settings being off.

run in console net_graph 3 and tell me what your in/ out numbers say,

that will likely help quite a bit, abet not with choke/lag from or to the server.

jen, revolutionizing spring loaded kitten packaging through reusable wiener dog shipping containers.

youd be surprised what can happen, we had fps_max 500 set in the force client section of the server.cfg and it was forcing clients to unbound their fps max, which caused ridiculous amounts of lag. (unintentional error but still one that almost killed the reg css server for 3 days.) dropping that one command fixed the registry and lag issues that everyone was complaining about. While the orange box does not suffer from the limitation, CS:s still does, too much, or not high enough fps can cause choke/lag issues for your client. while it may not make a huge difference, binding your fps to a set ceiling removes a possible issue . and if you are using vsync, turn that off. as for the OP's issues if you are on wireless and vista or win7 you probably are experiencing the windows wireless internet lag spike. and there is a thread here that details fixing it. click me for fix

if you are on a more powerful pc, make sure you set your fps_max to 200 or less. most newer cards easily do more then that in CSS, and that leads to choke.