Summary
common/sql/seed/006_gamedata_items.sql has exactly 934 rows whose name
column is the literal string [en] instead of a real item name:
INSERT INTO `gamedata_items` VALUES (0,'[en]','Normal/DummyItem',1,0,0,0,0,60000,0,1,0,0,0,0,1,1001,0,0,0,0,0,-1,0,0,0,0,0);
INSERT INTO `gamedata_items` VALUES (1000104,'[en]','Money/MoneyStandard',999999,0,0,0,0,60745,0,1,0,0,0,0,1,1001,1,0,0,0,0,-1,0,0,0,0,0);
(count checked with grep -c "'\[en\]'" common/sql/seed/006_gamedata_items.sql)
This is inherited data — the same 934 rows with the same broken name in the
same positions exist in the Bitbucket upstream's
Data/sql/gamedata_items.sql (project-meteor-server, develop branch),
so it's not something this port introduced; it's a pre-existing gap in the
community gamedata_items dataset both projects build on.
Rough breakdown
From working with this table while extracting shop/recipe data:
- ~703 are in the
11000xxx range (quest/leve reward items)
- ~182 are armor-variant catalogIDs (color/quality variants of named armor
pieces)
- the rest are scattered, including at least one guild-mark-adjacent
currency id and some crafting-material ids
I don't have a full categorized breakdown beyond that — flagging the
pattern rather than claiming a complete taxonomy.
Concrete impact I hit
While reverse-engineering the 1.0 client's shop and recipe data, I
misidentified one of these — 10007124 — as "Gryphon Leather" purely by
elimination (since its name is blank, I inferred an id from crafting
context and got it wrong). Cross-checking against
project-meteor-server PR #73's
independently-sourced recipe table caught the error: the item I wanted is
actually 10007208 ("Hippogryph Leather," a properly-named row), and
10007124 isn't used as a crafting result or ingredient anywhere in either
dataset. Full writeup in the RECONCILIATION.md attached to the
recipe-corpus offer in this same batch of contributions.
This is the kind of silent-failure-mode bug an [en]-named item causes:
nothing crashes, you just get plausible-looking wrong data if you're
inferring an id by context instead of by name. Any current or future
content (shop catalogs, tooltips, crafting UI, loot tables) that displays
or matches on these 934 items will show the literal string [en] or fail
name-based lookups against them.
Suggested next step
Not proposing a mechanical fix here — resolving 934 names correctly needs
real reference data (icon hashes, level requirements, cross-referencing
period item lists), not guessing. Flagging so it's tracked, and because the
934-row set + the one confirmed miscorrection above might be useful context
if anyone works on this table going forward. Happy to share the id list if
useful (grep "'\[en\]'" common/sql/seed/006_gamedata_items.sql | cut -d'(' -f2 | cut -d',' -f1).
Summary
common/sql/seed/006_gamedata_items.sqlhas exactly 934 rows whose namecolumn is the literal string
[en]instead of a real item name:(count checked with
grep -c "'\[en\]'" common/sql/seed/006_gamedata_items.sql)This is inherited data — the same 934 rows with the same broken name in the
same positions exist in the Bitbucket upstream's
Data/sql/gamedata_items.sql(project-meteor-server,developbranch),so it's not something this port introduced; it's a pre-existing gap in the
community
gamedata_itemsdataset both projects build on.Rough breakdown
From working with this table while extracting shop/recipe data:
11000xxxrange (quest/leve reward items)pieces)
currency id and some crafting-material ids
I don't have a full categorized breakdown beyond that — flagging the
pattern rather than claiming a complete taxonomy.
Concrete impact I hit
While reverse-engineering the 1.0 client's shop and recipe data, I
misidentified one of these —
10007124— as "Gryphon Leather" purely byelimination (since its name is blank, I inferred an id from crafting
context and got it wrong). Cross-checking against
project-meteor-server PR #73's
independently-sourced recipe table caught the error: the item I wanted is
actually
10007208("Hippogryph Leather," a properly-named row), and10007124isn't used as a crafting result or ingredient anywhere in eitherdataset. Full writeup in the
RECONCILIATION.mdattached to therecipe-corpus offer in this same batch of contributions.
This is the kind of silent-failure-mode bug an
[en]-named item causes:nothing crashes, you just get plausible-looking wrong data if you're
inferring an id by context instead of by name. Any current or future
content (shop catalogs, tooltips, crafting UI, loot tables) that displays
or matches on these 934 items will show the literal string
[en]or failname-based lookups against them.
Suggested next step
Not proposing a mechanical fix here — resolving 934 names correctly needs
real reference data (icon hashes, level requirements, cross-referencing
period item lists), not guessing. Flagging so it's tracked, and because the
934-row set + the one confirmed miscorrection above might be useful context
if anyone works on this table going forward. Happy to share the id list if
useful (
grep "'\[en\]'" common/sql/seed/006_gamedata_items.sql | cut -d'(' -f2 | cut -d',' -f1).