Allow bigger color palettes for param2 "color" blocks.

[DragonWrangler1]

Problem

I've run into several cases where I need more than just 256 px for my blocks. An example is trying to colorize the blocks in more than 256 biomes, or trying to blend between 200 colored biomes.

Solutions

A solution to this could be a paramtype3, (would most likely be non-trivial). Another advantage of this would be. In #15180 Since each flowing liquid is limited to only 16 colors due to 16 values being used up by the level of the liquid. 256x256 palettes, would increase it to 4096 colors.

Alternatives

For the listed usecases. I can't think of any alternatives.

Additional context

No response

[NathanSalapat]

You can always just create a few nodes to achieve the number of colors you want. More_dyes does this.

[DragonWrangler1]

You can always just create a few nodes to achieve the number of colors you want. More_dyes does this.

Only in part. With the water it's not quite that easy as You can't randomly change from one flowing node to another. So even with water you're still limited to 16 colors.

You could argue that yes, you can register more blocks for that too, however that'd also have a good chance for unwanted behaviour. ie. Water flowing from one biome into a biome that doesn't have a color for it. If you could easily change the flowing liquid at any point, then There'd be no need for this issue.. (Though perhaps this would be better to request the flowing liquid change rather than the very complex param3 addon..)

[appgurueu]

I can't think of any alternatives.

I have a large alternative and somewhat far-fetched vision.

I think ultimately adding more hardcoded params and meshgen features sucks for a couple reasons:

• Mods and games which don't use them still pay the cost for them (can be alleviated to some extent at the cost of more complexity).
• You quite frankly get a mess in the engine, because you end up covering various game logic use cases in the engine. Just look at the current list of param2types. The engine now has to handle all kinds of different drawtypes game developers can imagine, and all kinds of bitpacked variants of those.
• This mess will also generally be too inflexible to cover all use cases, so modders still end up disappointed if the drawtypes they want aren't there.

Now, in the grand scheme of things, I think the ideal solution is roughly the following:

• Allow games (mods; but this is best used by game mods specifically) to define dense auxiliary node data, effectively implemented as out-of-band typed arrays. Think numpy (or Python's array which nobody knows about because of numpy) at home when it comes to providing a VoxelManip interface for these. All kinds of params then become possible, whether they relate to rendering or something else. ¹ This is a bit like metadata, but metadata is designed for sparse data; this would be designed for efficient processing of dense data.
• Analogeously to metadata, allow marking which part of this should be sent to clients.
• On the client, let SSCSM hook into meshgen efficiently (far from trivial; similar to mapgen, might require async workers to be efficient enough) to then leverage these params.

Footnotes

1. There are users who would want to propagate temperatures for many nodes in the world, for example. ↩