While experimenting with bo3's I noticed some strange behavior when bo3's are stacked on top of eachother using branching. To demonstrate what I mean, I created 7 bo3's that consist of a single coloured wool block, one of each is red, orange, yellow, green, blue, purple, and magenta. Each one of those bo3 has the next one set as a branch. Red (the bo3 in the custom structures resource) branches orange, orange branches yellow, green branches blue, blue branches purple, and purple branches magenta. All of them are set to branch at 0,1,0 (one y level above).
I expected this configuration would spawn a bunch of neatly stacked branches like this:
Thats hand built, because when terrain control spawns them, this happens:
The sequence of bo3's is almost completely random.
If you'd like to test for yourself you can download the 7 bo3's here. we-red is the first so just add that to your custom structure resource.
Just tried changing the spawnheight of all the bo3's from highestBlock to randomY and this happened:
So that does the correct sequence, only problem is that its floating in the sky.
I think you can add a blockcheck to ensure it only spawns on the ground. I haven't messed with BO3s much yet though.
Yeah, but then it just wouldnt ever spawn them. It might spawn them occasionally if the frequency was extremely high and by chance one ends up spawning at ground level, but that would still be a really inefficient way of doing it.
The Problem is the way the BO3 branches are Created. They are not Neccessary created in the right Order from their "base" Object, rather then some "Random" spawnOrder.
So, if you have your Objects spawn "On Ground" the Branches may Spawn first on the Ground, then the Next object spawns above it "On the Ground"
This is something thats Bugging me for a while to. As you cannot Overwrite Blocks of one Structure with a Branch. (For example i tried a Maze, where an Opening in a Wall would be Created when there was another Branch there. I dont need to say that it didnt work)
A way to fix this, would to find a way to force TerrainControl to Create the Branches in the right Order. But as i dont code, I dont really know how this could be done. The Only Way i could think of right now, could put a good deal of Stress to the Server on Creation of Chunks. So I didnt post this Shortcoming right now, as there are far more important bugs to fix.
I noticed this line on the wiki page for bo3's:
"The y-coordinate won't do anything if the SpawnHeight of the object that started the structure is set to highestBlock or highestSolidBlock. Instead, the branch will spawn on the highest (solid) block."
So I think whats happening is all branches are spawning at 0,0,0 on the same position. I tried setting the spawnheight of the first branch to "highestBlock" and then the height of all the branches after it to randomY, but it seems that the spawnheight setting of the first branch governs the spawnheight of all the branches afterwards.
I also did a bit more experimentation and learned a couple more things. When a bo3 spawns outside its source block and is not placed, it still spawns its branches.
The red wool bo3 was on "dontPlace" and wasnt placed, but it still spawned the orange wool branch. Not necessarily a bad thing, but good to know.
Other thing I learned is that BlockChecks are not working for some reason. I added this blockcheck "BlockCheck(0,-1,0,GRASS)" to the redwool bo3 and it has no effect:
Heres the modified we-red.bo3 if anyone wants to doublecheck my syntax:
I Didnt know that it wasnt in the Documentary.
But Block Checks are not Supported in Branched Objects. This might be easy for such Small Objects.
But the Branched BO3 are thought in a Bigger Scale.
The Problem is that the structure might be bigger than the generated Chunks, wich makes BlockChecks for these Parts impossible.
I talked with Rutger a bit about this problem, if i remember correctly, the only solution for this would be a file wich stores extra information about the structures, but this would have some weighty downsides. So, the Structures dont support Blockchecks.
Sadly i cannot explain how the system now works, because the discussion turned very fast to technical for me.
For your Interest, there are also no Blockchecks for self Colliding Branches, so you can create an Loop where many Branches of one object collide and ruin your Structure. (A Perfect example would be my first Nether Stronghold). So, you need to think about this aswell while creating your BO3 files.
did my own little BO3 branches testing now.
I managed to get my branches spheres to spawn at the wanted block (Air), height and distance to the center sphere.
2 thinks aren´t really nice still:
1. It seems to me, that TC don´t use all settings concernig the cardinal points.
The east, bottom, center and top spheres are spawned / placed like in its settings.
(better told, the settings in the start BO3, the center sphere)
But the north, south and west spheres are interchanged like shown in that screen here:
2. There is a small offset in the correct north / south and east / west lineup.
Looks to me simmilar to that oddness "must 90° right turn map.png" to get true north in TC / dynmap.
But now as I know what´s distorted and its pattern, I use my screen to "adjust" that hopefully always.
May be, somebody has better insights. If so, please explain.
TC-Mod Tutorial Part 1
TC-Mod Tutorial Part 2
Contact => please read first HERE !
I use the WorldEdit north, to determine where my Objects need to be Placed. Wich is the Correct North, TC uses.
I think it may be due to the values, as the Directions are values from 0 - 3, where 0 is Mostly Used as North.
Where Dynmap and other Mapping tools use the Sun as FixPoint for North, wich has an offset to the North wich is used by WorldEdit, and TC
Also, (i dont know if you thought about that) if your Objects are Rotated to the east of the Object, and you want to make it a branch, this Objects orientation still needs to be North not East. Because the Branch Origin orientation does matter, so the Branch Rotation is not really the direction wich the Object is Facing. Rather its the "offset" of the original Object its attached to.
Thist test of yours would be "More Accurat", with more Insight if you would have Used Arrows or More Complex Structures where you actually would see the Direction of the Object wich is branched.
So: if you make Objects branch each other, with the East direction, you would get a Circle.
I'll try to explain the BO3 branching here. Let's say we have made a fantastic custom stronghold (I didn't make one, so I'm just using an image from a vanilla stronghold, stolen from the Minecraft wiki). Terrain Control has decided a good place to start it. No chunks are generated yet which touch the stronghold. Here's a chunk map (click for larger image):
A player is approaching the stronghold, the green chunks are already loaded. Suddenly, a chunk is populated (marked red on the map). It should have a part of the stronghold in it, as you can see on the image. Keep in mind that all other chunks of the stronghold are not generated yet, Terrain Control only knows that a stronghold center will be nearby. But even without knowing what blocks there are in the ungenerated chunks, TC can already make a good prediction of which part of the stronghold should be placed in the chunk that is currently populated.
But let's say that the part of the stronghold that is highlighted in the orange box has a BlockCheck that should normally prevent it from spawning. How could that check be executed? The blocks needed to check on aren't generated yet. And we need to know now whether a stronghold part should spawn in the current chunk (marked in red). This has been solved by just ignoring the checks for now and allowing the part in the current chunk to spawn. Later on, when the player has walked further and the orange part is about to generate, that part simply won't spawn, causing a gap in the structure.
Edit 13 August 2013: the above paragraph has been updated to reflect that BlockChecks are now executed.
Khoorn's original idea was to simply don't spawn anything of the stronghold until the chunk with stronghold center is loaded. It would then spawn the whole structure at once, keeping all the unfinished BO3s in a cache. Every time a chunk generates, it checks the cache to see if there were structures to finish. Because the position of structure pieces is only calculated on loaded chunks, BlockChecks can be executed. However, this also means that the structure can suddenly appear in the face of the player: on the image, the player would suddenly be burried in a stronghold. It also means that the cache needs to be written to disk, because it needs to persist between server restarts.
Another problem is that another player might have already explored the right part of the map. Those chunks are currently unloaded so the stronghold didn't spawn there, all BO3s that should have spawned there were written to the cache. But because the chunk was already populated, the cache won't be checked again for that chunk, and parts of the stronghold will be missing. (Of course, this can be fixed by checking the cache every time a chunk loads from disk, but this will slow down chunk loading.)
Very enlightening. Couple questions though.
Quote from rutgerkok: GoHowever, when the BO3 has no other objects attached to it, the BO3 will perform it's block checks.
However, when the BO3 has no other objects attached to it, the BO3 will perform it's block checks.
Does this mean that a bo3 that is branched, but branches nothing itself (in other words, the final end branch in a series of branches) will work with block checks?
Also, could this not work like when a bo3 spawns outside its source block?
Quote from Smellyhobo101: Go When a bo3 spawns outside its source block and is not placed, it still spawns its branches.
When a bo3 spawns outside its source block and is not placed, it still spawns its branches.
So, if a bo3 failed its blockcheck, it doesnt spawn itself but it still spawns all its branches, eliminating the need to do the check you described above. I'm no programmer myself so I'm not sure if that would be possible.
It wouldnt be the ideal solution, but I think it would be better than disabling the blockcheck feature entirely.
thanks for that insight....even if its (I guess....) the top of the "iceberg" concerning BO3´s with all its complex syntax / settings and not (never?) solved things.
By the way, I get more and more at it and managed that settings to work like its wanted.
I used now this settings to get my spheres lined up to its names (purpose) and the cardinal points:
That branched BO3 is set to spawn in desert biome using this setting:
The BO3´s settings:
Zentrum Kugel (steinkugel.BO3):
Alle anderen Kugeln rundum:
That population thing is next I will test.
But most of my ideas may be put into practice even now by using the current capabilities.
Short view about veins and that setting in the configs ... or even using BO3(s) to get that done... I rely at plain old custom biome, custom height, resources settings and if necessary, replaceedBlocks, to get that job done.
Example image of a huge gold/diamond vein underground to spawn at any area I want and at at defined size / height:
(... but that´s something cpl. different ;-) ... I know)
Anyway, I revise my former refusal of that BO3 system as I get more and more taste at its special possibilities (in some special cases).
(But for sure, bo2 will hopefully never die, as its simple to create, to set up and to use in most cases, if its not to big.)
Thanks Lantoaster again for his insights (keep on researching please and tell here) and his illustrative material (f. i. the nether fortress).
I used this BO3´s, to make some editions/changes and put it in my "theEnd" biome, next to a reworked nether tower from Androkai, to give it some "life" ;-)
Thank´s too Ruthger, for TC 2.4.10 update, its working nice in my setup.
(I didn´t get any of the already reported crashes gladly ... )
Bye for now, mysource
You must login to post a comment. Don't have an account? Register to get one!