-
-
Notifications
You must be signed in to change notification settings - Fork 7
Description
When decoding GET_MAP_OBJECTS responses (method 106) via the /golbat endpoint, ProtoDecoderUI consistently fails with invalid wire type errors from protobufjs. Other RPCs decode and display correctly.
Environment
- ProtoDecoderUI commit / version:
main
Steps to reproduce
- Open the game and move around so that
GET_MAP_OBJECTStraffic is produced. - Watch the ProtoDecoderUI console and UI.
Actual behavior
The console prints errors like:
Error parsing request REQUEST_TYPE_TITAN_PLAYER_SUBMISSION_ACTION_GET_AVAILABLE_SUBMISSIONS -> Error: invalid wire type 7 at offset 9
Error parsing response REQUEST_TYPE_TITAN_PLAYER_SUBMISSION_ACTION_GET_AVAILABLE_SUBMISSIONS method: [620001] -> RangeError: index out of range: 322 + 10 > 322
Error parsing response REQUEST_TYPE_METHOD_GET_MAP_OBJECTS method: [106] -> Error: invalid wire type 6 at offset 1781
etc...
Other RPC methods (including various social / inventory calls) decode fine.
Notes
I am using the latest proto-parser.ts from main and the @na-ji/pogo-protos version specified in this repo’s package.json.
requestMessagesResponses maps method 106 to GetMapObjectsOutProto for the response.
The raw base64 payload decodes to a non-empty byte buffer that looks like a valid protobuf message (field 1 length-delimited etc.), so this feels like a schema mismatch rather than transport corruption.
My fork only changes:
src/index.ts: I added a local dumpSixVariants(...) call to save raw / parsed / unparsed variants to disk.
src/parser/proto-parser.ts: I added some error-wrapping around decode(...) so failures get returned as { error, rawBase64, errorMessage }.
I did not change the method → message mapping or the underlying POGOProtos types.
If needed, I can provide:
A minimal log snippet with the full rawBase64 for one failing GET_MAP_OBJECTS response.
A diff between my proto-parser.ts and the current main branch.