Changes to loot in generated Structures
#11
The default ones also - ok
No it isn’t. I already got a parser in lua - gotta move that to cpp.

The blocks is quite overkill yeah. At this point I added chests (any container - it‘s just the vanilla name) and mobs - that’s a nice tool too I think.

So we drop any other entity/block/...

Some monsters use the fishing loot table in their loot tables. This would be nice to include
Reply
Thanks given by:
#12
I thought about compiling them in as I thought about the performance impact. But even lua reads all files in less then a second and does some stuff to them. So that should be fine

In case i want to add a folder to the root directory and would like to include that in the provided zip file for download. What do I have to do?

and if there are no default loot tables provided do we want the cuberite binary to place them there or do users need to download the new folder? Although if the cuberite binary could put them there it already knows the contests of the file so it‘s not necessary so we simply provide it as a download and print an error if someone doesn‘t include the loot tables and warn them that gameplay might be impacted

Oh - another thing: 
I just understood something. No mob loots also. So forget about what I said. ONLY chests.
Do we want to add the other stuff (monster/fishing/...) in the Future?
Reply
Thanks given by:
#13
I think we'll eventually want all vanilla loot tables, but for now, simply concentrate on the generating ones (with the folder structure ready for later additions).

As for the top-level folder, no idea there, I guess @bearbin would know.

If there are no loot tables, no loot is generated, as simple as that.
Reply
Thanks given by:
#14
Yeah - adding the other vanilla ones should be fairly easy. I added all availeble options for the loot tables and plan on adding them to the interpreter/parser

I think i got it. cmake adds them to the build folder and i found a file witch is named "WindowsExecutables.list" and "UnixExecutables.list" and added them there


That's a word (and the best way)
Reply
Thanks given by:
#15
So I had an idea for the export from the galery server to the cuberite binary/serverd download

I wrote my interpreter that way that it accepts minecraft style loot tables so if you want to use a custom loot table for a structure you write one with such a tool.

The object reposible for providing the loot tables has a function which returns a loot table from string. If you want to add a non vanilla loot table you put it in a special folder and then gaining access to the table by asking the provider for the name you gave to the file without ".json".
Reply
Thanks given by:
#16
I‘d like to write some unit tests. But the way it is the main.cpp is included into the LootTable.h

I‘d like to split this so that the Parsing functions are in a separate file.

Now my question:
Is there a folder for such I-O-operations or just include it into the src folder?


I have another idea:

To mark containers to contain a loot table you put a item named like the loot table into the container.

And in the end there is a metadata tag with the relative pos of the entity and the loot table it should generate
e.g |x, y, z, "Chest|JungleTemple"|x, x, z, "Chest|JungleTempleDispenser"|...
Reply
Thanks given by:
#17
Unit tests: We have a few of those already, so you might want to copy the approach used in them. Basically they compile in the minimum amount of Cuberite CPPs and a Stubs file that provides dummy implementation of stuff that is needed for dependencies, but is not critical for the operation. Then just provide a separate main function that runs the tests. Have a look at the tests subfolder in the repo.

I think the loottable reference should be stored within the cBlockEntityWithItems directly (including NBT read and write in the world files and the schematic serializer). That way plugins can manipulate the loot tables. Do note that vanilla keeps the loot table info until the first player actually opens the container, at which point the loot is generated. There are commands to regenerate the loot in a container (which we should have, too).
Reply
Thanks given by:
#18
Quote:think the loottable reference should be stored within the cBlockEntityWithItems directly


So you meen the whole json file as a string? Or just a a reference to the loot table? Although both is possible. just check if it's valid json and parse it or try the lookup - else send error message.
The String m_LootTable is already written to disk when storing the BlockEntityWithItems

Another Thing about hardcoding:

The Loot tables refences so called "item tags" this is a feature of minecraft to reference multiple blocks a once through a simple string. (e.g. minecraft:bamboo_buildable_on -> bamboo, gravel,...)
I hardcoded them from the wiki and now i saw that you can export them from the server jar.

My Question:
Do we want to include that also into the cuberite files or do we want it in the binary?
Note: Vanilla minecraft doesn't allow editing on those files.

Edit:

I know that there is a function that let's you check if a cItem is of a certein type BUT i didn't find any function to return a cItems with all the items so that you can obtain all or any of the items described by the tag (which would be needed for the loot tables)

Edit 2:

If we do include them i'd suggest merging the (realy many) files to a single json file and using the name of the file as key to the object containing the actual values from the file.
Maybe even gzip the resulting file to prevent incidental user changes to the files.

Edit 3:

Then I'd add an object to root that does the handling and distribution. e.g.
Code:
class ItemTagHandler
{
    bool IsInItemTag(const AString & a_Tag, const cItem & a_Item);
    cItems GetItems(const AString & a_Tag);
}
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)