UnownHash / Golbat

The Unlicense
36 stars 19 forks source link

Stats for quests are not filled correctly #226

Closed lenisko closed 4 months ago

lenisko commented 5 months ago

I see a weird results that doesn't match what we have in pokestop table.

-- having multiple fences per areas (country, city, province) this should be much greater than pokestop count
SELECT sum(count) FROM `quest_stats` WHERE reward_type = 12 and pokemon_id = 260 and date = CURDATE(); 
-- 141

SELECT count(*) FROM `pokestop` where quest_reward_type = 12 and quest_pokemon_id = 260; 
-- 247

Tagging @Cronick

Cronick commented 5 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
lenisko commented 5 months ago

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.

Fabio1988 commented 5 months ago

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
lenisko commented 5 months ago
347774
151657

But as stated, they look "okay/real" for country fences. When I filter them on province/city level they look weird.

Fabio1988 commented 5 months ago

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

lenisko commented 5 months ago

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

dkmur commented 5 months ago

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

Fabio1988 commented 5 months ago

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

Fabio1988 commented 5 months ago

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