Spring RTS Engine

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....

That sucks. Oh well we lose on the features. Maybe BetaLord will see it in his magnanimous heart to give them to us.

Im glad he didnt. Altacilents to buggy for my tastes.

It isn't a matter of buggy or not. Betalord should be proficient enough to implement those features. That is what sucks about him using delphi and not something more known like java.

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.

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.

but it also can give you a good idea of how something may work out.

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!

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.

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.

Or you could just make your own lobby server without spam controls to have storytelling time on.

or you could add the 5 or 6 lines to implement clientside spam control......

AF wrote:or you could add the 5 or 6 lines to implement clientside spam control......

Which could be circumvented, which means that the server-side spam control is still necessary.

Anyone who is setting off the automatic spam flood thing must be doing a really good job of spamming! I'm just saying this because I repeatedly use clue in #trivia, and I've never been booted.

it's not n# messages, it's volume of traffic.


Also, the people most likely to spam channels, are the people most unlikely to know howto alter and circumvent the restriction. It's a safe bet that 90%+ of flooders dont know how to program, nevermind navigate the maze that is compiling TASClient.

AF wrote:or you could add the 5 or 6 lines to implement clientside spam control......

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.

Felix the Cat wrote:Which could be circumvented, which means that the server-side spam control is still necessary.

Not by 90% of people who flood

No no no no, I don't mean on the lobby, I mean on this forum.

the 'you have to wait 1 minute before you can repost'?
I agree. It's painful as hell if you want to edit your post because you found a typo or whatnot, but the board refuses cooperation.
+1

Caydr wrote:No no no no, I don't mean on the lobby, I mean on this forum.

ROFL!

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).

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.

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.

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.

I am wondering why don't you suggest those improvements to me then?

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.

The forums teeming with suggestions, entire threads dedicated to listing them...

Although I dont remember credit being given to altaric for any improvements that may have crossed over, and I too have asked to see altaclient code and gotten a yes many times yet I havent seen a single line......