Changes to loot in generated Structures

[12xx12]

Using the vanilla way seems a good approach.



The Loot tables

---

The wiki says that they're json files. I exported them and for ANY avaiable item/block/entity ther's a loot table.

The question is if we want to have default loottables exposed for the user or if we include them in the binary. I think that the binary solution would be best.



There is a thing describing a loot table BUT its behaviour doesn't match the vanilla one.

There are secondary loot tables,...



New Classes

---

cLootTableProvider:
[stores custom loot tables (see below)]
[interprets loot tables exported from the GalExport plugin (see below below)]

• GetLootTableFromString: returns a loot table from string (used in generator to get right one for filling)
  

• This needs some more functions to get the loot tables from any other object/mob...
  
• m_CustomLootTables. A map from %WHATEVER% to cLootTable
  

cLootTable:

• Declares individual loot table.
  
• FillWithLoot: Function to fill a block entity with loot
  
• m_Pools: Array of cLootTablePool
  

cLootTablePool:

• Represents a pool in a loot table
  
• m_rolls: describes the number of rolls in the pool.
  
• m_entries: array of cLootTableEntry
  

cLootTableEntry:

[Vanilla has added a descriptor that the entry is a item, removed this as only items can be contained in a container]

• m_weight (weight for random distribution)
  
• m_name (name of the loot)
  
• m_functions (array of operations on the item) [i'm not quite shure if there are any blocks/items with multiple functions]
  

cLootTableEntyFunction:
[This supports a range of various parameters for the function]

• m_Type: cLootTableEntryFunctionType
  
• m_Parameters
  

enum class cLootTableEntryFunctionType:

• ApplyBonus
  
• CopyName
  
• CopyNbt
  
• CopyState
  
• EnchantRandomly
  
• EnchantWithLevels
  
• ExplorationMap
  
• ExplosionDecay
  
• FurnaceSmelt
  
• FillPlayerHead
  
• LimitCount
  
• LootingEnchant
  
• SetAttributes
  
• SetContents
  
• SetCount
  
• SetDamage
  
• SetLootTable
  
• SetLore
  
• SetName
  
• SetNbt
  
• SetStewEffect
  
  

I think most of them can be structs as they are just read and iterated over if there are lists in it. The heavy lifting is done in the function of cLootTable::FillWithLoot.



Custom Loot tables

---

So upon world load we search for any custom loot tables.

I would suggest looking for them in a seperate folder e.g. world/loottables/%name%.loottable.

The %name% might be also a folder. as there are multiple loot tables for one block (e.g chest)

Probpably best in LUA for easy parsing and consistency.



so this would be world dependent this would require some changes:

• the cWorld object would have a cLootTableProvidertable object which handles the loot table reqeuests
  
• generators that use loot tables need to have a pointer to the world objects to access loot tables
  

Implementation Details

---

I saw the cBlockEntityWithItems class, I agree with you.

So we can assign in the block area without caring about the actual placement of the block in the end?



If we only assign the metadata during export there won't be any loot on the galery



Exporting from gallery

---

The web editor would be necesary if we want to add that. I would start with the implementation in the server.

I'm thinking about a way to add a less messy way to add default loottables by using metadata from the set like e.g.

["ChestLootTable"] = "ChestDesertTemple"