Feature requests + bug reports

[DylanDC14]

My friend mooing_cowmilk has used cubiomes a lot and had some suggestions and bugs to report so I posted it for him here:
(also sorry if I shouldn't have posted this all in one issue)

Feature requests:
-"Match Any" feature for biomes on as many versions as possible (ie pre-1.18)
-Or feature for structures (I want a village or igloo, maybe I just don't know how to use OR logic gate)
-noise search for older versions? (or heightmap search)
-Sub type option for structure (example: igloo with basement, bastion type, etc)
-bit search? As in I know some of the hex that needs to be fixed, but searches the rest.
(this speeds up certain searches if you know the results only happen when certain hex are a value)

Edits:
-make ctrl+c when in matching seed copy a single seed and not the whole list
(or make it when you press on the seed at the top it defaults to highlight seed)
-multi structure combo (example: I want two different villages within x range but both have a ruined portal)
-only x biomes, for example if one only wants ocean biomes to cover the full area, one has to
exclude every other biome leading to a very slow biome check (57 biomes to check instead of like 6)

Bugs:
-When asking for find A then B at A, it only checks the first A it finds and not each A
(this might be fixed already)
-Wrong village gen
seed: 677791744091383061 on 1.15 thinks village @ spawn
seed: -7132857384767862461 on 1.8.9 thinks village @ spawn
-Wrong Spawnpoint:
seed: 869274373 on 1.0 thinks -20, 196 when actually -188, 64

-End Gateway locations are wrong in 1.16 (seed: 1 @ /tp @p -1085 ~ -403 exist but not to cubiomes)
-Wrong ruined portal:
seeds: 6121517793503351804
1173469177906729972 on 1.18.2 thinks there is one but not
-Desert temple/ jungle temples don't generate sometimes 1.18+ due to too low terrain but cubiomes doesn't check this?

[Cubitect]

Whoa, that a lot...

"Match Any" feature for biomes on as many versions as possible (ie pre-1.18)

Implementing the "Match Any" option for 1.17- in a performant manner is a major implementation overhead as the current code was not originally designed for it, but it may be added at some point in the future.

It isn't as general, but by choosing biomes at a higher scale you can effectively search for groups of similar biomes (and it's very performance friendly). So for instance, a jungle at scale 1:256 has the potential to generate any of:
jungle, jungle_edge, modified_jungle, bamboo_jungle, bamboo_jungle_hills,
as well as river and beach biomes. You can see these by hovering over the biome check box.

Or feature for structures (I want a village or igloo, maybe I just don't know how to use OR logic gate)

To use the OR logic gate, you add it first, and then add the conditions that should be part of the expression by referencing the OR logic gate as the relative location. Here is an example: igloo_or_village.txt that you can load with File > Load session...
I should probably add an appropriate example filter.

noise search for older versions? (or heightmap search)

There was not much biome related noise in older versions. Height-maps might be added for 1.18+ to improve accuracy of structure generation, but it proves to be a difficult process. There aren't really any plans to add height-maps for older versions.

Sub type option for structure (example: igloo with basement, bastion type, etc)

Determining structure sub-types is not really a focus of cubiomes and gets added on a case to case basis, depending on the interest and difficulty to implement. Bastion types are a good candidate, since they have a well defined starting
piece. But structure pieces beyond the starting point (such as End City ships) are unlikely to be added.

bit search? As in I know some of the hex that needs to be fixed, but searches the rest.
(this speeds up certain searches if you know the results only happen when certain hex are a value)

This had actually been a plan early on in the development, but ended focusing more on the top-16 | low-48 bit split for structures and biomes. Do you need full control over the bits by specifying a bit mask? I think it would be best if this gets its own feature request with a bit more detail on the use cases.

make ctrl+c when in matching seed copy a single seed and not the whole list
(or make it when you press on the seed at the top it defaults to highlight seed)

Copying the seed list is something I frequently need. I could add a ctrl+c to the map view, so the current seed is copied when the focus is on the map.

multi structure combo (example: I want two different villages within x range but both have a ruined portal)

You can kinda do this by splitting the search area for the second village into separate areas around the first village and combine them with an OR logic gate, (Something like this: two_vills_with_portal.txt).
Admittedly, this is more of a hack and not particularly simple to setup.

only x biomes, for example if one only wants ocean biomes to cover the full area, one has to
exclude every other biome leading to a very slow biome check (57 biomes to check instead of like 6)

I'm not entirely sure I understand. You can already setup any combination of biome requirements with the inclusion/exlusion/ignored-tricheckboxes. When you specify a biome filter, all the requirements are tested at the same time, while the algorithm does its best to abort non-matching seeds as fast as possible. You already get close to the best possible performance.

Excluding biomes is usually more expensive to check since the area has to be fully generated to verify that the biome doesn't generate later on in the generation. When you don't mix biome inclusions and exclusions, the search can usually be aborted earlier. If you want to have a large ocean area I would also suggest running the exclude condition at scale 1:256 to avoid the later
generation layers (1.17-) entirely.

When asking for find A then B at A, it only checks the first A it finds and not each A

I'm guessing you are using an older version.

Wrong village gen

Indeed, there seems to be an issue with the pre-1.16 village generation.

Wrong Spawnpoint

World spawn cannot always be determined exactly by cubiomes since it requires a check for actual grass blocks rather than testing the biomes. So the spawn point position should always be regarded with a grain of salt. In very unfortunate circumstances the spawn point can up to 1000+ blocks off.

End Gateway locations are wrong in 1.16 (seed: 1 @ /tp @p -1085 ~ -403 exist but not to cubiomes)

I'll have a look.

Wrong ruined portal 1173469177906729972 on 1.18.2 thinks there is one but not

Checked and the ruined portal at (0, 16) for seed 1173469177906729972 in 1.18.2 seems to indeed fail to generate.
I'll have a look.

Desert temple/ jungle temples don't generate sometimes 1.18+ due to too low terrain but cubiomes doesn't check this?

This is a known issue, that also affects woodland mansions to a lesser degree, and is described in the cubiomes readme as well as in the description for the conditions. Unfortunately, Mojang has made it much more difficult to determine when these fail to generate.

[DylanDC14]

okay, he responded

Do you need full control over the bits by specifying a bit mask? I think it would be best if this gets its own feature request with a bit more detail on the use cases.

I notice when I was searching for a witch hut to intersect a pillager outpost, the output always share common bits. 00005c27d3dd | f771 was a result where the 7d3dd was always in the lower-48. (-616711672426933283)

Excluding biomes is usually more expensive to check since the area has to be fully generated to verify that the biome doesn't generate later on in the generation. When you don't mix biome inclusions and exclusions, the search can usually be aborted earlier. If you want to have a large ocean area I would also suggest running the exclude condition at scale 1:256 to avoid the later generation layers (1.17-) entirely.

Here is an example, if you want a forced ocean spawn (8,65,8) (pre 1.18), the seed must have no valid biomes and grass in a 512x512 area. Using an exclude on a large-scale setting works to remove big continents but misses smaller land masses. (I did use this trick on 1.18 to get super tiny islands like a mansion with no land). So, one must use a smaller scale to ensure desired results. Using the ocean example, the part I’m referring to is:
(see pictures)

(This method was also how I did an OR feature for biomes when excluding all others were fine). For 1.18+ this trick forces spawn point to be far out (on top of strongholds), way faster then using a spawnpoint test.

excluding 57 biomes is slower then doing like a almost OR feature with the biomes your fine with
difference is: doing an or is to include one of the list. but doesn't make the full area specficed that biome set
unlike that trick above
(not sure if cubiomes takes this into account)

Side note: I have been using cubiome viewer for a long time so I forget things that were patched out (like not checking all instances of A to get A,B), but nice to see support longer after the first version.

[Cubitect]

I notice when I was searching for a witch hut to intersect a pillager outpost, the output always share common bits. 00005c27d3dd | f771 was a result where the 7d3dd was always in the lower-48.

Exact relative structure dependencies often end up restricting the lower 20 bits of the seed. The quad-hut search actually utilizes this to precompute a list of candidates. (I described this a little better over here.)

I suppose it might be useful to expose an option for this to the user. Full bitwise control is not really necessary for this.

(not sure if cubiomes takes this into account)

The biome generation for 1.17- and for 1.18+ are completely different and have totally different optimization potential. Generation in 1.18 is much slower, but you can (or rather have to) generate each position individually. So the exclusion filter generates positions one after the other, and aborts when an excluded biome is found. Cubiomes optimizes which positions are checked first so the exclusion can be determined more quickly. For 1.17- the layered generation has to finish the whole area before an accurate assessment can be made for the biome exclusion. This will be more or less independent on the number of biomes that you exclude. On the other hand, the inclusion of different biomes can be a lot faster in 1.17- since the generation can be aborted at early layers when the required dependencies are not met. It might be possible to also do at least some checks on early layers for exclusions, but currently cubiomes has no specific optimizations for this. However, you can chain multiple conditions for exclusions at different scales, starting with the largest. This is not 100% accurate, since you will falsely skip some seeds, but it simulates to some extent the optimizations that are done for the inclusions.

[Cubitect]

-Wrong village gen
seed: 677791744091383061 on 1.15 thinks village @ spawn
seed: -7132857384767862461 on 1.8.9 thinks village @ spawn

It seems there are actually a bunch of things going on here. On the surface the algorithm for village placement has not changed since forever (except for adding more variants), and Cubiomes (as well as other tools like Chunkbase and KaptainWutax's FeatureUtils as far as I can tell) assumed this to be the case. But it turns out villages had plenty of subtle changes.

• In 1.9 and earlier, villages performed two biome checks, the first made sure the biome was okay for villages, and the second biome check determined the village type. Strangely, the second one was at a slightly different position than the first. If the village type is invalid from this, you would essentially get a zero-size village.

• In 1.10-1.13 villages generate in more biomes and no longer fail to generate when they move into invalid biomes, so the second check is irrelevant.

• 1.14 added snowy_tundra villages.

• 1.15 villages now use the same biome checks as other structures, which occurs at block (9,9) inside the chunk at scale 1:1 with a new voronoi scaling.

• 1.16 made structures use the 1:4 scale for biome checks which now occur at position (2,2) in the start chunk.

These changes have been added to cubiomes, and will be in a cubiome-viewer release in the near future.

Wrong ruined portal 1173469177906729972 on 1.18.2 thinks there is one but not

Portals can generate in all biomes with no terrain restrictions and thus generation attempts should not fail. This is a bug in the MC code that cubiomes cannot emulate. When there are underground biomes, the game can get confused about the biome variant it chooses for the portal. The way in which this happens I suspect that there are also places with two or more ruined portals in the same chunk...

[Cubitect]

Patch v2.2.2 should have fixed many of the structure generation issues outlined here.

Spawn, ruined_portals, desert_pyramids, jungle_temples and mansions remain inaccurate to varying degrees due to block-level or surface height dependencies, and will not be fixed (any time soon).
If you find any more inaccuracies let me know.

[mooing-cowmilk]

Village still have some inaccuracies in Patch v2.2.2.
on 1.8 (I'm playing on 1.8.9):
276408427129916803 thinks village at /tp @p 0 ~ 64
570831252769262979 thinks village at spawn

Hope there isn't structure changes in a subversion.

[Cubitect]

I checked, and these villages fail to generate because they contain no actual houses. The starting piece can generate, but the first and only house is not in a valid biome which aborts the entire generation. I don't think cubiomes will support testing for this case, since it requires simulating the full village house generation.

[Cubitect]

The match-any option has been expanded to support 1.17 and below.

[Cubitect]

Closing in favor of #154, since most of the issues outlined here have been addressed.