fixed64 vs (u)int64
iAroc opened this issue · 10 comments
yo, not sure if u even check issues.
anyway, i sometimes crash when decoding a GetHoloInventoryResponse, failing with "throw Error("invalid wire type " + wireType + " at offset " + this.pos);"
im using node.js todo the protobuf stuff.
After debugging it down, i found that i fails on EggIncubator decode, when it tries to read the pokemon id as fixed64 as you have here:
https://github.com/Furtif/POGOProtos/blob/master/src/POGOProtos/Inventory/EggIncubator.proto
The pokemon_id in my case is
uint64: Long { low: -49685929, high: -682833928, unsigned: true } -> 15513994688595614295n
int64: Long { low: -49685929, high: -682833928, unsigned: false } -> -2932749385113937321n
After digging around, i found that many forks in the past also changed it back and forth between fixed64, uint64 or int64.
You changed that somewhere back in 2019, so my question is to why did u change it?
Since for me it seems int64 is correct?
Also if that one is wrong, i guess all the others should be int64 then too, and not fixed64? Or any Idea where the actual problem is, in case fixed64 is correct?
@iAroc change it if work well for you make pr
there are a lot of things that are self-generated in case of error and you are sure or have tested and this is good, I am not afraid to propose ...
surely you should be right but as several scripts make a comparison maybe this part you talk about is impacted, such was the case for giftbox (see closed issues)
thank you for your participation
on the other hand, fixed64 exists in a lot of ways mainly in responses in what is request in general is uint64 or int64 as you said.
on the other hand and use js I don't know if the standbox is ok, there is a recent branch here https://github.com/Furtif/pogo-protos/tree/181.0
//
// Pokémon Go stuffs
//
// uint64 to fixed64
if (line.Contains("pokemon_id") || line.Contains("encounter_id") /*|| line.Contains("giftbox_id") || line.Contains("giftbox"))*/ && line.Contains("uint64"))
line = line.Replace("uint64", "fixed64");
if (_name?.Equals("BattlePartyProto") == true && line.Contains("ids") && line.Contains("uint64"))
line = line.Replace("uint64", "fixed64");
if (_name?.Equals("PokemonProto") == true && line.Contains("id") && line.Contains("uint64"))
line = line.Replace("uint64", "fixed64");
if (_name?.Equals("PurifyPokemonLogEntry") == true && line.Contains("purified_pokemon_uuid") && line.Contains("uint64"))
line = line.Replace("uint64", "fixed64");
// uint32 to fixed32
if (line.Contains("checksum") && line.Contains("uint32"))
line = line.Replace("uint32", "fixed32");
//*/is uint64 according dumps
https://github.com/Furtif/POGOProtos/blob/for_fix/base/v0.181.0.proto#L7841
not fixed and not uint is int64 only
ty for the fast update :O
it doesnt really matter if its uint64 or just int64, they take the same type in protobuf (both are varInt, 1-10 bytes), where fixed64 is always 8 bytes.
while adding new stuff, i also had problems with DiskEncounterMessage, needed a int64 there too. maybe u only checked responses?
From the game side, internal it always uses ulong and runs on default 64bit, resulting that its a uint64_t. thats true for nearly every instance where it uses encounter_id or pokemon_id. its strange that it sometimes even internally doesnt use ulong.
it uses only long (e.g. int64_t) on everything time related and raid seeds. and rare,but sometimes on stuff like pokemon_id.
Since the dumps are showing int64/uint64, who came up with the fixed64? what was the reason for that?
thanks for your time. I will report more stuff if i see more thats not working.
@iAroc as I said see the commit above where I speak 'comment' put ok or change to 'xxx' #24 (comment)
for example there is a comment b0103aa#r40717719
this issue is no longer current.