SDE is missing metaGroupID for several ships

[SustainedCruelty]

o7,

As of 11 December 2025, there are 45 ships in types.jsonl that are missing their metaGroupID.
As far as I can tell, this only affects ships and not modules.

I’ve attached a CSV of all the relevant ships.
Please let me know if there’s any other information I can provide that would help with fixing this.

missing-metagroups.csv

Thanks in advance

[ccp-pinky]

Thank you for the report!

Currently the SDE can be a bit inconsistent what a missing field means. Most of the time it means it is having its default value. And that is also in this case: the fact metaGroupID isn't mentioned, is because it is 0. We do have long-term plans to address this a bit, but nothing short-term.

But more importantly: your ticket as it stands is just an observation. So that made me wonder: why did you run into this? As in, was this actually a problem for you? And if so, can you elaborate a bit on why it was a problem?

Answers to these questions helps us better prioritize issue. Tnx!

[Nohus]

Related to #1443, all types with a radius of 1 don't have the radius field in the SDE. Assuming because that's the default and defaults are not encoded.

[SustainedCruelty]

Thank you for the report!

Hey, thanks for the quick response!

Most of the time it means it is having its default value. And that is also in this case: the fact metaGroupID isn't mentioned, is because it is 0.

Sorry, I don't get what you mean by that. Why would a metaGroupID of 0 ever be a valid value for a ship? There isn't even a metaGroupID 0 in metaGroups.jsonl

Looking at T1 Dreadnoughts for example:

TypeId,TypeName,MetaGroupId,MetaGroupName
19724,Moros,1,Tech I
19722,Naglfar,NULL,NULL
19726,Phoenix,1,Tech I
19720,Revelation,1,Tech I

Why is the Naglfar not a T1 Dreadnought but the other ones are?

Another great example are shuttles:

TypeId,TypeName,MetaGroupId,MetaGroupName
11134,Amarr Shuttle,NULL,NULL
672,Caldari Shuttle,1,Tech I
34496,Council Diplomatic Shuttle,4,Faction
11129,Gallente Shuttle,NULL,NULL
21097,"Goru's Shuttle",3,Storyline
21628,Guristas Shuttle,4,Faction
30842,InterBus Shuttle,NULL,NULL
11132,Minmatar Shuttle,NULL,NULL

Caldari Shuttle is Tech 1 but not the other racial shuttles?

But more importantly: your ticket as it stands is just an observation. So that made me wonder: why did you run into this? As in, was this actually a problem for you? And if so, can you elaborate a bit on why it was a problem?

When I want to query for all T2 ships, I should be able to do this: (which I can't)

WHERE metaGroupID = 2;

Instead I tried using the Meta Level from the Dogma Attributes:

INNER JOIN dgmTypeAttributes dta
ON it.TypeId = dta.TypeId
INNER JOIN dgmAttributeTypes dat
ON dta.AttributeId = dat.AttributeId
AND dat.AttributeName = 'Meta Level'

WHERE dta.ValueFloat = 5.0;

Which also doesn't work by the way, because T3 ships like the Jackdaw also have a Meta Level of 5.0

Thanks to this I'm forced to look at the metaGroupID of the blueprint that produces the ship, which adds a few more joins just so I can filter between t1, t2 and t3 ships...

[ccp-pinky]

I sense a bit of frustration; I can understand that, but please understand I am just trying to understand your use-case :) Either way, thanks for the detailed info, very useful, and something I can use to put some priority on it :)

The main reason the metaGroupID isn't filled, is because in-game actually doesn't care about it as such. For example, if you go in-game to one of these ships and "right-click, Compare" on them, you will see that they are marked as "Tier 0" for the Meta Level.

Not saying that is correct; but the SDE is the same data as in-game is dealing with. So we can't solve this in the SDE, but I will forward this to the team responsible for this, so they can fix this in-game. The SDE will then update based on that.
To set realistic expectations, this might take a while to get fixed. But at least it is in the pipeline :)

[SustainedCruelty]

Got it, thanks a lot for the detailed explanation and for forwarding it to the right team; that's really appreciated.

Sorry if my last message came off a bit strong. I'm sure you know, bugs like this, where only a small piece of the data is "off" are really hard to track down when you're building queries and aggregates, so it can get a bit frustrating to debug.

Thanks again for taking the time to look into this
Fly safe o7