Biome independent structure table

[IntegratedQuantum]

This is important for lore-related structures as well as generic rare structures such as Meteorites #1283

[codemob-dev]

Maybe we could use _defaults.zig.zon?

[IntegratedQuantum]

No, I want these structures to apply even to (and from) other addons.

[codemob-dev]

What if we separate all structures from biomes, and use biome tags similar to what was suggested for music? Then we could use an empty tag list to mean affecting all biomes.

[Orbwinder]

It would be a useful capability to whitelist/blacklist entire biome categories so that an "igloo" structure addon could specify that it spawns in all .cold biomes that are not also .isCave

[IntegratedQuantum]

We could use biome tags for that I guess.

[BoySanic]

I thought I would post a comment with the approach as I see it:

• New structure table type that encapsulates:

  • id
  • biomeTags (cubyz:cold, cubyz:hot, etc)
  • structures (biomes.structures as we currently know it)

• Biomes no longer directly store a structure table in their zon file.

• Biomes now store a biomeTags element to associate structure tables to biomeTags

• During asset loading:

  • Structure Tables
    • Load each available .zon in assets/cubyz/structure_tables (or assets//structure_tables
    • Builds a [][] const u8 of the structure table IDs to lookup later
  • Biomes
    • Replace structure table load logic with:
      • Loop through all loaded structure tables (via the ID list from earlier, Structure Tables would need a getById or something)
      • If a structure table has a biometag that matches the biome, or the structure table has no biometag, concatenate the contents of that structure table to the biome's internal structure table
      • Add totalChance as we did before, normalize if > 1 as we did before.

I think this would be the simplest implementation.
In my experimentation so far it would involve moving the hashing functions out of src/server/terrain/biomes.zig but I think we can toss that in src/utils/hash.zig or something. I would also agree with sticking it in src/server/terrain/hash.zig since only biomes and structures use it atm

[codemob-dev]

• Biomes no longer directly store a structure table in their zon file.

This seems unnececarry, why remove the useful organization of putting structures in the file for their biome? Why not allow both versions?

[Argmaster]

I think you misunderstood the purpose of this change. It is not intended to replace existing system, but to extend it. We need a way to spawn things that are not attached to specific biomes, although I am not sure how specific we will want to be about where we spawn that stuff.
At least that is my interpretation of the issue.

[BoySanic]

I think you misunderstood the purpose of this change.

I guess I do see the usefulness of keeping biome-specific structure tables.

My revised proposal:

• New structure table type that encapsulates:

  • id
  • biomeTags (cubyz:cold, cubyz:hot, etc)
  • structures (biomes.structures as we currently know it)

• Biomes now store a biomeTags element to associate structure tables to biomeTags

• During asset loading:

  • Structure Tables
    • Load each available .zon in assets/cubyz/structure_tables (or assets/addon_name/structure_tables
    • Builds a [][] const u8 of the structure table IDs to lookup later
  • Biomes
    • Load structures as we did before, then:
      • Loop through all loaded structure tables (via the ID list from earlier, Structure Tables would need a getById or something)
      • If a structure table has a biometag that matches the biome, or the structure table has no biometag, concatenate the contents of that structure table to the biome's internal structure table
      • Add totalChance as we did before, normalize if > 1 as we did before.