Dclone Tracker same event Overreporting

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.

mhlg wrote: 2 years 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.