Dclone Tracker same event Overreporting

Sometimes I'll drop in to check the Dclone tracker, and If it's reported to be at 5/6 only minutes ago I'll park for a short time in the hope it will pop fast, but if it's been up for hours I'll skip it. In one recent report it was at 3 minutes so I logged on and parked. While I was still parked I checked the tracker again and someone else reported the exact same region and 5/6 count, and then not 10 minutes later another member reported it yet again. So now I'm wondering if the first report was also a repeat of a previous report and if so for how long? I find this overreporting of the same event annoying and a waste of time. In my experience a 5/6 count that's been up for an hour could take several hours before it pops, but if the same event keeps getting reported again and agin then there's no way to know how long it's been up. So to Dclone tracker reporting members, before reporting, please take a second to check to make certain you're not reporting again what has already been reported.

I think one part of the issue is that the page doesn't auto-refresh by itself when someone else updates a value. So, people open the tracker, have it open, someone else reports a change, and then a bit later they also see the status in-game and go to update. It's very easy to forget (or not care to) refresh the page before submitting the status, and since it doesn't auto-refresh, you get the effect you're describing. For one, Teebling could change it to auto-refresh. Second of all, he could change it to show the time the status was originally reported, and perhaps list a number of "confirmed" reports of the same status. Any other ideas?

ShadowHeart wrote: 7 months ago

I think one part of the issue is that the page doesn't auto-refresh by itself when someone else updates a value. So, people open the tracker, have it open, someone else reports a change, and then a bit later they also see the status in-game and go to update. It's very easy to forget (or not care to) refresh the page before submitting the status, and since it doesn't auto-refresh, you get the effect you're describing. For one, Teebling could change it to auto-refresh. Second of all, he could change it to show the time the status was originally reported, and perhaps list a number of "confirmed" reports of the same status. Any other ideas?

Some good suggestions. Maybe listing confirmed reports of same status might be the most doable. That way it would inform us that an original event is still open without resetting the time.

I do report the same status sometimes. Especially when the last report was hours ago and I see low number of users online. I do this to confirm the status is still correct. I never do it when it was minutes ago though. I feel ShadowHeart's suggestion would be great. One timestamp for first report, another timestamp for last confirmation of current status.

when it reach 5/6 on non ladder it usually takes hours before it actually pop, i seriously doubt anyone is selling sojs to get it to 5/6 and then not make it walk

my theory as i said some months back is that the game incrementally makes the counter go forward every 7-10 hours, but when it does reach 5/6 some streamer probably do the last step, just hard to know when.

To make it update in real time I'd need to poll the database value continuously and then send an ajax request to all clients when it changes. Not particularly easy to achieve, but would be cool if I did it fully with a screen shake effect at 5 or 6/6 lol.

The last report time/author is stored in the DB of course but not previous ones to the last update - I'd have to make a new DB table to get multiple reports for the same filters + confirmations stored and displayable.

I tend to report every time I use the uberdiablo command, just to give a "fresh" status on the evolution, as I tend not to trust much a status dating back from 3+ hours.

So I may be one of your overreporters - but not recently as I miss time.

mhlg wrote: 7 months ago

before reporting, please take a second to check to make certain you're not reporting again what has already reported.

I very much disagree.

If you look at the tracker page and it tells you that it has been sitting at 4/6 for 14 hours now and no reports in between, that is effectively completely useless information as you will have no way whatsoever of knowing whether it really is 4/6 or if there just hasn't been anyone around to update it.

If you look at the same tracker though and it tells you that it is at 4/6 with a last report 2 minutes ago - even if it has been at 4/6 for the same 14 hours - you can reasonably assume that it is indeed currently at 4/6.

The total current duration of the phase is a neat bit of extra information and a lot of client trackers (including my own) do track that additionally so you get both. But all in all, the "last reported" being relatively current is far more important.

I'd support adding the total duration to the page (so long as Teebs has the time and energy to do so) but asking people to not re-report the same status would merely make the tracker fairly pointless anytime the same status has been active for any longer duration as you simply have no way of knowing how valid that still is and - given a longer timeframe - would reasonably have to assume it just isn't.

It'd be a different story if the tracker were fully automated and guaranteed accurate of course but not so long as it is updated by folks manually.

That lack of accuracy also renders that whole idea of "just don't re-report the same to get the total duration instead" invalid. Say you move to 4/6. Someone then gets a bugged b.net command result and sets it to 1/6 5 hours later. 1 hour later someone notices that and corrects it back to 4/6. And 6 hours later, you look at the tracker. If noone re-updated the same thing and noone else made a mistake, you'd now see 4/6 for 6 hours. Which tells you nothing. It'd be too long ago to still consider reliable. It doesn't show you the actual 12 hour total thanks to the needed correction in between (which happens all the time). It just wouldn't tell you anything anymore other than "this is when a report came in that was too long ago to be relied upon, MAY have been the start of the phase, MAY have been a correction or MAY have been a re-report after all" which would make it entirely pointless.




@Teebling:
Building on the above, if you do want to add a total duration, do keep in mind that to do it correctly, it isn't as easy as "had 4 reports of 4/6 since the last 3/6 report so use time of first of these 4 to calculate total". Between human error and the simply broken/bugged b.net commands/server status, you end up with a ton of cases (like...a LOT) where 4/6 will last for let's say 10 hours (random example) but over those 10 hours someone accidentally throws in a 5/6 which is then corrected back to 4/6 and someone will have a bugged command and throw in a 1/6 which is then corrected back to 4/6 and so on. To get an actually accurate total duration, you do have to add in some corrective measures to account for all that. If/when you do want to do that, feel free to reach out since I've gone through the whole "find what seems to be the most reliable" process to create those same confirmations and corrections for my tracker client, happy to share the approach I used with you. May not quite be the absolute ideal anymore if the lower player count nowadays also reduced the overall reports/time significantly but at least pre-D4andwhatnot, it seemed to work quite reliably (haven't bothered to fully re-evaluate since).

Current example: Duration = total phase duration, accounting for known reports and applying corrective checks.
Last report = same last report you'd see on the tracker page here (which remains far more important).

The only real limitation here is that my own tracker is of course based on the data pulls it did and is hence limited by downtime (i.e. my not having it running - didn't bother moving it to my server for continuous pulls instead as the total just isn't important enough) whereas if you did it here, you could just utilize the entire DB as needed and hence keep long-duration totals more accurate.

I also belong to the DClone-Overreporters even though I see the point mhlg adressed. I often jump and park when status changes very fast. To know that you need to know the time of the last reported status change.
From my point of view it is sufficient to show the last time of the status change and the last update. The Telegram Bot (1) for example only shoots a notification when status changes. Absolutly sufficient for this kind of data aquisition and you do not have to much information to save.

An excitable Boy tending cows cried “Diablo, Diablo!” to get attention and people came. Then another boy did it and again people came. A third, fourth, and fifth boy cried “Diablo” and it went on like this until they were ignored. Then in Silence Diablo’s clone came and Sanctuary was lost. The cows now fearing for their lives all armed themselves with lochaber axes and moved away to a secret place.

“In behavioral psychology, extinction is weakening of a conditioned response over the course of time, eventually resulting in the said behavior either decreasing or disappearing.”

Or the boy cried “Dclone (wolf)” too many times and no one came.

A potential way to solve mhlg's issue would be if there was a historical log of tracker reports that we could all view.

For example, from another website:
Might not be too hard to code, and could be useful info. Jm2c