Ban Menu revision request.

[Stickly Man!]

@JamminR
It's definately server side, I *believe* it's part of ULib-- then again, while ULib is first loading, it gets the infinite loop error while processing bans (which makes me wonder if all of the bans are even getting through in the first place).

But, XGUI sends a function via ULib.clientRPC to the client to let it know that some data is coming, then XGUI loads all of the clientRPC functions to send "chunks" via ULib.queueFunction(). Then it waits..

I haven't had time to test, but I believe that something on ULibs side is clogging up the queueFunction's queue because of all of the bans-- A simple test would be to use a timer to send run each clientRPC call after a set amount of time (say 0.1 or 0.2 seconds)-- or maybe try ignoring the timer altogether and call all of the clientRPC functions at once (which MIGHT be a bad idea based on how it's coded, plus garrysmod might throw the infinite loop error again)

All I need is time! (to help Megiddo hunt the bug, so Megiddo needs time too!) 

@mNote
Oh yeah.. that's right, adding bans might not work. What do you mean by "sort of" permanently banned? I believe ULX doesn't store any bans via source bans list, so technically that should work..

We'll try to get a fix as soon as we get some time 

[JamminR]

<stuff>ULib.clientRPC<stuff>
I believe ULX doesn't store any bans via source bans list, so technically that should work..

We use Gmod RPC..and, I believe it's like network vars....slow to synchronize upon server join/start.
I don't have links / solid memory to show where/what little I remember of that though.

Also, ULX does indeed use source bans list.
Any perm ban you do gets writeid afterwards, and exec'd at server startup.
Source itself doesn't store temporary bans to a file..which is why a 'ulx' bans.txt was created.
 It will (when working) store temporary bans across server sessions unlike Source.

[Stickly Man!]

Hmm, I was under the impression that all ULX-related bans were stored in bans.txt because sourcebans can't store data such as time banned, banned by <admin>, etc. which ULX is able to retrieve for any ban-- The only thing ULX does with the bansfile is write temporary (or permanent if the ulx ban is perma) banids based on the bans in bans.txt, then adds all of the existing bans from the banned_user.cfg file to the table of active bans on the server.

Did that make sense?  lol

[JamminR]

ULX does store all bans in bans.txt (perma and temp)
However, every server start, if Source's /cfg/banned_user.cfg exists, ULX loads it into memory. (exec)
Every ULX ban uses ULib.addBan that also loads the file, and then, for even more sanity, updates it (writeid) when a player is banned.

Code: [Select]

function ULib.addBan( steamid, time, reason, name, admin )
if file.Exists( "../cfg/banned_user.cfg" ) then
ULib.execFile( "../cfg/banned_user.cfg" )
end
game.ConsoleCommand( string.format( "banid %d %s kick\n", time, steamid ) ) -- Execute NOW
ULib.queueFunctionCall( game.ConsoleCommand, "writeid\n" ) -- Write to file when old bans are done loading

... lots of other code regarding the bans.txt, temp time, admin, reason, etc ...
end


[Stickly Man!]

Hmm.. I see. 
Of course, depending on what the actual problem is with the large ban files.. this might be changing a bit 

[mNote]

Question:

What do you mean by source bans? Are you speaking of the ban mod that is built for Source Mod or are you talking about the server's banning system?

I actually am not using SourceBans to moderate my bans at all. I'm just using banned_user.cfg, banned_ip.cfg, and ULX bans.

Almost all of my bans are being issued via IP because STEAMIDs can be replicated with some sort of GMod hack that's been used a couple of times already on my server.

[JamminR]

Source in this case relates to normal Source server banning, not SourceMod
ULX, release and SVN, use SteamIDs and the related config (banned_users.cfg) files to load and write on every ban.

[Stickly Man!]

Your "source bans" would be the banned_users.cfg, the 4000+ that you got from SteamGamers.com, and any other bans are stored in ULX (and as JamminR mentioned, also partially stored in the banned_users.cfg file-- it's confusing lol)

[mNote]

This is very frustrating. I can't get XGUI to work on my server at all.

I don't know if it's a common problem or not, but I placed the 'xgui' folder into the 'garrysmod/addons/' folder as stated in the installation direction. The new 'cache/dua/' folder is also uploaded onto my FastDL server, but it still makes me DL these files that I never get, even when I place these files onto my FastDL server.

While in-game, I open up my console and notice that SE blocked 'xgui_client.lua' and that it is a nil value. I technically never got the file so I thought I had to upload it onto the FastDL server. Still doesn't work.

I'm assuming that I have to create a new scriptenforcer manifest file somehow on my dedi, so that I can use that to run as the new scriptenforcer.txt.

Any ideas...?

[JamminR]

You know that xgui has to be installed on the server side gmod/addons too, right?
From your description, it sounds like you just installed it all locally, then just uploaded it to your fastdl.
Also, make sure you're copying your SERVER's gmod/cache folder after a restart of it to the fastdl, not your local client.

I'm assuming that I have to create a new scriptenforcer manifest file somehow on my dedi, so that I can use that to run as the new scriptenforcer.txt.
Any ideas...?

Absolutely, anytime you update the server with code that runs on client too, you have to update the manifest for script_enforcer.
See the "generating" category of the gmod wiki article for best way to do it.
http://wiki.garrysmod.com/?title=ScriptEnforcer

[Stickly Man!]

Ah yes, XGUI only needs to be installed on the server-- you can install it on the client if you want to (usually only if you want to be able to use it on servers that don't have XGUI installed)

As for the scriptenforcer, it sounds like you installed XGUI correctly, so I'm guessing that might be causing the problem.. Don't know much about it though.

(You can probably now ignore the PM I just sent you lol)

[mNote]

You know that xgui has to be installed on the server side gmod/addons too, right?
From your description, it sounds like you just installed it all locally, then just uploaded it to your fastdl.
Also, make sure you're copying your SERVER's gmod/cache folder after a restart of it to the fastdl, not your local client.
Absolutely, anytime you update the server with code that runs on client too, you have to update the manifest for script_enforcer.
See the "generating" category of the gmod wiki article for best way to do it.
http://wiki.garrysmod.com/?title=ScriptEnforcer

XGUI is installed server-side, not locally. Cache is updated onto FastDL (dua folder).

On join, it says I am downloading XGUI files but it will keep saying that every time I re-join, which leads me to believe that I never got the files.

I also tried to create a new scriptenforcer file but it won't run...

[Stickly Man!]

That.. is very strange.. have you tried disabling scriptenforcer completely and see if it works? Otherwise I can't think of anything that might be the cause..

[mNote]

That.. is very strange.. have you tried disabling scriptenforcer completely and see if it works? Otherwise I can't think of anything that might be the cause..

Yes, I even tried that. I honestly think it has something to do with me retrieving the files onto my own computer, or something stuck on the server that needs to be gone. Maybe I need to delete something to refresh some kind of data for XGUI to reproduce?

[Stickly Man!]

I have no idea.. have you tried clearing the garrysmod\cache\dua folder? You mentioned something about 'updating' it, maybe try removing the folder completely and let the server rebuild it?