assets/archetypes/compileditems.msgpack
This file has all the item data, keyed by the internal name I think. You’ll have to use that and the english.json to find the correct string.
2 Likes
fyi: item names are no longer in the localisation data like english.json, they’re part of a more compact binary asset itemcolorstrings.dat (its now used server side for reclaim filtering)
3 Likes
All item strings are there, not just color related ones?
They were all gone when I checked the new file from inside the msgpack. I had to grab em from a backup english.json I had around.
1 Like
That means we will not have the names of any new items right? I wasn’t able to find any translation data for title and subtitle for the new glass signs (although the description exists), so I haven’t bothered adding them to my site yet. I really don’t fancy having to add each new item manually along with 4 other translations 
Figure out how to pull them from the itemcolorstrings.dat 
1 Like
Will do - Does it contain all the translations as well, or will I need to set my game to each translation and make a copy of the file for each one?
1 Like
It contains them all
2 Likes
for anyone interested, figured out the mapping. here is the NAME to GUINAME to ID json export. Let me know if you find any issues… I have excluding “ALL” items that are listed as “canGive : false” as there were alot of extra item mapping involved that can’t be listed in the sell table. I can easily pull in other item specific values if needed, just let me know what.
Now to move a little further with the web interface for the shop searching… hope the API requests will come back by the time i’m done with the web interface side.
https://drive.google.com/drive/folders/1mXYFFymS9MvXUr2vBzwOF_8vIIi0DcrG?usp=sharing
edit :: Looks like there are a few values (4 to be exact) that are coming back from the msgpack decoding as the new glass signs. However, the decoding of the english.msgpack doesn’t have a reference to the name. Curious if this is an issue / item missed from being added to the english.msgpack or if this is an issue with the data being there, but it simply being decoded … btw, I tried 3 different decoding process / tools, and all of them gave me the same results, so i don’t think it’s a decoding issue, but not sure.
Okay, so using all the info provided in the Documentation of itemcolorstring.dat topic I have managed to extract the list of string translations from the itemcolorstrings.dat file.
What I am unsure of, however, is how to link that list of names to the ID or stringID of the item.
e.g.
“id”:9333, “stringID”: “ITEM_TYPE_CONTROL_GUILD_BASE”
And while I know that name is “Guild Control”, it’s the fourth item name in the English list and I can’t see how that relates to ‘9333’ or ‘ITEM_TYPE_CONTROL_GUILD_BASE’
Anyone got any ideas? or perhaps @lucadeltodecso has the answer?
I’m sure he’ll chime in Monday after somebody has already reverse engineered it 
Hahaha, so long as he chimes in at all, I’ll be happy.
the first section of the itemcolorstrings.dat contains a sorted list of itemid which indirectly gives the indexing of the title strings Documentation of itemcolorstrings.dat structure
from start of file:
u8 : metals-palette max index <-- ignore
u16 : number of encoded ItemType's
{
u16 : ItemType
u8 : subtitle-index <-- ignore if you dont care about the subtitles
} * number-of-encoded-ItemType's [ sorted by itemId for binary search
aka if 9333 is the 102nd itemtype in the list, then item-title at index 102 is the title for that item
5 Likes
Ah, yeah I was skipping over that part 
Thanks luca! You’re the man! 
I took the compileditems.msgpack and the english.msgpack … converted them to Json, and paired together the fields I needed which is how i got all the item_name, item ID, and the friendly name … which is what i shared on google drive. The one thing that I wasn’t able to find within the itemcolorstring.dat was how to determine if the item should be excluded from display, due to not really being an item, or being a cheat / creative only item, etc. The msgpack method has a ton of details on each item that allowed me to filter by. only 4 items weren’t matched up, which was the glass items… and the oort stones weren’t detected because they were flaged as “notGiven” … but I white listed those to include them.
There seems to be a lot of duplicated item IDs:
But otherwise it all seems to be working to me.
Thanks again to @lucadeltodecso and to @Lorgar
2 Likes
This is because the game uses block IDs for various implementation states, for example to differentiate between signs-in-the-process-of-being-created vs signs-in-a-valid-state.
1 Like
If you look at the internal names they’re a different block internally, even though they share the same language string. Signs have a complete version, some blocks have a dugup version etc.
“SIGN_GLEAM_MODULAR”
“SIGN_GLEAM_MODULARCOMPLETE”
The final item count for stuff usable in-game and searchable from the knowledge menu came to 972. It’s still probably wrong but pretty close.
1 Like
Ah, I see!
Thank you both, makes a lot of sense 