Closed lenisko closed 4 months ago
having multiple fences per areas (country, city, province) this should be much greater than pokestop count
It will only match with a single fence using MatchStatsGeofence (Nvm, should match multiple areas, so think you are right on that), so won't be much higher then pokestop table, but should at least be equal or higher.
https://github.com/UnownHash/Golbat/blob/main/decoder/pokestop.go#L923-L924
On my own instance, it seems to be counting fine. So a bit weird why there is such a difference on yours. Will have a look later and see if I can find something that could be the cause of this.
SELECT sum(count) FROM `quest_stats` WHERE reward_type = 12 and pokemon_id = 260 and date = CURDATE();
-- 60
SELECT count(*) FROM `pokestop` where quest_reward_type = 12 and quest_pokemon_id = 260;
-- 38
If this helps.. I have from 2 up to 4 fences for each scanned location (mostly 3 - country, province, city). Stats on smallest ones are like 1, or don't exist. Top level look better, but not sure if they are reliable.
I tried with following query on my setup, no guarantee if query is correct, copied it from discord
SELECT SUM(`count`) AS total FROM golbat.quest_stats WHERE date = CURDATE()
GROUP BY date;
# -> 67695
SELECT SUM(count) as total
FROM (
SELECT quest_reward_type AS reward_type, COUNT(*) AS count
FROM golbat.pokestop
WHERE quest_expiry > UNIX_TIMESTAMP() AND quest_reward_type IS NOT NULL
GROUP BY quest_reward_type
UNION ALL
SELECT alternative_quest_reward_type AS reward_type, COUNT(*) AS count
FROM golbat.pokestop
WHERE quest_expiry > UNIX_TIMESTAMP() AND alternative_quest_reward_type IS NOT NULL
GROUP BY alternative_quest_reward_type
) AS subquery;
# -> 66768
347774
151657
But as stated, they look "okay/real" for country fences. When I filter them on province/city level they look weird.
I assume it doesn't match for some of you because you have multiple areas covering same locations?!
Previously Golbat fences were defined to work with pokemon. if you use the same fences you might see quests in world
(as this is considered not within fence).
@lenisko if it matches for "country" fences then the stats should be correct. Golbat tries to match with all fences provided (from koji or file)
so the issue might be related to golbat not knowing which fence is of which type, it's only used for general stats
I assume it doesn't match for some of you because you have multiple areas covering same locations?!
You made it sound... wrong? I believe it's quite normal to have multiple fences now.
Previously Golbat fences were defined to work with pokemon. if you use the same fences you might see quests in world (as
this is considered not within fence). I'm passing country (fort), province and city fences. In 2 cases I split cities.
so the issue might be related to golbat not knowing which fence is of which type, it's only used for general stats
you mean we filter out fences using a koji fence type? if so that's just wrong
as mon fences often differ from quest fences, now that golbat processes quests, it should hold both fences for this to be done correctly. The mon fences we have "always" submitted to it are generally taken from a koji project. Quest fences can either be taken from drago or a seperate koji project and soley used for quest stats. As for all fences of a type, quest or mon, they should not overlap within its type
what I meant is the following:
But what you might want to achieve is that mons are mainly covered in Manhattan stats, as this fence is used for your mon route, you don't want to add stats for mons outside of your border, as those are seen as nearby somewhere, that pollutes mon stats
In the example above your quests would be covered in 3 different areas for stats counting, makes it difficult again to find correct numbers
If it matches much better with full country fence stats it might be related either with the lookup or some concurrency issue.
It's probably the way how they are collected and processed after. https://github.com/UnownHash/Golbat/blob/d28f82390a491001d4c3607c8b975cf1de20cd3b/decoder/stats.go#L553
I see a weird results that doesn't match what we have in
pokestop
table.Tagging @Cronick