+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Changes to loot in generated Structures (/thread-3308.html)
Pages:
1
2
Changes to loot in generated Structures - 12xx12 - 08-27-2020
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:
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?
RE: Changes to loot in generated Structures - xoft - 08-27-2020
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.
RE: Changes to loot in generated Structures - xoft - 08-27-2020
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)
RE: Changes to loot in generated Structures - 12xx12 - 08-27-2020
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]
[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
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
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"
RE: Changes to loot in generated Structures - 12xx12 - 08-27-2020
Ok there are way more things in the loot table
RE: Changes to loot in generated Structures - 12xx12 - 08-28-2020
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.
RE: Changes to loot in generated Structures - xoft - 08-28-2020
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
RE: Changes to loot in generated Structures - 12xx12 - 08-28-2020
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?
RE: Changes to loot in generated Structures - 12xx12 - 08-30-2020
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
RE: Changes to loot in generated Structures - xoft - 08-30-2020
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.