axel7083
commented
1 year ago The function responsible of converting ObjectID to MessageID will be called ObjectMessageIDToActualMessageID and is located at 0x0201fc10.
An implementation of the function would like this:
int ObjectMessageIDToActualMessageID(unsigned short param_1)
{
int iVar1 = 97;
do {
unsigned short indexValue = (MSG_ID_CHAR_MAP)[iVar1 * 2];
if (param_1 < indexValue) {
unsigned short nextIndexValue = MSG_ID_CHAR_MAP[(iVar1 - 1) * 2];
if (nextIndexValue <= param_1) {
unsigned short difference = param_1 - nextIndexValue;
unsigned short correspondingValue = MSG_ID_CHAR_MAP[(iVar1 + -1) * 2 + 1] & 0xffff;
return difference + correspondingValue;
}
}
iVar1 = iVar1 + -1;
} while (0 < iVar1);
return param_1;
}The function is not looking for a match, but will rather compute it.
Here is a step by step example:
(1) You have the ObjectID
In our example we will take 0x73E == 1854.
(2) Iterate over the ObjectID
The ObjectID column is sorted, you need to found the range where MSG_ID_CHAR_MAP[i] < ObjectID <MSG_ID_CHAR_MAP[i +2]
We found the lower bound to be 1850.
(3) Take the difference
Between the lower bound 1850 and your 1854, the difference is 4.
(4) sum the lower bound corresponding value with the difference
The corresponding MessageID of 1850 is 102, so we got 102+4=106 our messageID is 106
Description
The Sign, does not use the Message ID to select which message to display. There is a Mapping table for
object message ids(parameter of the objects) toobject message ids(the ones in the text editor).A lot of element does not have a match corresponding in the text editor. Which makes it very weird. I was hopping to have a clear match between the Sign first parameter value and the text. But sometime I can't found the matching correspondance in the table
Some weird sign I do not understand the mapping:
Extracted and formatted table
0x0208eeec, it seems to be a table ofshortwith a size of 196.