Leaderboard

Block properties aren't meant to hold that amount of possible values. use tile entities instead

We currently have the ability to add fluids to all entities, but no real system to handle the fluid itself. Specifically, I will be talking about the associated physics as the client side effects are simply just fluid checks with events. The relevant common code effects can also be matched using the many provided events added by Forge. There are a few places where relevant tagged data would need to be check for custom fluid handling, but its less important for the purposes of this post. To make a minimum viable fluid with unique physics, one must apply two methods provided within the entity: Entity#handleFluidAcceleration which does exactly what it says and Entity#func_233571_b_ which grabs where the entities eyes are within the fluid level. Both of these are used in different places. The first is used within the entity tick via Entity#func_233566_aG_. The second is used to determine if the user might be jumping off the ground within a fluid, moving through fluid, swimming in fluid, etc. Exposing this would result in some class object or registry that would store the associated fluid tag, a function given the entity and returning the acceleration, a consumer containing the entity if the fluid acceleration returns true to update a specific state. The fluid code would also need to be patched within LivingEntity#livingTick to check the tags for the correct fluid the entity is in when jumping and whether or not entities can swim within it. I want to discuss what would be the optimal way of storing and handling these instances. Creating an event is out of the question as its unnecessary ticks for a portion of the code that can be handled with a registry. It would also be good to consider fluids in some sort of dynamic context where existing hardcoded traits could be genericized in some fashion. However, most of this code dances in the realm of tags, so there would need to be some discussion on how to handle and comply with Forge's stance on tags.

I don't want to call anything that is not reversible "storage". Because storage implies reversible. You would not store your quartz as quartz blocks as then you lose it when you need to craft comparators. I went with decorative as all 2x2 recipes are for the sake of decoration thus far, but its a fair point that it may be a bit vague. "compressed" or "packed" are two words that come to mind, but both are used in mods or vanilla for 3x3 at this time. "bricks" is another option, but would probably hit confusion with the stone brick style blocks, so not sure what else to suggest as a prefix.

I would rather not use "decorative_blocks" because that doesn't really say what they are, and people may start adding other "decorative" blocks into the tag. Maybe "small_storage_blocks" or "storage_blocks_2x2" or something similar would be better. As for the actual blocks, there are more than just quartz and copper which would fall into the 2x2 tag: Glowstone Clay Snow Honeycomb Honey (reversible, but requires 4 glass bottles) Magma Cream Quartz Copper (reversible, but I think only if the block isn't weathered?) Amethyst Sandstone (possibly? It's a bit different being block -> block, but follows the same irreversible principle). Prismarine (has both a 3x3 "prismarine_bricks" and a 2x2 "prismarine" recipe. Both are irreversible). Purpur (probably not, the recipe produces 4 blocks, so more of a conversion like the various stone types).