About StringTables about manta

[jcoene]

A lot of things have changed since the earlier days, including how string tables are used. The data you're looking for lives in entity data. Try adding an OnPacketEntity callback and look for updates to CDOTA_PlayerResource. That should have a lot of basic information about players, including names.

Best of luck, and thanks for your help with the other issue!

[lucasb-eyer]

That doesn't change the fact that StringTable parsing looks broken, does it? I gather this means there's no interest/need for you to look into that right now, correct?

Also, the CDOTA_PlayerResource maps hero to player number, which we can use in CDOTAMatchMetadataFile to get an account-id which we can query, but I believe the only place the actual name during that match is stored is in the StringTables.

Edit: sorry, this answer sounds negative/harsh even though I don't mean it to, thanks for your great effort in this project! :)

[jcoene]

Hello,

What'a happening that indicates to you that there are issues with parsing of string tables? We (Dotabuff) use them extensively at scale and have not run into any issues. String tables can contain binary data, so it's hard to infer much from the paste in your original report.

Regarding player names in CDOTA_PlayerResource, try looking for either m_vecPlayerData.XXXX.m_iszPlayerName or m_iszPlayerName.XXXX depending on replay version. They should be there.

[jcoene]

With that said, if you're encountering an issue with string tables and can produce a fix, we'd love to accept a patch.

[lucasb-eyer]

Yes, my original paste is what made me think string table parsing is wrong. But if you're using them, it must be me misunderstanding/misusing them. Three observations made me think there are issues:

1. manta's public API doesn't give any way of accessing a StringTable entry's value field. (LookupStringByIndex returns the key). This made me think maybe you don't use StringTables at all.
2. Hacking around 1, I see that all keys are not "strings", but contain the same number as their index.
3. Again hacking around 1, all values look like binary blobs. From your answer I understand that's expected; is there an established way to parse these? For example, in my OP paste, we can see the values of indices 1-10 contain player names along with other binary data.

Yes, if I get to something valuable, I'll gladly contribute a PR.

As for the CDOTA_PlayerResource, thank you. Your post made me realize I was missing the ClassBaseline in my dump, which indeed contains the m_iszPlayerName property.

[jcoene]

So, some of the string table values are actually strings, others are binary data (such as class baseline entity data). There are only a few places where you may need to use string tables directly, such as when parsing combat log events. Related to your point #1, there's a helper function for that, ex: p.LookupStringByIndex("CombatLogNames", index)

Related to point #3, one of the uses for string tables is to actually store that class baseline data. It's stored as packet entity data, and so has been abstracted away. When you read from the CDOTA_PlayerResource baseline, those values are actually coming out of a string table.

Sorry that the manta API hasn't made some of this easier, we have some room to improve in making it easier to use the library.