Provider info_Configuring your list

Step 4: Configuring your list in list.lua

The list.lua file contains a table of "case data", where each case records an incident that occurred with a scammer.

Cases

A case is a small table of data summarising an incident that took place; which player or players perpetrated the scam, what type of scam was perpetrated, and a url pointing to the evidence that led to the player being listed.

The evidence url is absolutely vital in establishing trust.

A given scammer can be related to multiple cases, and Scambuster will appropriately collate the data when it constructs its database, and present a full history for each listed player that the addon user encounters, in accordance with their preferences.

Example implementation

There is some flexibility afforded in how each case can look, for example:

list.lua

local _, t = ...
t.case_table = {
    -- The below are all valid configurations.
    [1] = {
        name = "Arthas",
        guid = "Player-some-guid123",
        category = "raid",
        description = "Got a bit too upset at demons and had a strop.",
        url = "https://wowpedia.fandom.com/wiki/Culling_of_Stratholme",
        class = "DEATHKNIGHT"
    },

    [2] = {  -- if the GUID is not known, can just give the name
        name = "Sylvanas",
        category = "harassment",
        faction = "Horde",
        url = "https://wowpedia.fandom.com/wiki/War_of_the_Thorns",
    },

    [3] = {
        name = "Gallywix",
        description = "Did not honor payment for boat travel services.",
        url = "https://www.wowhead.com/guide/story-goblin-starting-area-lore",
    },

    [4] = {
        players = {  -- Useful when multiple scammers are linked to an incident
            [0] = {
                name = "Deathwing",
                guid = "Player-some-guid345",
            },
            [1] = {
                name = "Ragnaros",
                class = "WARLOCK",
            },
        },
        category = "trade",
        description = "Caused quite a large Cataclysm.",
        url = "https://wowpedia.fandom.com/wiki/Cataclysm_(event)",
    },
}

Required fields for each case

The always required fields for each case are:

• name: the name (or last known name) of the scammer.
• url: a link to the url of the evidence against them, usually a thread/message/channel on discord.

Additionally, at least one of the following two are additionally required to help Scambuster provide useful chat broadcasts when a scammer is encountered.

• description: a short description of the incident, what type of scam was perpetrated, etc. The description should be no longer than 250 characters long to conform to WoW's chat restrictions, and ideally shorter.
• category: a category, should be one of "dungeon", "raid", "trade", "gdkp", "harassment". If none of these, is ignored.

Optional fields for each case

The following fields are optional, and can help Cutpurse better track scammers, and help your users tailor their experience using the addon more closely:

• guid: the player's GUID. This is highly recommended to include, as paid name changes retain the same GUID. This will also stop a false-positive from pinging if a scammer renames and someone else takes up the now-vacant name.
• class: the player's class, in allcaps, no spaces English, e.g. DRUID, DEATHKNIGHT, WARLOCK etc. For more info see: https://wowpedia.fandom.com/wiki/API_UnitClass
• faction: the player's faction. "Horde" or "Alliance".
• aliases: an array of the previous names the scammer has gone under.

Suggestions

• Use categories. These allow the user to specify what types of scam they wish to be forewarned of. For instance, someone might not care when recruiting for a raid GDKP that someone ninja-looted a dungeon epic. Categories allow for greater customisation of the addon user experience.
• Use short, to-the-point descriptions. Walls of text in the chat channel can be easily glossed over. Condense the necessary information as much as possible to ensure an alert is easily processable by the addon user and their party.
• Where possible, use GUIDs. These are a much more powerful matching tool than a player's name, and can completely negate the risk of a false-positive alert.