Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify data type of MsgEntry.attributes #34

Closed
dtlnor opened this issue Dec 13, 2022 · 5 comments
Closed

Identify data type of MsgEntry.attributes #34

dtlnor opened this issue Dec 13, 2022 · 5 comments

Comments

@dtlnor
Copy link
Contributor

dtlnor commented Dec 13, 2022

The number of MsgEntry.attributes in each entry is same as the number of Msg.attribute_headers.
The MsgAttributeHeader.j indicating the data type of the value in MsgEntry.attributes
Which from what I observe should be:
0 : int64
1 : double
2 : string (a u64 offset pointing to the actual string)
which should resovle the TODO at https://github.com/wwylele/mhrice/blob/main/src/msg.rs#L138

edit:
-1 : string (a u64 offset pointing to a actual string), it seems like its always pointing to a null string(0x0000)

@wwylele
Copy link
Owner

wwylele commented Dec 13, 2022

I remember last time I saw some inconsistent data so I didn't resolve it this way. Will revisit

@wwylele
Copy link
Owner

wwylele commented Dec 15, 2022

Fixed in 3eb805c. Thanks!

@wwylele wwylele closed this as completed Dec 15, 2022
@dtlnor
Copy link
Contributor Author

dtlnor commented Dec 15, 2022

-1 : could be a string? (a u64 offset pointing to a actual string), it seems like it is always pointing to a null string(0x0000). From the nid801_MR.msg.539100710 and Quest_Demo_MR.msg.539100710 file

@wwylele
Copy link
Owner

wwylele commented Dec 15, 2022

I have seen -1 that has corresponding data "1400" (in integer), so I believe that's just garbage data

@dtlnor
Copy link
Contributor Author

dtlnor commented Dec 17, 2022

I have seen -1 that has corresponding data "1400" (in integer), so I believe that's just garbage data

because when I checking those file has -1 value. I saw the value inside always going to the string part(larger than data_offset) if we handle it as offset.
for example:
natives\STM\npc\Message\nid801_MR.msg.539100710, all the values are 151948, which if I found the value at that offset, it is 0x0000
natives\NSW\Message\Quest\Quest_Demo_MR.msg.539100710, all the values are 32304, which if I found the value at that offset, it is 0x0000
natives\NSW\Message\Quest\Quest_Demo.msg.539100710, all the values are 160168, which if I found the value at that offset, it is 0x0000
for that file has 82ADE89D-FEB631FA mmh, all the values are 1400, which if I found the value at that offset, it is 0x0000

so I guess -1 is some thing like disabled. and its value is an offset always pointing to the string part with the value 0x0000 which is ""

I tried to assert its value must be between the data_offset and EOF, and assert the string value must be 0x0000, its fine with all the msg files in current game version

although it is still garbage data

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants