as alterações já estão na master do github

Maravilha!
Logo que possível testarei aqui!

Só uma pergunta informal - qual editor hex você usa?

E outra coisa que eu percebi...

(Antes de mais nada, um disclaimer: eu estou assumindo aqui que eu sou o campeão de fazer quase QUASE TUDO da forma mais complexa o possível! Se a resposta do que eu te perguntar no final desse post for algo que você já explicou e eu que fui jumento o suficiênte para não entender ou se for algo absurdamente óbvio, por favor - não fique bravo comigo, please!)

O cálculo usado para descobrir a prox. mensagem é calculando o tamanho da mensagem atual com o valor hex presente no ponteiro. Exemplo que você me deu com a imagem do RE2:

Ponteiro 1 = 08 00
Tamanho do 1º mensagem = 58h
Ponteiro 2 = 58 + 08 (em hex, 60)

(Eu sei que deve ser considerado o segundo valor devido a forma que as variaveis funcionam dentro do RE3 mas em fim...)

A forma que eu implementei foi a seguinte: para o programa saber quais pontos ele precisa "cortar" para pegar as mensagens no RDT, eu mandei ele obter exatamente a primeira mensagem com FA no arquivo (usando os métodos antigos de alibabá e seus 40 filtros!), assim eu vou poder voltar apartir desse ponto de 4 em 4 casas até encontrar o inicio dos ponteiros (0100 ou 0000). A partir daí, para o programa obter as mensagens, ele vai começar a contar os tamanhos da mensagem a partir do final do ultimo ponteiro (aonde se encontra o começo da primeira mensagem). Para obter o tamanho das mensagens, eu estou usando o cálculo abaixo (Exemplo usado no mapa R11A.RDT - Sala S.T.A.R.S):

Ponteiro 1 = 16
Ponteiro 2 = 43
Tamanho da Mensagem = Ponteiro 2 - Ponteiro 1.
(Acredite, funciona da mesma forma - o resultado é 2D)

Só que aí eu percebi uma coisa: como o RE2 / RE3 sabe o tamanho da ultima mensagem?

Boas;
Eu uso desde sempre o HexEdit. Atualmente utilizo a versão 4.0, que é freeware. Acredito que não seja dos mais modernos, já que foi descontinuado, me parece. Mas é o que estou acostumado e me dá as principais ferramentas que preciso.

Quanto à sua forma de analisar os ponteiros, ela está absolutamente correta. Como te disse lá em cima, o verdadeiro romhacker desenvolve sua própria forma de analisar os métodos e fico mto feliz em ver que vc tem esse feeling pra coisa!
Pra vc calcular o tamanho da última mensagem, nesse teu esquema de contar inversamente, uma boa alternativa é correr o texto até achar o byte FE. Ele fecha os textos. E aí vc aplica os 40 filtros do Ali Babá pra te avisar CASO alguma sala não tenha este FE no final.

Não se preocupe em perguntar, nem se já respondi ou não. Pergunte sempre!

Bom saber - eu sempre usei o HxD, ele me tem me servido bastante!

No caso da ultima mensagem... Não acha estranho o RE3 não saber o tamanho da ultima mensagem?
Eu já estava cogitando escrever o programa dessa forma por que realmente não faz sentido ele não saber o tamanho da ultima mensagem... (Ou se realmente tiver, está em algum outro lugar no arquivo do qual eu não sei.)

Outra coisa... Existem alguns mapas uma forma diferente de indexar as mensagens, como R20B (Bonde - Lado de fora) ou R212 (Subsolo do Restaurante Grill 13). Mas, tem outros casos que tem os ponteiros estranhos!

Veja o caso de R100 (Warehouse - Save) - O primeiro ponteiro dele é FFFF!

(Por hora eu apenas mandei o programa pular o ponteiro se o ponteiro estiver com esse valor).

E também tem o R105 (Brad entra no Bar Jack - Dia), que o primeiro ponteiro tem o valor FF02!

A princípio deu a entender que pegaram o ultimo ponteiro e resolveram colocar no começo de propósito! Só que aí eu pensei: De acordo com a estrutura de variaveis do RE3, esse valor é impossível de existir (ou é FE02 ou então é 0003). Sendo assim eu vou tratar esse caso como um terceiro indicador do inicio dos ponteiros (0100, 0000 ou FE02).

 

Update: Consegui resolver o problema dos mapas citados acima (menos R20B e R212) tratando os valores estranhos como ponteiros! (ficando assim 0100, 0000, FFFF, FF02 e AD04 como critério de busca)

Porém mesmo assim ainda tem outros mapas que pelo visto não seguem o cálculo que você me ensinou, que é o caso do R10F (Boutique) que tem os ponteiros dessa forma:

Resultado da Busca: 0100
Ponteiros: 0800 0600 5400 A200
Hex: 01 00 08 00 06 00 54 00 A2 00 FA 02 30 44...

Assim como é de se imaginar, o cálculo não dá certo da mesma forma que não tem ponteiros suficiêntes comparado ao tanto de FA 02 que tem no arquivo - considerando que algumas mensagens contém FA 02 mais de uma vez!

Veja um trecho da mensagem abaixo:

..00 55 4B 51 01 FD 00 FA 02 33 45 48 48 00 55 4B 51 00 3F 44 3D 4A 43 41 00 55 4B 51 4E FC 3F 48 4B 50 44 41 4F 1B FB 00 FE 00

Tradução:
...you.(Pausa) (Inicia mensagem com velocidade 2) Will you change your (Line Break) Clothes? (Yes / No) (Finaliza mensagem)

Estou tentando ver como proceder nesse caso...

No caso do RDT100, não entendi pq vc afirma que os ponteiros começam no FF FF. Na verdade eles começam, no teu print, no 31 00. Porém, está faltando um ponteiro, aí. É provável que um dos textos tenha sido retirado de alguma forma. Não tenho o RE3 em inglês aqui, no momento. Porém, veja a versão traduzida por nós:

Após o FF FF que vc cita, nós temos 4 ponteiros. E não 3, como vc mostra no teu print.

No caso do RDT10F, os FA 02 excedentes são precedidos de FD 00. Quando isso acontece, você NÃO PODE considerar FA 02 como início de texto. Então uma boa saída neste caso possa ser um regra de que qdo FA 02 for precedido de FD 00 continua a contagemd e bytes de texto até o próximo FA 02 que NÃO TENHA FD 00 antes.
FD 00 = Novo parágrafo dentro do mesmo texto. Mostra a flecha intermitente na tela.
Isto poderá acontecer nos diálogos, também. Fique atento a isso!

 

Perdão, eu me expressei mal -eles começam na frente de FFFF.
A forma que eu resolvi isso temporáriamente é com uma ideia que está próximo do final desse post.
Eu estava pensando aqui... Seria esses valores algo como o tamanho max. de mensagens permitidas por mapa?
(Exemplo: FFFF permite que no mapa tenha no max. XX mensagens)

Digo isso por que eu percebi que tem muitas variações desse valor nos mapas!
Veja os exemplos abaixo:

R111.RDT (RPD - Main Hall)
01 00 FF 31 0A 00 2C 00 91 00 B2 00 DD 00

R112.RDT (RPD - Escritório com o Marvin)
01 00 48 68 0E 00 34 00 65 00 8C 00 BC 00

R113.RDT (RPD - Arquivos)
01 00 81 D6 0E 00 31 00 77 00 CC 00 F8 00

....Suspeito!
(Se você quiser eu posso te enviar os arquivos para você mesmo ver)

Em relação a leitura dos ponteiros, eu acho que descobri uma forma mais interessante de encontrar o início dos ponteiros!
Se você subtrair o ponteiro atual com o anterior, ele sempre deve dar um valor positivo. No momento que ele te der um valor negativo, você terá encontrado o primeiro ponteiro! Veja o exemplo abaixo:

R100.RDT (Warehouse) - Simulando uma busca que o programa irá fazer
Hex antes das mensagens: 01 00 FF FF 08 00 31 00 60 00 7D 00...

Ponteiro atual: 31 00
Conta a ser feita (Hex): 31 - 08 = 29 (em decimal: 41)
(Resultado com positivo - uma nova busca será feita)

Ponteiro Atual: 08 00
Conta a ser feita (Hex): 08 - FF = FFFF FFFF FFFF FF09 (em decimal: -247!)
(Ponteiro incial encontrado!)

Essa regra se aplica a todos os arquivos citados nessa postagem!

Em relação aos parágrafos, eu não preciso mais me importar tanto com eles, por que o programa agora obtém o tamanho das mensagens através dos ponteiros.

Interessante!

Esse cálculo só dará problema se o valor anterior for diferente. No RE2, às vezes acontece de iniciar com 01 00 PP 00. Neste caso do teue xemplo, seria 08 - 01. Aí daria errado. De cabeça não lembro se no RE3 existe essa situação.
Só fique atento a isso!