Turn off the retarded spam/flood filter
Moderator: Moderators
Thats because since altaric decided to fork TASClient he's had the license to go and do more changes than he would do in a patch which have shown....
There was one person who contacted me in the lobby talking about adding stuff into the main server like proper XML stuff and logging instead of what is in there now, and that he'd gone a lot of the way already. Odd he and his code disapeared....
There was one person who contacted me in the lobby talking about adding stuff into the main server like proper XML stuff and logging instead of what is in there now, and that he'd gone a lot of the way already. Odd he and his code disapeared....
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
No, cleaning up dirty code can sometimes be easy, but it often requires a rewrite. If it's something small like bad naming conventions or bad commenting then ya, that's pretty fast to fix, but if it's something like inappropriate class and method structures then all the crap code has to be thrown out. Functionality is somewhat deceptive. If you gain functionality by ditching modularity you really aren't ahead at all.Forboding Angel wrote:and it would take a whole heck of a lot of work for betalord to clean up altarics code? If that is indeed the reason... THat's absurd, the work is already done for the most part.
Theres a difference between proof of concept patches and perfectly working patches and I must say that 90% of the patches we (engine developers, but it'd surprise me if it was any different with patches to lobby server / TASClient) receive are closer to proof of concept patches then to working patches.
A perfect patch requires a dev to read once through it, notice it's fine, apply, test & commit et voila, another feature added / bug fixed.
A proof of concept patch needs hours of rewriting (like the rotating buildings one, JC spent over 3 hours hand applying it) / bugfixing, discussion with the writer, etc. Usually it is only a little bit faster as implementing it yourself from scratch because it doesn't much more then giving you hints as to where certain code must be modified, but at the same time it's much more boring work to do.
So let me make my point clear: do not just write a patch, but review it yourself, test it, fix it, review it again, test it again, polish it, test it again, and only submit it after having done all that!
A perfect patch requires a dev to read once through it, notice it's fine, apply, test & commit et voila, another feature added / bug fixed.
A proof of concept patch needs hours of rewriting (like the rotating buildings one, JC spent over 3 hours hand applying it) / bugfixing, discussion with the writer, etc. Usually it is only a little bit faster as implementing it yourself from scratch because it doesn't much more then giving you hints as to where certain code must be modified, but at the same time it's much more boring work to do.
So let me make my point clear: do not just write a patch, but review it yourself, test it, fix it, review it again, test it again, polish it, test it again, and only submit it after having done all that!
- Drone_Fragger
- Posts: 1341
- Joined: 04 Dec 2005, 15:49
howabout instead of removing the spam filter, It checks to see if you are just saying the same thing over and over, such as: "SPAM SPAM SPAM LOL SPAM" And then if you are, it kicks you. Otherwise, it ignores you. That way, people doing perfectly legitimate stuff (like stories etcetc) won't get punished by the autoban for spamming.
- Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
Or you could just make your own lobby server without spam controls to have storytelling time on.Drone_Fragger wrote:howabout instead of removing the spam filter, It checks to see if you are just saying the same thing over and over, such as: "SPAM SPAM SPAM LOL SPAM" And then if you are, it kicks you. Otherwise, it ignores you. That way, people doing perfectly legitimate stuff (like stories etcetc) won't get punished by the autoban for spamming.
- Felix the Cat
- Posts: 2383
- Joined: 15 Jun 2005, 17:30
- SwiftSpear
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
It's probably best to do this as well as have the current spam control. Have the client that we distribute spam control enough to keep people from getting them selfs auto banned and help keep the channels a little cleaner, while at the same time if someone comes on with telnet or a custom client and decides to try to spam us then server says "screw you" and bans their asses like it does right now. At least that way we don't accidentally have people getting them selfs banned just because they didn't know there were spam restrictions, and people who do get banned we can leave banned in pretty good faith knowing that they were doing something malicious because they had to intentionally modify the connection environment to post the amount of spam they did.AF wrote:or you could add the 5 or 6 lines to implement clientside spam control......
- Johns_Volition
- Posts: 134
- Joined: 05 Jul 2006, 21:17
To clear some things that came up regarding windows lobby:
Flooding protection works like this: if you sent more than 20 KB of data to the server past last 10 seconds, it will ban you. This has nothing to do with repeating chat messages etc. since I haven't written flood protection against that (that should be implemented lobby-side, not server) but serves rather as a basic protection against certain kind of exploitations. You can't easily reach this limit by just repeating messages in the lobby. Messages longer than 1024 chars are stopped at the server too (some error is sent back).
There are some open suggestions in mantis as well and I am working on it, but it is a lot of work so it's not possible to implement everything at once.
Flooding protection works like this: if you sent more than 20 KB of data to the server past last 10 seconds, it will ban you. This has nothing to do with repeating chat messages etc. since I haven't written flood protection against that (that should be implemented lobby-side, not server) but serves rather as a basic protection against certain kind of exploitations. You can't easily reach this limit by just repeating messages in the lobby. Messages longer than 1024 chars are stopped at the server too (some error is sent back).
Not true. The only patch for lobby I ever received was from Altaric, but since his code was messy I refused to merge it. That was for his host-bot. Later on, when he released his modification as a standalone (as I suggested to him), he started to make various other improvements. I did asked him a couple of times to send me the sources and I did implement some of his ideas, but it did mostly require a complete rewrite. I do try to keep lobby code clean and consistent as possible, and merging a badly structured patch can later on mean more work (with finding and fixing bugs due to inconsistencies) than to write it up yourself, unfortunately.AF wrote:Actually betalord ahs enver accepted a patch off of anyone, he doesnt want patchers. If he did then he'd have accepted at least 1 of altarics improvements.
I am wondering why don't you suggest those improvements to me then?smoth wrote:I can understand that. I was just thinking that for common everyday usage there are a lot of things that really should have been done to the lobby. However, it being written in delphi makes finding poeple to patch it hard. Something that shocked me when I found out about it.
There are some open suggestions in mantis as well and I am working on it, but it is a lot of work so it's not possible to implement everything at once.