Adding Generator For Single Prefab Structures
#1
Lightbulb 
So I had a look around in old issues and found the one asking for a generator which generates single piece structures like jungle temples, dessert temples...



There is the cGridStructGen generator which would makes sense to use because these structures are placed more or less on a grid.

So this is the generator I would use.

Further research shows this is more or less biome dependent so maybe change the generator


I thought about creating just one generator and passing the type of structure to generate to the constructor which takes care of everythin else. So further additions would be easier

The Generator would be handed the placement parameters and the type. Dependent on the type it would load a different file.



The Generator would need a prefab loaded into memory like in the piece structure generator (e.g. villages) but only once so I need a way to store that.
I had a look around on the Galery Server and found some models. And multiple ones for one structure so the the class should hold multiple options for one structure



Madmaxoft already noted that it should be configurable if the generator places those structures. I put it that way that the Generator checks if the world.ini includes the structures in the "Finishers" parameter.



So the flow would be



1. Composable Generator checks if the structure should be genrated; if "no" don't; else

2. call the PrefabSingleStructure generator with the asked structure to generate

3. load the structure from file (like with the other prefab pieces)

4. the cGridStructGen should handle everything else



There are some edge cases to be checked on each strucure:

e.g. DesertTemples may be generated into water and get cut off



Some of the strucutures contain chests which need to be filled. A chest entity function takes care of that.



The loading from file is coded into the cPrefabPiecePool. This could be reused for this purpose. I thought abbout creating a class that does care of that avoiding stupidly copying some code. But since there are only two types of generated structures this makes no sense so i will copy the code neeeded.

Using the cPrefabPiecePool is possible (I think) but is way to overpowered for this use.



I would start making the Desert Temples work and everything else should be not that bad.

Structures I Found on the Galery Server:

Desert Temple: Desert 48 + 49 + 115
generates within desert always at height 64 (may be burried in sand) (contains loot) [https://minecraft.gamepedia.com/Desert_pyramid]
Jungle temple:                                  
generates within a jungle - generated with a chance of 3/4 in jungle (contains loot) [https://minecraft.gamepedia.com/Jungle_pyramid]
Witch hut:                                        
generates rarely in swamp biomes - spawns whitches and only lets spawn black cats [https://minecraft.gamepedia.com/Swamp_hut]
Desert well: Desert 221                     
generates with the chance of 1/1000 in a desert chunk [https://minecraft.gamepedia.com/Desert_Well]

Structures NOT in vanilla but still nice
Plans 341 (Flying Island with Flowers)

BigPlains 1 (Creepy ghost house)
Reply
Thanks given by:
#2
Welcome to the forum Smile

Some thoughts I have about this:

There may be multiple prefabs for one "structure", so it makes sense for the single generator instance to load multiple prefabs at startup. Ideally, this would be from a file "Prefabs/SinglePiece/<StructureName>.cubeset". Note that "Prefabs" folder is already present and has other prefabs, and that a single .cubeset file may store multiple prefabs, which is ideal for this use-case.

Prefabs already have support for properties defined on them (metadata), the cubeset file includes those properties. The Gallery server stores them in a DB for each prefab, and has a web-based editor for them. There's also per-cubeset-file properties. The file-level ones can be used to define the grid size for each generator, the prefab-level ones can be used to limit the biomes, heights and possibly other factors regarding when that individual prefab is considered for generating and where it is placed.

cPrefabPiecePool already handles most of these, so it is actually the ideal class to use for this.

Please call it SinglePrefabXYZ, not PrefabSingleXYZ Smile

The Gallery server backups are available (see https://forum.cuberite.org/thread-1372-post-12382.html ), download the latest backup and run it in your own server, then you can see the full webadmin support that the plugins give. Unfortunately I can't give out webadmin access to the Gallery server to anyone, basically it transitively gives root access to the machine running the server, and I don't trust you that much just yet.

I don't think your flow is right. We don't want the cComposableGenerator to be modified for this at all, except for adding a new Finisher it recognizes. Instead, add a new Finisher called cSinglePrefabStructureGen, base it off of the cPieceStructuresGen (constructor does nothing, Initialize reads the cubeset etc.), which contains a single generator instance for each cubeset file specified in the Finishers world.ini line. So for example the line "Finishers=SinglePieceStructures: JungleTemple|WitchHut|DesertWell" will create one instance of cSinglePrefabStructureGen containing three instances of cSinglePrefabStructureGen::cGen (the actual generator), each handling the single cubeset.
Reply
Thanks given by:
#3
Thank you for your welcome   Blush

I already saw the other prefab files and thought about doing exact that thing

I'm gonna check the cPrefabPiecePool then if it works without any connections

That's nice with the web editor
May I export them for me and commit them myself or do you have to do this from the "official" gallery server?

Yeah i just needed any name to understand the flow of the generator this is defenetly gonna be changed.

What? No - root is way too much - downloading seems fine. And of course you don't give any guy from the internet your computer.

the only things i wanted to add in the cComposableGenerator is the checks if the user asked for the generation and calls the generator. (like for every option avaiable)
Maybe we add a new line in the config file for the single piece structures to prevent the "Finisher" line in the config file from getting to long and unreadable.
Then we could pass the string if anything is in it to the generator and make it handle it
Reply
Thanks given by:
#4
Only a note about not using the Finishers line - the order in which the generators are listed is important, that's why you need all of them listed in a single place. What if the admin wanted to put WitchHuts with high priority (at the start of the list) and DesertTemples with low priority (at the end of the list). It may not make sense for these two specific prefabs, but it could make sense for custom ones.

Yes, that line is getting ridiculously long, and the config is convoluted, we know, but so far we haven't been able to do better. There were talks about moving the config files from INI to other language (Lua being the most natural choice), but none of them support all the features we want, the usual problem is keeping comments on a load+save cycle.
Reply
Thanks given by:
#5
You can export the pieces yourself, but for a permanent solution we need to actually mark the areas as approved and edit the metadata on the primary Gallery server. So once you decide what areas to use, let me know so that we can change that on the Gallery server.
I believe you won't need webadmin access to the Gallery server for approving areas, and the metadata can be somewhat edited in-game, too, so you can do those changes once I raise your rank on the Gallery server.
Reply
Thanks given by: 12xx12
#6
I can't export on my own server - i have opened an issue on the GalExport Git

https://github.com/madmaxoft/GalExport/issues/44
Reply
Thanks given by:
#7
So I did some research in the code:

The generation with the cPieceStructureGen is not that good (as you already mentioned here) because the backend expects at least one connection.

So this would result in cSinglePieceStructureGen (New name) similar to cPieceStructuresGen.
This will keep the piece pool and selecting one of the starting pieces but ditchin the whole BFS-thing and just placing them there.

If there's a chest in the structure the generator fills them althoug I would make this dependent on the name of the generated prefab
The Generator must implement the method DrawIntoChunk by cGridStructGen to have access to the chund data to place the chest entity
Reply
Thanks given by:
#8
Ok so now the flow is

cComposableGenerator checks if there any single piece structures asked for and hands the list over to cSinglePieceStructureGen

for every structure specified cSinglePieceStructureGen adds a generator placing the structure.
this is achieved by loading everything into a piece pool and then choosing one of the structures avaiable. they MUST be defined as starting strucutres because they are only accesuble directly

if there are chest in the structure they are filled by creating a new prefab that fills all chests in the structury with the given items.
This has to be determined by hand. i dont think the prefabs support this.
Reply
Thanks given by:
#9
If I were you, I'd ditch the chests for now - they should be handled by some universal code that will work for all prefabs, not just the cSinglePieceStructureGen. What we want is basically a similar language that the vanilla has for loot tables, which would be stored directly in the prefab containing chests (and possibly other containers as well). So for now generate chests empty in those structures, and then in a separate PR implement the loot tables.
Reply
Thanks given by:
#10
Heh, and welcome to Cuberite development - you want to do something, but find out you first need to fix one thing, then fix another thing, and then yet another, and before you know it, a year goes by with you only fixing unrelated stuff and only then you finally can start on the thing you wanted to do in the first place.

The same happened to me when I joined, wanted to do worldgen, ended up fixing thread locking, socket threading, writing lighting, splitting away simulators and only then finally worldgen
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)