Staffbot changes; Store ?bans, aliasing, long-name fix

Bump… Rudy wants this ASAP????

Replying to RiiStar:

Bump… Rudy wants this ASAP????

Do you know which in particulair?

To verify, are these the two things remaining to be implemented?

- "Long name fix". If a staffer looks up aliases for a partial name, check for potentially similar names. I assume this means that if and only if a staffer checks for a 19-character name, StaffBot should do a query that looks for names that are 20-23 characters long and start with those 19 characters. Is that right? Just want to make sure to be exact before implementing something that is not what's desired.

- Expired warnings — drawing the line between expired and non-expired. Is the limit 1 year for all warnings? This one should be easy if the warning types all expire at the same time. Could actually have it display only warnings within the time period with the normal warning lookup command, and then have a secondary command for checking all logged warnings if someone has a need. Or, this could be a toggle, defaulting to displaying only those warnings that are still valid.

(Oops, was editing exactly as Mav was as well. Disallowed me the first time.)

Mainly it crashing when looking for users with " in names sql breakage ftw…

Maybe our addSlashesToString method in Tools is buggy …

StaffBot runs on Queen, right? All we need to do is consult the Queen exception log on this one. We can go from there. Guessing it's a malformed query, and so the ResultSet is null, which can never occur if the query is made properly, resulting in NullPointerException. But the only reason the query would be malformed by using a certain character in the query name is due to our addSlashesToString support method being faulty.

If you see him could you ask Rudy about the other two things?

dugwyler;

As far as I know, all the things mentioned still need to be done.

- long name fix: yes, exactly what you said but maybe make it a bit more intelligent. If I do !warnings abc, the bot should return a list of found users (if too much only the first 20?). By the results you can then narrow your search or already copy/paste the correct name you're looking for.

- Expired warnings: yes, as you said but warnings expire after exactly 2 weeks (14 days). Only displaying the non-expired warnings would be very nice (and a command to display the expired warnings).

Staffbot runs on RoboQueen. If you say the crashing problem with " in the playername might be caused by addSlashesToString we should check which version is currently on RoboQueen to make sure this wasn't already fixed.

that was me :x

2 weeks? Things have changed a lot!

I have the long name completion in as well as suppression of expired warnings. This one will need to be tested — can it be run on King? Either that or we can wait until Queen can be updated and test it that way.

hm better would be if you would be able to test it on your computer? You can connect to the TW Dev zone and I can email/PM you the connection details to the test database on twcore.org ?

In expired warnings I mean they are still valid to ban for, maybe you mean something different?

Oh, nope, same thing. I just seem to remember a while back that the allowable time was much longer on TW.

It would be better if I could test it locally, I agree. But again, I'm just not going to do it for these small kinds of changes. I don't enjoy that aspect of development at all, especially when we're talking about fairly straightforward, simple changes that don't have a very large effect and could be easily fixed. If there are problems, there are people who are perfectly capable of identifying and fixing them if I'm not around — just as if someone else is not around and I am, I can fix up their code if needed.

I recognize the necessity for testing new standalone bots, but I promise you in no uncertain terms that if it comes down to coding and testing these little fixes, or not coding them at all, I will choose not to code them, and will work on personal projects only. It's your right as maintainer to demand that they are tested — but you need to take a stand one way or the other. If you decide they must be tested, make that a requirement; if you decide that while it's a good thing to test them but that it shouldn't be required, make it a recommendation, but please don't encourage me to do it. I don't have the time to test code for Subspace. It's a waste of the most valuable human commodity. In the end this game is just not that important, and deep down we all know this. Who gives a shit if a particular system is down for a day and a half? Someone won't get banned? The repercussions of a fault are extremely minimal; the extra time it takes to test, though generally small, is absolutely unacceptable in comparison to the risk associated with failure.

You're welcome to argue with me here, but I absolutely will not budge on this issue. Again, should you decide to require testing, I will be happy to resign myself solely to personal projects.

dugwyler, I agree with most of your post and my post about testing was never meant to get you on your bad side.

Yes, I should make a decision about this (I haven't yet) which would be to test anywhere possible but is not a requirement.
The only thing I want developers to do is to run a simple test if the new feature(s) they just built are working, not anything more complex then that. This prevents that if the bot goes up it doesn't crash on spawning or on the command for just a simple NPE.
However, as I said it's not a requirement. On the other hand, if you don't test it will take longer for the feature to be completed and cost more time and energy of the other developers including me who have to explain that it isn't working yet and they have to create a ticket (or post a comment) to get it fixed.

From what I remember this one is done.