Pular para o conteúdo
MirX
Estado

O que está feito e o que falta

Gerado automaticamente a partir das rondas de trabalho e da auditoria do cliente contra o servidor. Ordenado por impacto e, dentro do mesmo impacto, pelo esforço menor. Actualizado em 04/09/2026 17:22.

14rondas publicadas
53itens antigos já resolvidos
61achados da auditoria consertados
132por fazer
34de impacto alto
37de esforço pequeno

Por fazer

Achados da auditoria já consertados

Rondas publicadas

50

Caixa de Seleção: vinha sempre a primeira pedra (Vigor) e sem aviso no ecrã. CAUSA: CLIENT_GAME_USE_ITEM tem QUATRO campos {1 use_item_uid, 2 use_item_count, 3 is_inven_use, 4 select_get_id} e o handler passava o campo 2 (a quantidade, sempre 1) como escolha — casava sempre com o SortNo 1 do grupo. Agora usa o campo 4. AVISO: GAME_CLIENT_NOTIFY_ITEM_GAIN (2500) nunca era enviado; s_notify_item_gain/avisos_de_ganho mandam um aviso por item DISTINTO com a soma das unidades. Teste novo: scripts/testar-caixa-escolha.py

49

três pedidos do dono, todos publicados: • **Caixas**: 9.999 Caixa de Seleção de Pedra Mágica Lendária (604020088) e 9.999 Épica (604020087) na mochila do 467 (empilháveis, uma linha cada; scripts/aplicar-caixas-pedra-467.py, ponto 20260903-0158). Ao abrir dão a escolher entre 10 pedras (uma por família, Tier II). ATENÇÃO: elas não abririam — dados/caixas_escolha.json tinha só 2 grupos de 108; regenerado do pak actual (gerar-caixas.py) e publicado. • **Atributos aleatórios**: com melhor=True toda pedra saía com o ME

48

Pedra Mágica: os atributos secundários nunca existiram. MEDIDO: a única linha que aparecia ("Aumento de Todo o DANO DE ATAQUE +6,7%") NÃO vem do fio — é o Attribute1 de /ITEM_ATTRIBUTE.csv, que o cliente desenha sozinho. As outras são RandomOptionCountMax (= Grau − 1; 4 na Lendária de Ascensão) tiradas de RandomOptionGroupId, e viajam no campo 8 random_option_list do 13104. Nenhum caminho de criação de item escrevia em item_option_tb (sortear_encantamento só é chamado pela janela de Encantar). Conserto: servidor/pe

47

Pedra Mágica: o baralho 0 não existe no cliente. MEDIDO: mirx_magic_stone_tb tinha 10 linhas em DeckIndex 0 e 2 em 1; o 8007 DECK_LIST saía com active_deck_index 0 e um deck_info de deck_index 0, que o cliente não desenha (roda vazia, poder 0, botão "Alterar baralho (0)") — e o bloco de login 13164 lia o mesmo 0, daí "volta vazio todos". Agora: banco.pedra_magica_deck_ativo devolve 1 por omissão; PEDRA_MAGICA_DECK_MIN=1 e _pedra_magica_deck(uid, deck) normalizam tudo o que chegue <= 0 para o baralho activo; a lista

46

lista B inteira publicada, 28/28 testes verdes: • **Ponto de Pressão** (Advento do Dragão Divino): garantir_dragao_criativo abre os 6 furos no tecto (grau 5, 10 atributos do pool da Ânsia 24xxx) uma vez por sessão no 60746; "Desbloquear Novamente" e Ânsia do adm no mesmo tecto, sem recusa. Alternativa por banco: scripts/aplicar-pontos-pressao-467.py. • **Espólio da masmorra**: servidor/espolio.py (60205 DROP_RECEIVE_INFO_LIST, mirx_espolio_tb) — a janela deixa de dizer "Ainda sem nenhum espólio". • **Dominação**: s

45

Moedas identificadas em /MONEY.csv: 6 Milhagem, 19 Jade de Dragão, 13 Pedra da Guerra, 14 Pontos de PvP, 15 Moeda do Clã, 16 Pontos de Amizade, 17 Moedas do Clã, 21 Emblema de Cavalo, 22 Ponto de Admiração, 23 Aço de Dragão (3 sem nome, 7 "Fugir"); saldos do adm em 1 B (scripts/aplicar-jade-milhagem-467.py, ponto 20260903-0040). Janela Evento: o cliente faz POST /event/list?lang=pt na API 7000 e recebia "endpoint nao implementado" (67 B); agora nginx serve o ficheiro em POST (location = /event/list, conf .antes-eve

44c

print do dono (Cheonho "1/1" devia ir a "0/1"): a peça é material puro, o espírito existe sem ela → reserva ZERO (gasta até 0, em falha e sucesso). Adm com 0 peças segue sem recusa e sem gastar; não-adm sem peça é recusado antes de pagar. Nota: garantir_pets_criativos repõe 1 peça por espírito no login (uma vez por sessão) — o adm volta a ter 1/1 ao religar.

44b

medido no log/BD que a peça FOI gasta (item_stack_tb 2 → 1) mas a janela continuou a mostrar 2 — o cliente não aplica o campo 4 (del_item) à cópia local da bolsa. Agora a resposta 49025 vem seguida da mochila inteira (INVEN START/DATA/END) sempre que alguma pilha é tocada. Só existe um item por espírito (UseId 1701000049 → 1701200049).

44

promover Espírito (60572 PET_UPGRADE) agora gasta a peça do próprio espírito (PET_LEVEL.LvUpNeedPetItemCount → regra "pecas_pet"; item = PET_PECAS[tid].item_id, ex. Wooska 4901 → 1701200049) em FALHA e em SUCESSO, com reserva de 1 (o próprio espírito; consumir até 0 apagava o alvo e garantir_pets_criativos repunha). Adm nunca recebe result≠0 (com 1 peça segue sem gastar, com log); não-adm é recusado ANTES de pagar moeda/material. A peça vai no campo 4 (del_item) da 49025. Teste: scripts/testar-pets.py (+10 conferên

43

Loja arrumada por categoria — só a vitrine ACTUAL do Global fica ligada (692 artigos; 5.778 fora de cartaz desligados; era isso o "bagunçado"/repetido), preço estético = centavos do Global em Moeda de Ouro, adm não é cobrado (igual ao Mercado). Raides: 38/38 com chefe (INSTANCE_DUNGEON_INFO.DungeonBossMonsterId; posição de BossAppearPlayer1WarpXYZ), 32 mapas novos da campanha povoados, 70 mapas nomeados (stages.json agora publicado). Purgatório: as 16 stages UNDERWORLD já tinham ~1.000 monstros (2F-7F por confirmar

41

Técnica do Clã — "Cooperar" já era tratado (60363, +10 exp por clique, teto 8.700 = 870 cliques); agora para o adm um Cooperar enche a barra e a obra (LEVELUP_START) é instantânea; 60369 SKILL_START + bónus de atributo via servidor/tecnica_cla.py (mirx_guild_tecnica_skill_tb). Aparência: servidor/aparencia.py ligado — CHARACTER_INFO_LOGIN_GLOBAL leva 16 costume_list e 22 luxury_costume_pet_id (Vestível→Pet por NOME, hipótese) e APPEAR_USER leva 13 vehicle_id e 30 equip_costume_list. Aura do Espírito: PET.csv não te

40

Oração (NPC_PRAY 11/21: 60788 PRAY_ITEM -> 12101, 60789 BONUS -> 12102, bloco de login 13175 CHARACTER_PRAY_SYSTEM_DATA que ia VAZIO; dados/oracao.json; mirx_pray_tb; adm 100% de sucesso); 13137 MAP_WAYPOINT_DATA deixa de ser recusado (QUADROS_GRANDES 16 KB); todos os 10 Grandes Prédios do CLÃ TESTE no degrau máximo (Forja, Mina, Árvore, Santuários, Torres, Portão — aplicar-predios-cla-todos.py). 6 agentes em curso: Desencantar, Técnica do Clã, aparência (vestível/ aura/montarias/classes), raides c/ chefe + mapas n

32

armazém do 467 fundido (528 -> 35 itens; 493 sacos x1 somados em 4 pilhas; cópia *-antes-fundir-armazem); spawns do Pico Secreto 1-8F e Torre (11 stages) no chão real (1.117 pontos, área Secret_02/FD_BlackDragonTower), chefes grade>=4 colapsados para 1x (eram 3 linhas n=10); mundo_spawns.json + area_mapas.json agora no publicador. Pendente: "x93" do Nefariox não reproduzido nos dados (suspeita: acumulação em runtime/respawn); Purgatório sem spawns.

24

Pico Secreto aceita os ids do cliente (SECRET_DUNGEON RowId 1000/1001..8001 -> andar = id//1000; antes "masmorra pico_secreto/1001 desconhecida"); raides sem mapa em mundo_spawns (34/38) entram pela posição do 1º WARP_LOCATION do mapa (dados/warps_por_stage.json, 1.104 mapas; sem chefe dentro ainda); História: passo final 109207300 (Level 500, inatingível — teto 250) é fechado pelo servidor para o adm ao entrar (fechar_passo_inatingivel). Pendentes do mesmo diagnóstico: chefe dentro da raide (D3), Torre "Retornar"

Marcadores antigos verificados como resolvidos

Encontrou algo que não está aqui? Diga na comunidade com a versão do lançador e os passos para reproduzir.