Opened 3 years ago

Closed 3 years ago

#1207 closed defect (fixed)

TWDOpBot IP/MID/NameWatches not working

Reported by: Shadowmere Owned by: milosh
Priority: high Milestone: milestone:
Component: Bots - TWD/TWL Version: Latest version from repository
Severity: minor Keywords:


(TWD) Staff's chat bot fails to alert the different notifications.

While a staff member can do !IPwatch !MIDwatch !namewatch and the bot recognizes these with:

TWDOpBot> Login watching enabled for 'IP'/'MID'/'Name'

it never alerts despite these IPs, MIDs or Names logging in to the zone.

Change History (3)

comment:1 Changed 3 years ago by milosh

  • Owner changed from WillBy to milosh
  • Status changed from new to assigned

comment:2 Changed 3 years ago by milosh

milosh> ?messages

[Jan 11 14:43] Shadowmere: While you try to figure out different watches on TWDOpBot, can you recheck the !addnote player:.. and !listnotes playername commands please? OpBot started confusing the two giving back "format.. notes is id:note..." when using !

comment:3 Changed 3 years ago by milosh

  • Resolution set to fixed
  • Status changed from assigned to closed

I've taken a look into this and it seems it was caused by r8132 which was an attempt to eliminate duplicate entries into tblAlias since the code for twdop directly copies

It seems that since the code it a direct copy it also copies the checks in place to prevent duplicate entries. As the code stands, it seems to allow or desire duplicate entries for a single user should that user have multiple IPs/MIDs/names. That is how it detects alternate machines and thus whether a user is cheating by playing under a new name on a known machine. Obviously that would be a lot of duplicate entries for some users and a dense table in general for the population we have. I'm not sure if that's what initially caused alarm about this code, but either way the duplicate SQL calls are not needed since the pubhubalias already makes them. However the watches are utilized by the TWD Op staff in the TWD Op staff chat, so placing those back should suffice.

Perhaps further discussion about these SQL calls and whether to refactor this code should be had here. For now I will close the ticket.

Note: See TracTickets for help on using tickets.