Changes to loot in generated Structures

[12xx12]

This is just a collection of ideas from me and some issues.



As discussed here the Prefabs/PiecePool needs some changes to natively support loot (chest, furnace, dispenser,...)



Also the GalExport plugin would need some changes. to support the new features

• export if there are loot containers in the structure
  

• exporting the position of the blocks that need loot. No need to calculate that during generation
  
• export which loottable to use/export custom loottable
  Note: The custom loot table could be quite messy on entring. I'm not quite shure about this
  

Things I would add to the Prefab/PiecePool are:

• filling chests during generation
  

Things tied to this are:

• Adding Loot tables to the server [This is a great help shortening the needed data in the cubeset]
  

Things I'd like to do while at it:

• different growth steps in generated fields in villages. I don't know which class will do this at this point [issue]
  

• Add new types of fields to villages (different crops) just by a new structure on the gallery server
  

Are there any other things I missed?

Do you have any notes?

[xoft]

I'd recommend doing something similar to vanilla's loot tables: https://minecraft.gamepedia.com/Loot_table

If I understand that correctly, there are data files that describe the loot to be generated in different situations, and containers can reference them (by filename). There is a way for custom worlds to override the default loot tables, simply by having appropriately-named files in a specific subfolder within the world folder. I think this behavior can be copied to Cuberite.

As for assigning loot tables to containers, we have a cBlockEntityWithItems class that is the ideal place to implement the loot table handling, including the saving and loading. Since cBlockArea supports block entities, this will give support to loot tables to the cBlockArea class, and there's only a single missing step of exporting / importing them via cubeset files, which would need implementing by the GalExport plugin.

We'd also need an loot table editor, most likely implemented in the GalExport plugin as a separate web tab, each area would have a list of containers and associated loot tables.

One possible extension to the Vanilla system would be custom loot tables, specific for a container. Instead of storing a filename in the LootTable tag, we could store "verbatim:[json]" with the loot table stored directly in the tag.

[xoft]

One thing to note that I haven't noticed before: Vanilla doesn't generate the loot from loot tables upon world generation, but rather when the actual container is opened by a player. This is a useful change that can would be useful for plugins to intercept (especially the GalExport plugin could make the server NOT generate loot in the Gallery and instead keep the loot table)

[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"

[12xx12]

Ok there are way more things in the loot table

[12xx12]

Oh S**T here we go again...

Again another feature you need to implement to accomplish another.

So... When parsing the loot tables you would go mad. The Files use the new item names and the server uses it's own internal names for items.

Is there a way to obtain the old item type eum from a string in the new namespace?

Else i would need to move everything to the new item enum class I think.

[xoft]

I think for now just use StringToItem() on the value, possibly removing the "minecraft:" prefix; and we'll fix it once we finalize the 1.13 compatibility. If the item fails to parse, just drop the loot table entry, with a warning into the console.

Small incremental steps

[12xx12]

my plan was to write a lua script that takes all loot tables and puts out a long cpp file whitch is filled with loot table classes

using the strings feels like a hack and is then interpreted at any time a loot is placed.

i didn't even think about parsing custom loot tables.

One thing we have to think about is: vanilla does have a loot table for any item. Do we want to do this too? or do we want to keep the way we do it now or do we want to keep the way it is but check if there is a custom loot table for this block?

[12xx12]

another thing I thought about is that it makes most sense to use the Minecraft style loot table format in json for custom loot tables. there are some generators online for those and creating them by hand is quite annoying so this is the user friendliest way

[xoft]

We definitely want the loot tables to be loaded at runtime, not compiled in. Since there's already a json parser in Cuberite, it shouldn't be that much of a problem.

We don't need the loot tables for broken blocks or for gameplay actions for now, we're fine with just the container ones.