Ulysses
Ulysses Stuff => Suggestions => Topic started by: mNote on March 25, 2010, 07:20:07 PM
-
Hey there, ULX,
I am mNote and I am a user of the ULX/ULib admin tool and I would like to make a request for the ban menu.
I am an administrator of a pretty large community that have, over the years, gathered over 4,000 steam ids onto our banned_users.cfg file. Now, I know that ULX picks out information from this file because I have done several testings of importing this list and exporting it to the point where I know that ULX will fail to work if it has to read and format a very large file.
Personally, I am asking for a revised ban menu. A ban menu that stores only temporary bans, up to a maximum of maybe 6 digits in minutes (999,999) and no more. It shouldn't also grab the banned_user.cfg list because when that list has 4,000 steam ids in it, ULX will take a VERY long time loading and ULX will fail to work altogether.
I like the ban menu the way it is, but because it picks out perma bans from my banned_user.cfg list, I have to resort to banning by IP and starting the ban list anew.
If you guys can do this, I will greatly appreciate it. I'm actually in the process of finding a better ban management than ULX but I like ULX's interface so much that I'd rather start by asking here.
Please and thank you.
PS: You can find the community I belong to at SteamGamers.com.
-
Is it ULX that breaks altogether? Or just ULX's banmenu?
Have you tried using XGUI yet? (http://forums.ulyssesmod.net/index.php/topic,4080.msg18601.html#msg18601) I have a feeling that your banlist might be a bit too large to handle also (I've been meaning to find someone with a large banlist to do some testing).
If it turns out to take too long to process, I think I can easily add a feature that will limit the amount of processing, OR limit the bans shown. Let me know how it turns out!
-
Only the ban menu and the system. While it takes time to load all 4,000 steam ids into the menu, it won't kick players that have been previously banned. It also won't ban new users too when an admin utilizes the ban command.
If you were to try to view the ban menu, it will get stuck on the "Loading...." part and it will stay that way for a very very long time. I tried waiting it out and never reached the end.
If you would like a ban list, visit Steam Gamer's Banned page and download the permanent ban list.
By the way, the XGUI won't work with my GMod server because my GMod server runs the "Trouble in Terrorist Town" game mode. This doesn't allow players to use the spawn menu the same way sandbox mode does.
-
By the way, the XGUI won't work with my GMod server because my GMod server runs the "Trouble in Terrorist Town" game mode. This doesn't allow players to use the spawn menu the same way sandbox mode does.
-how does the spawn menu block affect XGUI?
-
Yeah, the spawn menu shouldn't affect XGUI at all-- in fact, XGUI is designed to replace ULX's current menu, so if ULX's menu works, then XGUI should too ;)
I checked out the banlist and tried it with XGUI on my server.. And here's what I found out:
With XGUI, we're essentially running into the same problem with ULX's menu. The problem isn't that there is too much data to 'process' (which I may add, the ban information from the banned_user.cfg ONLY includes STEAMID and time.. and since most of the times are 0 for permaban, there's almost absolutely nothing to process). The problem is when the server tries to send all of the ban information to the clients. ULX sends it when you open the ban menu, XGUI sends it when the player joins. However, since there is so much data to send, garrysmod calls an "infinite loop" on it, and cancels the function, so it never finishes (thus, both XGUI and ULX's ban menu don't get the message that all of the ban information has been received, so it sits on a loading screen).
I am currently planning a fix for XGUI-- The server will split the banlist by ULX bans and source bans, and will then send the ULX bans, and the source bans IF there are 50 or less source bans. If there are more than 50 source bans (or in your case, a couple thousand), then it will enable an option on the clientside XGUI to retrieve and view the source bans if/when needed. (I'll have to use a more reliable chunk method of sending the information, to prevent garrysmod from infinite-looping-- and I'll do it in a way that it shouldn't block use of the rest of XGUI).
Does that sound good to you? I'll probably be able to have this fixed up and released sometime tomorrow.
Also, because XGUI is very soon going to replace ULX's default menus, there will most likely be no planned fix for the normal ULX menu, so if you're getting any lua errors or issues opening XGUI, let me know!
-
Ah, that sounds very promising.
I guess I will download and try out XGUI and see if I can properly make it work on my server.
Thanks for the attention and help guys, I appreciate it.
I might need some help getting XGUI to work on my dedicated server.
I dragged the 'lua' folder into my "orangebox/garrysmod/addons/ulx/" folder and then restarted my server. After that, I went and reloaded the new "cache/dua" files onto my FastDL server and gave the server another restart.
Once I get into game, I type in !xgui but it says XGUI is a nil value. I also type in "xgui" into the console and it comes back to say "xgui is an unrecognized command" or something close to that.
-
Hmm, for now XGUI is in an addon format, at least, until it's actually included with ULX.
You should be putting the files in the folder addons\xgui\lua, and make sure the addons\xgui\info.txt is there too. Hope this helps!
(Also note that XGUI probably won't open properly because of the ban menu. You can run 'xgui getdata maps' in console if it's stuck at the loading screen to get XGUI to open, but, there will be some missing information and other minor issues.
-
Hmm, for now XGUI is in an addon format, at least, until it's actually included with ULX.
You should be putting the files in the folder addons\xgui\lua, and make sure the addons\xgui\info.txt is there too. Hope this helps!
(Also note that XGUI probably won't open properly because of the ban menu. You can run 'xgui getdata maps' in console if it's stuck at the loading screen to get XGUI to open, but, there will be some missing information and other minor issues.
Ah, thank you. I'm in the processing of getting a 2nd server so I can do GMod lua script testing on it. I'll be sure to give your XGUI a try on that new server.
By the way, I'm still eager for the revision to the current ban systematics.
-
I'm workin on that right now ;D
I had a few things come up today and I haven't been able to work on it yet. I should technically have it done in a couple hours, but.. I usually end up running into some unforseen problems, so.. we'll see how it goes :P
-
And wow, how it doesn't go! :o
I've ended up recording a rather large portion of how XGUI sends/receives data from server to client (and has a progress bar now!) The good news: It works! It's able to send the huge banlist in roughly 10 seconds (along with about 200 detailed ULX bans I added for testing). The main XGUI portion will still be usable while the bans are being retrieved. Bad news: I'm not quite finished, there's quite a few bugs to work out and things I need to finish up due to the recode. Also, for some strange reason, the bans won't send ANYTHING until about two minutes after they're first requested (after they send that first time, it works fine afterwards if you re-send the information).
So, I'll keep working on this tomorrow, hopefully I'll be able to have this ready in a day or two ???
-
Take your time, Stickly Man. I'd like you to make the script as perfect and polished as possible, as not to create further issues. It sounds like the amount of work you're doing is starting to produce great results. Keep it up, and thanks for your trouble.
-
No problem 8)
Everything's starting to turn out quite a bit smoother! I got all of the code fixed up for the new data receiving method (it has a progress bar to show you how much data has been sent!! ;D), and was able to get all of the bans showing up. Fun fact: DListViews do not like having 4,000+ items in them. Not only do you get < 15 fps, the whole menu literally explodes with graphics glitches! It was great fun! Anyways, so I'm going to do two things: 1) I'm going to have a completely seperate popup-window to show the source bans (and limit it to say 50 bans per 'page'), and 2) I'm going to add a filter to the main ban window where you can show/hide permabans. (I just got this done, actually)
Besides making the seperate ban window, there's one last major problem to fix (that's partly ULX's fault) before I can push an update. For some reason, with a very large ban file, something MAJORLY slows down-- to the point where you have to wait about 2 minutes before data even starts to send (only the first time though, if you try re-sending the data later it's no problem)
I'm pretty sure I can push the release sometime tomorrow (even if we don't get that last bug fixed-- you'll just have to wait a bit for the data to send until we can get it fixed, but everything else should work fine)
-
Aannnd now school will be taking up most of my time for a while :(
I'm going to double check and make sure that there aren't any major bugs in the code, then I'll send you a PM with my latest version. I think it has a couple unfinished things and just a couple of bugs (one of them being the wait 2 minutes before data starts sending thing), but other than that, it should be working fine.
-
<darn responsibility getting in way of hobby><stuff>
the wait 2 minutes before data starts sending thing), but other than that, it should be working fine.
I'd be curious to know if this was just an issue with the server side code actually taking that long to sort 4000+ bans, or if Garry's code has some issue that takes it that long unnaturally. (Or, are you using server side ULib lua commands which don't touch Garry's gmod lua?)
-
At the moment, I have commented out every part of the ULX code that has banned_user.cfg in its line of text.
So far, it runs just fine and I am still able to permanently ban players off my server... sort of.
But, I would actually like a cleaner version of it since I had to break into the mod in order to modify it.
-
@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 :P
-
<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.
-
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? :o lol
-
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.
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
-
Hmm.. I see. ;D
Of course, depending on what the actual problem is with the large ban files.. this might be changing a bit ???
-
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.
-
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.
-
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)
-
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...?
-
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
-
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)
-
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...
-
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..
-
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?
-
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?
-
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?
I will try this and update this post on how it turns out.
Usually, I just drag the 'dua' folder onto my desktop and then drag it onto my FastDL server. I had assumed that the whole entire cache gets updated every map change since it says the files were modified around the same time the map changes.
Edit ----
Unfortunately, this did not work. It's still making me redownload some lua files and whatever is downloaded is getting blocked.
Edit 2 ---
Also, I'd like to make a request to go back to the basics of my first post. It's been 2 weeks since I made this thread and the progress of it has been slow. I appreciate all the help, but I think it would be quicker if the original ULib and ULX be recoded to fix the ban mechanics rather than introducing me to XGUI.
-
--And now it's fixed! ;D
We finally got some free time today, and I gave Megiddo your bans file to work on. The ban system is now MUCH more optimized, and can now process all of the bans in about ~3 seconds. The ulx banmenu, however, gets overloaded with all of the bans, and doesn't show anything at all (while making things run very slow).
As per your original request, XGUI supports listing of permabans and temporary bans all in one spot, with the bans from banned_users.cfg in a different spot.