---
name: rosh-campos-08-01
description: "Layout do pacote 08 01 do Karos e a armadilha dos campos que \"funcionam por acidente\""
metadata: 
  node_type: memory
  type: reference
  originSessionId: 3cda60cc-4b3c-4cc6-9aac-a6bf2b08e5af
  modified: 2026-08-24T20:33:01.064Z
---

Campos do CCharInfoHeroGage (08 01, 109 bytes) do [[rosh-emulador-karos]], medidos em
24/08/2026 com um personagem indo até o nível 9:

    [ 7:11] id                BE
    [15:19] HP atual          LE      [19:23] HP maximo   LE
    [23:27] MP atual          LE      [27:31] MP maximo   LE
    [43]    nivel             1 byte
    [45:49] reputacao         LE
    [57]    contador54        1 BYTE, satura em 256
    [65:69] FP / Fleta        LE
    [69:73] EXP               LE
    [90:94] PONTOS DE HABILIDADE  BE  (nao é "nivel-1")

**Why:** quatro desses campos eu tinha documentado errado, e todos pelo mesmo motivo —
lidos como u32 BIG-endian três bytes antes do offset real. As duas leituras dão bytes
idênticos enquanto o valor for menor que 256, então funcionaram por semanas e só
quebraram quando um personagem passou de 255 de HP e de EXP. O `[90:94]` idem: batia com
"nivel-1" nos níveis 1 e 2 (0 e 1), que era todo o alcance das capturas antigas.

**Reincidiu em 24/08 no `06 06`** (item entrando no inventário): o id do item está em
`[13:17]` little-endian, e `[12:16]` parece certo mas não é. Sexta ocorrência do mesmo
deslocamento de um a três bytes. Nesse pacote, `[12]` é o slot, `[19:23]` o id de
instância e `[27:31]` a quantidade.

**How to apply:** ao decodificar campo novo neste jogo, desconfiar de big-endian; o
protocolo é predominantemente little-endian e o BE deslocado é sempre uma coincidência de
valores pequenos. Antes de cravar um campo, conferir com um valor acima de 255 — e ver
[[medir-nao-adivinhar]]. Ferramentas: `tools/analisar_progressao.py` e
`tools/varredura2.py` (compara os pacotes que geramos com a distribuição do oficial).
