Bans reasons issue:

[Stickly Man!]

So yeah, I keep seeing this come up in users bans.txt files..

http://pastebin.org/345719

Code: [Select]

"STEAM_0:1:17308570"   
      {
              "admin" "Console(Console)"
              "unban" "0"
              "time"  "1276791632"
              "name"  "[TF59] Sune"
              "reason"        ""
      }
      "STEAM_0:1:20830870"   
      {
              "admin" "Console(Console)"
              "unban" "0"
              "time"  "1276801059"
              "name"  "snakefist"
              "reason"        "(\\ Magic word. Magic word. Magic word. Magic word. Magic word. Magic word. Magic word. Magic word. Magic word. Magic word. Magic word.\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\")"
      }
      "STEAM_0:0:12167254"   
      {
              "time"  "1276837701"
              "unban" "0"
              "admin" "Console(Console)"
              "name"  "Kewburrz"
              "reason"        "(\\\\\\\\\\\\\\\\\"I heer yew propspammmm\\\\\\\\\\\\\\\\\")"
      }
There's obviously some bug going on somewhere, but we should be on the lookout for this. I'm gonna ask the person who I got this from to ask his friend how exactly he banned them.. most people don't remember lol

EDIT: turns out they were using the release version when these two were banned... doing some testing on my own server

EDIT2: ah-ha! (In release version 3.40) If there was a \ typed in the reason (tested in console), it had a strange output on the bans.txt. Will test on svn revision soon.

EDIT3: I never post useful information on a third edit!

EDIT4: Tried a bunch of various ban reasons with crazy \ and " and stuff, and ULX svn handles it quite well.. except this one:
ulx banid STEAM_0:1:2222 2 I LIKE \ aspa"3"@#4@" 5\23"%2\3" ragus!""\\"

--It seems, as long as the reason doesn't have 3 or more quotes, it works okay. Don't know if we should worry about this or not

[Stickly Man!]

Unrelated, but new problem!

I was testing XGUI on Tommyo1590's server, and there were strange issues all around..
Basically, xgui wouldn't ever open for me because of the "Player not yet Authed" error. (In other words, ULib.ucl.authed table was empty)
It turns out that the reason he couldn't see any groups in XGUI, or why URestrict wasn't showing anything either, was probably because we were getting some bugs with data between ULX/ULib from server->client wasn't being sent or anything. (7 minutes in, and I never got the authed table)

So, I had him do this:

- Rename his server gmod folder to something like garrysmod_backup
- Redownload gmod via HLDS, and then install ONLY XGUI, and svn ULX+ULib into the addons folder.

After that, we got back into his server.. and we were getting the same issues X|

So, even with a vanilla server, I think some of his problems are being caused by his server hoster, or maybe even some network settings? (Probably not since we did a full reinstall of gmod)

Looking at net_graph 3, I was getting about 250-270 ping--
and the lerp (whatever that is) was colored orange and showed 60.6 ms (where I see 66.7 ms on my ded server)


So, I have no idea what this means, or even if there's anything we can do about it. But Megiddo, if you want to go and check it out anytime soon, just let me know. We can get his ip/password and take a look.

[JamminR]

Re: \\ - Release version, known issue, mentioned time and time again amongst the forums.
It's actually more problematic with players with \\ in thier name than it is with reasons from what I've seen.
imo, Garry should stop making up his own lua rules, and find a legitimate way to filter actual comment -- strings that could be used in names/string input to lua.
No, it won't happen, but both -- and \\ just make it that much more difficult to filter manually.

Re: Unauthed player.
Datastream or sv_downloadurl seems to normally affect from what I've seen of other forum posts.
I'll let you/Megiddo dig deeper, but that seems to be the common issues causing that is improper. We're not forcing a datastream fix within our SVN code are we Megiddo? I know we had links/posts for how to fix one, but I thought Garry had made a release that fixed it already.

[Megiddo]

We were forcing a fix, but it was removed when Garry officially fixed it. I'll try to get in touch with you today about this Stickly.

[Megiddo]

Tomo's issue was that garry's new datastream is horrible. I'm not sure if it's in order or not anymore (the problem I originally fixed for him), but it's got a nice bug where sometimes data will get stuck in the datastream queue and can never escape. This means that nothing else will ever get processed as well. Ever! He made a cvar to increase the number of "jobs" datastream can process, but a side effect of the bug is that the stuck data will continually delete the rest of the data before it gets to the rest of the data... so lots of help that does.

The fix for this? Drop in the file I sent garry. Everything works 100%.

I can't believe it... of all the stupid things garry's done...

* Megiddo continues ranting to wall for 20 minutes

[JamminR]

Datastream or sv_downloadurl seems to normally affect from what I've seen of other forum posts.

Tomo's issue was that garry's new datastream is horrible.
<clip>

* Megiddo continues ranting to wall for 20 minutes

See? See? I DO pay attention.
Sure sure. It's selective, but if you make it geeky, I'm much more likely to pay attention.

*JamminR to wife* Wait. What were you saying dear?

[Megiddo]

Nice catch, JamminR. I didn't even think of datastream at first (thought it was fixed, foolish me).

[Megiddo]

I included our own pared down, working version of datastream in ULib. It can run side-by-side with the original datastream just fine. Our version shouldn't impact servers much, since I tried to optimize the code for efficiency wherever I could (default datastream just keeps the tick hook open all the time...).

Unlike our hook library which overrides the original hook library, I thought this was the better approach for datastream. If garry ever does decide to fix datastream, we can just hop back over to his, but until then we can remain in control of our data and ensure that it actually stands a chance of getting to our users...

[JamminR]

I included our own pared down, working version of datastream in ULib.

Back several revisions ago you changed from using datastream for all (most?) ULib(and therefore ULX) calls to the server to using (uh, concommands/umsgs?) not sure.
You decided to do this because people on active servers were having to repeatedly run the console commands to get the server to react.

So, now that we have our own;
1) Would it be wise to go back to using (our) datastream for whatever reason you decided to use it on the ULib rewrite in the first place?
2) Would we even need to change back to Garry's if/when he fixed it?

Mind you, I'm not even sure of the design or theory differences between what we had before the datastream switch back or before.

[Megiddo]

We stopped using the client->server portion of datastream, but we still use the server->client portion. Since the way we rewrote the client->server portion hasn't elicited any complaints since we went off datastream, I don't see any reason to go back to using it. And there's not really any reason for us to go back to the original datastream if garry fixes it except for the fact that the server now has two versions of datastream that both work... But at least we know our version would continue to work, where we can't be so sure about garry's.

[JamminR]

we still use the server->client portion

Actually, until now, this might be cause for many of our client side issues, no? (XGui, URestrict, few other ulx issues circling around the board.)

I don't see any reason to go back to using it.

My question then is - why did we try using datastream in the first place?
As long as we use ours instead of Garry's, and had a sound design before having to switch back to previous methods (because garry broke datastream), would ULib be better with datastream(ours of course)?

[Megiddo]

It might be the cause of all our client side woes, yes. We used datastream because I didn't realize what a pile of crap it was at the time, and there's really no reason for us to go back to garry's as long as our continues to work.