Large despawn times (known bug)

beeb commented 8 years ago

As noticed by many API devs recently, a change needs to be done to get proper despawn times.

Any chance the fix could be ported to this implementation too?

AgentFeeble commented 8 years ago

I kind of feel like this API is a tool to receive the data from the Go servers as is, allowing the applications using the API to interpret the data as it sees fit. This change would force all users to see Pokémon with these strange expiry times as expiring in 15 minutes time. What if the app wants to treat this case differently? The strange data could also have a meaning that we haven't figured out yet, and actually be valid. So I think a change like this should be implemented by consumers of the API. Your app could interpret this larger than usual timestamp as it sees fit (replacing it with a 15 minute expiry if you want, or you could discard the pokemon on each refresh, and if it is still valid it will come up in the results again).

Additionally, this could be implemented in one of the following ways, each with some downsides:

Specialised deserialisation code for the map objects response, where currently the deserialisation is generic for all response (all use the same code path).
Change the protobuf implementation files. This would make it difficult to update the files whenever the protobuf descriptors are updated, making sure that the changes persist across updates.

This is my opinion though, I'm open to discussion. If you feel differently you're welcome to try change my mind :)

beeb commented 8 years ago

Okay, I thought this was due to an overflow and was not proper data. If you think they are meant to have this must disappearing time then I guess you're right.

There are also negative disappear times (that I'm filtering out at the moment) that seem to be due to an overflow, however : https://github.com/AeonLucid/POGOProtos/pull/184

AgentFeeble commented 8 years ago

Is this with the MapPokemon or WildPokemon object? I don't think its overflowing for MapPokemon, thats already using 64 bits, but I do know it can overflow with WildPokemon, which is 32 bit. Apparently this is by design, the server is returning a 32 bit value for WildPokemon, I'm just not sure of the reasoning behind it.

beeb commented 8 years ago

Yes the negative times are for wild pokemons.

AgentFeeble / pgoapi

Large despawn times (known bug) #7