Forum:Incorrect Charm log submissions

Forums: Yew Grove > Incorrect Charm log submissions

Charm logs can be manipulated easily. Suggestions which differ too much from the given rates should automatically warn an administrator before processing. I have just killed some KBDs, and noticed that most of the charms were crimsons, yet the following revision (anonymous user, 100 kills...?) shows a whole different pattern: by 82.150.129.253 at 10:28, June 7, 2011

This is an obvious example of a deliberate false submission, which could have been avoided by implementing a system which automatically warns administrators when a very different charm submission is submitted.

Additionally, some monsters drop multiple charms. Players who maintain a drop log may add the number of drop occurrences instead of the amount of charms. For these players, a notification would be handy. For example:

Notice: Your submission differs from the known data. Please check your submission

• Did you enter the amount of dropped charm instead of the number of charm drops?
• Did you make a spelling mistake?

Current data:

<table of current information (+droprates)>

Your submission:

<table of submission (+droprates)>

If you believe that your submission is correct, click here:

Save page

User:Mugger759/Signature 11:27, August 5, 2011 (UTC)

Discussion

We already have a system like that. We have a automated script remove any likely incorrect entries when the submissions are moved to the log in the charm namespace, which is where we get the percentages used on the articles from. Sentra246 11:33, August 5, 2011 (UTC)

The rates of the charm submission (mentioned at the first paragraph) were way off, yet still processed. User:Mugger759/Signature 12:02, August 5, 2011 (UTC)

It was processed and shown to be inaccurate, so it was never added to Charm:King Black Dragon. Sentra246 12:06, August 5, 2011 (UTC)

Oh. I did not know about that feature yet. I was looking for the cause of the very different drop rates. I also maintened a private droplog of the KBD, and I hardly ever get not charm. My second suggestion still remains: Warning users of the difference between the drop occurences and number of charms (I once added a wrong charm sumission of 2k+ Corporeal beast kills. If I didn't check my edit, the wrong submission would be processed).User:Mugger759/Signature 19:46, August 5, 2011 (UTC)

Comment - a quite short while ago, I made a change to the charm drop submission tables on the /Charm log pages, to show all current data in green above all other submissions. The submissions can be compared to that data by antivandals, and when it differs too much, the edit can be undone or reverted. Also, the bot that moves all submissions to the actual charm logs checks if the submission is reliable, and moves it afterwards. There is currently not a big problem with the system, and (almost) all vandalism is filtered out just after it's submitted. JOEYTJE50TALK pull my finger 12:05, August 5, 2011 (UTC)

Oppose - Abuse filter already checks for a lot of typical charm log vandalism. And joey's percentage thing is also in place. In any case, I don't think it's a good idea to warn users if their submission is off. I don't even think that's it's possible. It's a nightmare trying to fetch parameter values in abf, and it's not possible to check it with existing data unless both are on the same page. The problem with checking for "off" values is that, quite honestly, many of our charm logs are wrong in the first place. For monsters which have different level varieties in different locations, we use the same charm log submission page. We don't know if they have different charm drop rates or not. I've been thinking about proposing to scrap some charm logs like this and start over completely, but many other more important things should come first. The more popular charm logs are succeptible to more vandalism, that's true, but we should really let a human do the checking. Amauricebot is in general pretty good at determining which entries should be added, though it seems to bug when commas are entered. I would find the diffs, but it's kinda hard to do so on my phone. Basically, what we have now is fairly sufficient, and the sheer amount of effort required to make this proposal work is not worth it. Suppa chuppa ^Talk 23:49, August 5, 2011 (UTC)

Notice of intent - If there is no further activity in 3 days, this will be closed. Suppa chuppa ^Talk 13:58, August 10, 2011 (UTC)

Consider the second suggestion, regarding the Number of charms versus the number of drop occurences. It's a very common mistake, especially if you have a look at the charm logs of monsters with multiple charm drops. Either that, or a very obvious message at the charm submission pages of monsters with multiple charm drops.User:Mugger759/Signature 15:49, August 10, 2011 (UTC)

While it may be a good idea, I have absolutely no idea how to implement that with the abuse filter. That being said, it already highlights the row if the total number of charms for each type is not a multiple of the amount dropped at once. Suppa chuppa ^Talk 18:21, August 11, 2011 (UTC)

I'm not skilled at programming in wikicode. My suggestions shouldn't be hard to implement though. Like:
IF (charm drop rates are way off AND {{#var:perkill}} > 1) THEN {/*Add a message to the table*/ Your charm submission seems unlikely. Did you take into account that {{#var:perkill}} charms are dropped a time? }
Could you translate that to wikicode?User:Mugger759/Signature 17:58, August 12, 2011 (UTC)

This would not be possible with wikicode, but what you are proposing with a message stopping them would more be an abusefilter. If you do want to do such things with wikicode, you'd need {{#ifexpr:calculation|if true|if not true}} but that won't be able to appear as a message when it is true. It will still submit the edit anyway. JOEYTJE50TALK pull my finger 08:56, August 16, 2011 (UTC)

Notice of intent - Does anyone skilled with wiki code want to take a crack at this? Otherwise, it is going to be closed. --Liquid^Talk 19:17, August 15, 2011 (UTC)

I have implemented the idea, and came across a new issue: <noinclude> does not work as intended, because the Template:Charm log submission is transcluded in the Charm submission pages. Variables such as kills and curtotal are not defined and the table is broken at previews. Any solutions?User:Mugger759/Signature 10:13, August 17, 2011 (UTC)

Didn't you mean to use <includeonly>? JOEYTJE50TALK pull my finger 09:41, August 18, 2011 (UTC)

No, I didn't make a mistake. The table headers and variables are not available when the Preview button is clicked. Instead, a bunch of seemingly random characters (wikicode) is shown. After saving a page, the revisions become visible. Try it yourself by previewing any charm submission. To see my applied changes, visit this page.User:Mugger759/Signature 13:28, August 18, 2011 (UTC)

Comment - Suppa chuppa kept undoing my edits to the template, because he believed that it didn't work. Visit Template_talk:Charm log submission and copy the shown code to the RuneScape:Sandbox, then use Preview. See the commented notes for explanation on my code edits.User:Mugger759/Signature 20:25, August 18, 2011 (UTC)

Comment - I removed the changes on the template that were made as I was not really pleased with the direction this was going. I felt the implementation was not really the direction I think you wanted to go. The way it was working was just adding a big block of warnings that really wasn't doing too much. Also, the warning you added about how vandalism wouldn't be tolerated only appeared to people viewing the template, not to people submitting a charm log. There's already been a warning on the charm log header that says false information is considered vandalism for the longest time. Additionally, there really wasn't too much of a need for a change in the way charm logs were processed. All charm log entries are already processed automatically and compared with existing data. If the bot felt the submission was too far off, it wouldn't be added to the data anyways. I even think that Joey coded something a while ago to make your line of charm submission turn red if you submitted something incorrect as a warning. There's a green highlight of the line with the existing logs. Anyways, if you still think you can code something that's working like you want it to, come back and present that.  Lil cloud 9 ^Talk 09:25, August 19, 2011 (UTC)

What part didn't work "as intended"? My edit would add a very noticeable warning to incorrect charm submissions at a charm log with multiple charm drops. Lots of first-time charm log submitters skim over the header, because it's a wall of text ("TL;DR"). Visit Template talk:Charm log submission, and use that testing template. Can you add YOUR testcase, instead of stating that it does not work as intended, without showing proof?User:Mugger759/Signature 10:26, August 19, 2011 (UTC)

Oppose - Per Suppa.

1. REDIRECT User:Walrus068/Signature 10:05, August 19, 2011 (UTC)