Failed to load MobData for NPC ID 688

[CollinHerber]

Description

On a fresh new world this message is prompted

Reproduction steps

Start a fresh character with a fresh world and note this message at the start.

Screenshots

No response

Logs

No response

[CollinHerber]

Enabled Mods

• Path of Terraria
• WMITF
• Subworld Lib
• Recipe Browser
• High FPS Support
• Boss Cursor
• Boss Checklist
• Atmospheric Torches

[ckeyboard]

I can confirm that this is caused by the Recipe Browser mod.

[CollinHerber]

I can confirm that this is caused by the Recipe Browser mod.

We'll want to resolve the compatibility issue given the subscribe count of Recipe Browser

[ckeyboard]

To replicate this bug for any NPC we've created in this mod, set this flag in its SetDefaults() method:

NPC.friendly = false;

Alternatively, we could clone the defaults of a hostile enemy for the same effect like Minera.cs does.

NPC.CloneDefaults(NPCID.Crimera);

This triggers logic that tells the MobRegistry to fetch the json file from the Vanilla folder.

foreach (Stream jsonStream in from path in jsonFiles where path.StartsWith("Common/Data/Mobs/Vanilla") && path.EndsWith(".json") select PoTMod.Instance.GetFileStream(path))

Therefore, everytime we add new hostile mod NPC's, we will see this error message, since their json files don't exist in Common/Data/Mobs/Vanilla.

However, we will only see this error message the 1st time we load into a world save file.

[ckeyboard]

Here's my proposed solution:

1. We create a new Mobs/Mod folder to hold the NetIds for our modded NPCs separate from Mobs/Vanilla
2. We do the same with our enums by spliting MobNetIdEnum.cs into
   1. VanillaMobNetIdEnum.cs
   2. ModMobNetIdEnum.cs
3. We register NetId 688 for Minera in ModMobNetIdEnum.cs
4. We amend MobRegistry.cs as follows

   if (Enum.IsDefined(typeof(VanillaMobNetIdEnum), data.NetId) || Enum.IsDefined(typeof(ModMobNetIdEnum), data.NetId))
   {
   int enumValue = data.NetId;
   if (!jsonDataMap.TryAdd(enumValue, data))
   {
       Console.WriteLine($"Duplicate NetId found: {enumValue}");
   }
   }
   else
   {
   Console.WriteLine($"Invalid enum value: {data.NetId}");
   }

[GabeHasWon]

How will MobNetIdEnum work? A constant enumeration would immediately fail if one or more mods load before us, plus it seems really inconvenient to hardcode constants for every modded NPC. We could just check NPCName.json for modded NPCs; modded NPCs being NPCs where npc.ModNPC is not null && npc.ModNPC.Mod is PoTMod. This would avoid loading and inconsistency issues entirely, and not require manually writing IDs.

[ckeyboard]

I like your solution of not relying on hardcoded id constants. The question is how should we go about adding the mod NPC data into the MobRegistry (assuming that's what we want do)?

If the data is not really important to us, we could simply ignore mod NPCs in MobAPRGSystem::ApplyRarity() altogether and be done with it.

public void ApplyRarirty(NPC npc)
{
    ...
    else if (npc.ModNPC is not null && npc.ModNPC.Mod is PoTMod)
    {
        // do nothing, we don't care about ModNPCs
    }
    ...
}

Otherwise we could update MobRegistry::Load() to include a new LoadModNPCMobData() method.

public void Load(Mod mod)
{
    _mobData = LoadJsonFilesToMapAsync();
    _modMobData = LoadModNPCMobData();

    // TODO: Concatenate _mobData with _modMobData
    //       Warn on duplicate NetId entries

    foreach (KeyValuePair<int, MobData> entry in _mobData.Where(entry => entry.Value.Entries.Count > 0))
    {
        Console.WriteLine($"Mob With Key: {entry.Key} - Registered");
    }
}

private static Dictionary<int, MobData> LoadModNPCMobData()
{
    // TODO: Compile a list of mod NPCs and associated MobData
}

[GabeHasWon]

I don't know all too much about this system, I can check in tomorrow if we want - but I know we'd want modded npcs to be registered. Mapping name to data is easy - assuming it's a PoT enemy, ModContent.Find<ModNPC>($"{PoTMod.ModName}/<NPCName>").Type will always give the NPC ID of the given enemy. Then we can use it to look up the data as normal. Loading means the IDs would be appropriate as long as we load data in PostSetupContent, as in Load it will not be set up and modded IDs are not finalized.