Setting the thing to 12 bytes wide there looks to be something counting upwards.
Curiously sections seem to start with MSGB (MSGP starts the thing so don't know if it is supposed to MSG and a further value to signify something).
347 instances of MSGB in the file.
The first MSGB starting at 1058h in the file. EE4A being the last entry in the list before then, rather shorter than the FEA2 where the last MSGB in the file happens.
Quick sanity check
1058h = 4184
Dividing that by 347 does give me 12 which is bytes wide. I was not necessarily expecting that as there is a start to the file and some other stuff, was expecting the result to be more actually.
Anyway EE4A is a lower value than I expected for an end of pointer table, however if I add the 1058 to it you get FEA2 aka we are probably dealing in so called offset pointers (they start counting where the real data begins rather than from the start of the file). If it helps to visualise it then you probably had a book start with Roman numerals for the contents, introduction and whatnot before going to Arabic numbers for the normal page numbers. Same idea but for computers instead.
What the remaining bytes are in that 12 byte section I am not sure. I would generally expect 4 bytes for a length/pointer as that can make for quite large files where 2 bytes/16 bits almost runs out in this example. Remaining ones could be a length (easier to read it than have to calculate it), could be formatting, could be who is talking or could be something related to any of those.
I am also not sure what is in the bytes between MSGB and the text itself, usual guess is formatting, what portraits to display or something like that, though could be lengths of individual lines within it (doubtful from what I have seen of it but without testing then eh).
Anyway back to pointers. First few locations of MSGB are
1058
10FA
11C6
123E
129A
Nothing in the start there, taking 1058 from it
0
A2
16E
1E6
242
Oh look
Code:
Offset(h) 00 02 04 06 08 0A
00000018 0000 0000 0000 00A2 0000 0001 .......¢....
00000024 0000 00A2 0000 00CC 0000 0002 ...¢...Ì....
00000030 0000 016E 0000 0078 0000 0003 ...n...x....
0000003C 0000 01E6 0000 005C 0000 0004 ...æ...\....
00000048 0000 0242 0000 00FE 0000 0005 ...B...þ....
00000054 0000 0340 0000 00C8 0000 0006 ...@...È....
00000060 0000 0408 0000 00DA 0000 0007 .......Ú....
0000006C 0000 04E2 0000 0098 0000 0008 ...â...˜....
00000078 0000 057A 0000 004E 0000 0009 ...z...N....
00000084 0000 05C8 0000 0092 0000 000A ...È...’....
Next value also appears to be the length (take the next value and minus the current, or if you prefer add the value there to the current. Note in other things this might be be the same thing if they pad out the data for reasons like starting at a certain multiple is good for the processor).
The others appear to be counting upwards in that section but shortly after have random skips, so probably a line number/reference value instead (some text maybe got deleted, reordered or something). It may also be that I got it wrong there and the line numbers at what starts the entry before having location and size.