[Horsedick]

Originally Posted by thetwistedpanda After deleting several players with issues and re-creating them, only to notice the issue remained, I had a thought. I wrote a plugin to purge the server of anything admin related, then I shut down the server, deleted all temporary/sqlite files, reinstalled SourceBans, and started the server up. The issuer persisted, and I nearly broke a keyboard. However, I decided to look at the SQL for the 10th time (at least), and found the problem. SourceBans doesn't (didn't?) properly update the sb_admins_servers_groups table when existing entries have their groups changed. Specifically, the group_id column in the specified table didn't correspond to the gid column within sb_admins. More often than not, the row didn't even exist in the id column for sb_srvgroups. After manually updating more than 3/4s of my entries and rehashing the servers, the players who had problems magically started working again.

That is a big problem.... and I know there is a problem with IP# bans. Too bad a few of the guys that made this haven't come back to support it any...IMO it should be moved to Unapproved since its lacking support.

[thetwistedpanda]

They're not required to provide support. If the plugin works and basic instructions exist, that's enough. Plugin authors are more so required to fix bugs / errors that prevent the plugin from operating normally. As this issue hasn't been reported more often, I'm assuming it was fixed in a previous version or it a specific case where only a few individuals are affected.

[Horsedick]

Originally Posted by thetwistedpanda They're not required to provide support. If the plugin works and basic instructions exist, that's enough. Plugin authors are more so required to fix bugs / errors that prevent the plugin from operating normally. As this issue hasn't been reported more often, I'm assuming it was fixed in a previous version or it a specific case where only a few individuals are affected.

Well would be nice to have some of these recent bugs addressed such as what I've pointed out and you yourself have pointed out...go back several pages and I'm sure there are many more or even suggestions to go within a updated version in the near future.

[11530]

It doesn't help either that the Bug Page listed on the OP (http://tracker.hlxce.com/projects/sourcebans/issues) isn't working.

Edit: Actually it seems the URL of the link in the OP, and the text within the [url] tags are different. The text is correct, but the URL is wrong. Clicking the one above will work fine.

[Peace-Maker]

Originally Posted by thetwistedpanda After deleting several players with issues and re-creating them, only to notice the issue remained, I had a thought. I wrote a plugin to purge the server of anything admin related, then I shut down the server, deleted all temporary/sqlite files, reinstalled SourceBans, and started the server up. The issuer persisted, and I nearly broke a keyboard. However, I decided to look at the SQL for the 10th time (at least), and found the problem. SourceBans doesn't (didn't?) properly update the sb_admins_servers_groups table when existing entries have their groups changed. Specifically, the group_id column in the specified table didn't correspond to the gid column within sb_admins. More often than not, the row didn't even exist in the id column for sb_srvgroups. After manually updating more than 3/4s of my entries and rehashing the servers, the players who had problems magically started working again.

No changes were applied on the gameservers? Changing the steamid of an admin wasn't recognized by the gameservers? The gid column in the sb_admins table is for the web admin group - the group_id column in sb_admins_servers_groups doublicates?! the srv_group column in sb_admins, but saves the group_id instead of the groupname (probably due to some very old design changes in the database scheme which wasn't applied to all parts of the software..) Both are used in the plugin
What did you change manually and what did you try to edit on the admins exactly?

Originally Posted by Horsedick I had one issue where the sucker kept overriding my admins.cfg and admin_groups.cfg files...I didn't want that I wanted them to be left alone yet the sourcebans still work as needed so I went in and edited the code to make it create a admin_groups1.cfg and an admins1.cfg file instead of over writing the others which solved a issue for me but not sure its the same as what you are dealing with. Edit: I'll also bring up something that it seems IP# banning is not working. I had a user create another alt account and enter under the same IP# I made sure to go back and apply a IP# ban to ensure this wouldn't happen yet it did. Anyone else having any issues with IP# bans not working?

You could just have set BackupConfigs to 0 in your sourcebans.cfg ;)
IP banning does work correctly for me. SourceBans doesn't support any wildcards btw, if you tried to ban an ip range.

Originally Posted by Horsedick Well would be nice to have some of these recent bugs addressed such as what I've pointed out and you yourself have pointed out...go back several pages and I'm sure there are many more or even suggestions to go within a updated version in the near future.

It's hard to fix bugs, if one can't replicate them. There are often strange issues with the database connection which aren't part of sourcebans to be fixed. Most of the support is given in the support forum over at interwavestudios.com btw.
Suggestions for new features for upcoming versions aren't added to the current 1.x branch, but would be added to the rewrite - which has sadly frozen due to lack of time in the developement team. The current state is in the svn. If you or someone else got much time at hand, you're welcome to join and submit your patches to finally finish sb2. Since we'd need to write new features twice if we'd add them to 1.x too, we (read FlyingMongoose ) set a feature lock on the 1.x as well as the 2.0 branch. Any new features would be implemented in any upcoming 2.x updates, so 2.0 isn't growing faster than we could rewrite the current functionality.

Originally Posted by 11530 It doesn't help either that the Bug Page listed on the OP (http://tracker.hlxce.com/projects/sourcebans/issues) isn't working. Edit: Actually it seems the URL of the link in the OP, and the text within the [url] tags are different. The text is correct, but the URL is wrong. Clicking the one above will work fine.

Whops, fixed. Thanks.

[daleGEND]

Just a general question and please do not take this the wrong way. I have noticed that using sourcebans seems to cause a pretty heavy lag when loading cookies. It causes other plugins I use to not load their configurations before the first round begins (thus making things like store items, classes, etc to not load). This depends on how many people are in the server at the time. One of my servers is about 46 slots so anything over 12-15 starts to pose a problem.

Are there any performance enhancements in SourceBans 2.0? Any known tips or tricks to fixing this issue?

[Horsedick]

Originally Posted by Peace-Maker You could just have set BackupConfigs to 0 in your sourcebans.cfg ;) IP banning does work correctly for me. SourceBans doesn't support any wildcards btw, if you tried to ban an ip range. It's hard to fix bugs, if one can't replicate them. There are often strange issues with the database connection which aren't part of sourcebans to be fixed. Most of the support is given in the support forum over at interwavestudios.com btw. Suggestions for new features for upcoming versions aren't added to the current 1.x branch, but would be added to the rewrite - which has sadly frozen due to lack of time in the developement team. The current state is in the svn. If you or someone else got much time at hand, you're welcome to join and submit your patches to finally finish sb2. Since we'd need to write new features twice if we'd add them to 1.x too, we (read FlyingMongoose ) set a feature lock on the 1.x as well as the 2.0 branch. Any new features would be implemented in any upcoming 2.x updates, so 2.0 isn't growing faster than we could rewrite the current functionality.

as for the configs... wish I had known that before or it been documented some where...

I set a IP# ban on a full IP# not a range and it didn't block a user using that IP#.. I triple checked, even talked to another admin of another gaming group that saw the same thing. Either something isn't set right that we don't know or there is something wrong some where.

and on the applying bugs I'm just sayin I've noticed several posted here but wasn't sure of solutions perhaps no bugs could just be setups. The whole thing is great the way it is..could it be better? Ohh yes for sure, I can think of several enhancements as well as I'm sure others could too.
Look forward to options on settings being the main thing and each one explained for what function each does in some detail...that eliminates many questions you see here.

[thetwistedpanda]

Originally Posted by Peace-Maker No changes were applied on the gameservers? Changing the steamid of an admin wasn't recognized by the gameservers? The gid column in the sb_admins table is for the web admin group - the group_id column in sb_admins_servers_groups doublicates?! the srv_group column in sb_admins, but saves the group_id instead of the groupname (probably due to some very old design changes in the database scheme which wasn't applied to all parts of the software..) Both are used in the plugin What did you change manually and what did you try to edit on the admins exactly?

Over several months, I modified/created/deleted/edited/re-created server admin groups to separate various classifications of users -- admins, moderators, several different donator groups, reserved slots, etc. Within the past few months, at least the last month I can confirm, I noticed that several users wouldn't update on the game servers regardless of what I did. I could even create a new server and sync it with SourceBans, and that user wouldn't receive any permissions. However, I was able to create new users with a different SteamID and the changes would work instantly.

Regardless of the steps I took, specific users just didn't update. Shutting down the server, deleting the user from the configs, changing flags on SourceBans, and restarting the server would result in the admin being loaded with a setup different from what I specified, usually the previous setup that I deleted. As one might imagine, this should have been impossible.

Since I wasn't able to fix the issue within SourceBans, I looked at the tables in phpmyadmin. What I found was, aside from a few duplicate "aid" entries (didn't believe that was possible), was that the srv_group entries were correct, but didn't match up with the "group_id" of sb_admins_servers_groups. I had numerous entries referencing a group_id that didn't exist anymore. For example, prior to manually fixing the columns, I would have had "id" entries of 2,4,7,13,14 but the entries for "group_id" would have been 2,3,4,7,8,11,12,13,14. The users that were not updating correctly used group_ids that didn't exist anymore.

I manually reset the group_id, srv_group_id, and server_id for all entries in sb_admins_servers_groups. The last two were mainly due to a few oddities, probably due to entering a user in incorrectly. After everything was confirmed functioning normally, I also went back and re-ordered all of my groups and admins to be sequential, just so I can narrow down a future issue if it occurs. But the group_ids were either due to a bug in the script in a previous version or perhaps an error being thrown when executing a query leaving it unfinished.

[Horsedick]

While I'm thinking about it...how do you select one person/admin to send ban submissions too?

[GunSpeed]

Tried searching, after reading the sourcebans FAQ :

"You should always check beforehand, if your gameserver banned your webserver's ip with listip in rcon. Remove it from the banned_ip.cfg and removeip IP via rcon."

I was wondering what is the cause of that ban in the first place? Since that was my problem and recently too!
Thanks!