Block Entities for Redstone?

[StockiesLad]

Current Limits

The current system from Minecraft is not designed to be extended the likes of which you did. Single-handedly adding that much more performance-cost for one mod is not practical.

Envisioned Solution

It is far more sensible to use BlockEntities, and a BlockEntityRenderer to actually handle redstone. Unfortunately, this means you have to rewrite basically everything (including nuking the current redstone system, which is subject to parity breaks).

• Store power levels as a field in an enum: "PowerType" with 4 fields.
• In the Block Entity data, you store a byte array of length 4. The ordinal of the PowerLevel then corresponds to the index of the array, where it's respective power-level is stored.
• Example: powerLevels[powerType.ordinal()] = powerLevel;
• Use mixin to redirect all redstone calls to channel through this system. If done correctly, only redstone (and torches it seems) need an actual custom system. Things like repeaters and such will just read the highest power level (you can extend this system to make different color powerstone components later on). Try to avoid actually changing anything else.

Because it's stored as Nbt data, you save 99% of the RAM and only have to worry about a couple block entities and renderers, not thousands of block states (you'd be effectively optimising the whole system anyways...).

For such a system, you'd need to put this kind of rewrite in a separate library that people can PR into. Otherwise PowerStones would just be a ridiculously intrusive mod.

(If you are interested and would like a bit of help there, I'm here).

Aside from that, good job thus far. Most others have not actually even implemented a working system of alternate red stone to begin with.

[StockiesLad]

Also, just reading a bit. This is not good practice. Make an abstract function where said block returns the given array of power levels I was talking about. Make helper functions to compile such raw data nicely.

default byte[] getWeakStonePower(BlockState state, BlockView world, BlockPos pos, Direction direction) { 
    return new byte[] {0, 0, 0, 0}; // You get the idea...
}

This is much more extensible and easier to maintain (if you wanted to add more colours/functionality later on).

[CalvinMT]

Thank you for taking the time to review the code and for outlining a possible direction for improving the mod.

I was already aware that the next major step would involve moving to BlockEntity and BlockEntityRenderer, but I didn’t realise this approach would also have a positive impact on performance. That’s very useful to know.

If I understand correctly, this would require separating the new redstone rendering logic into its own BlockEntity implementation, ideally extracted into a standalone library that this mod depends on. My assumption is that the first step would be to design and implement this new redstone BlockEntity system as a reusable library, and then integrate it back into a future major version of PowerStones.

One question I still have: a year ago, someone on the Fabric Discord suggested that I might need to use a custom baked model to solve the wire-overlap rendering issue. Given this new approach with BlockEntityRenderer, would a custom baked model still be relevant?

Discord - Fabric - Custom baked model discussion:
https://discord.com/channels/507304429255393322/807617488313516032/1319271307405299783

[StockiesLad]

Thank you for taking the time to review the code and for outlining a possible direction for improving the mod.

I was already aware that the next major step would involve moving to BlockEntity and BlockEntityRenderer, but I didn’t realise this approach would also have a positive impact on performance. That’s very useful to know.

If I understand correctly, this would require separating the new redstone rendering logic into its own BlockEntity implementation, ideally extracted into a standalone library that this mod depends on. My assumption is that the first step would be to design and implement this new redstone BlockEntity system as a reusable library, and then integrate it back into a future major version of PowerStones.

One question I still have: a year ago, someone on the Fabric Discord suggested that I might need to use a custom baked model to solve the wire-overlap rendering issue. Given this new approach with BlockEntityRenderer, would a custom baked model still be relevant?

Discord - Fabric - Custom baked model discussion: https://discord.com/channels/507304429255393322/807617488313516032/1319271307405299783

My pleasure!

As for block entities, it optimises the performance of logic and RAM (as it avoids blockstates). However, block entity rendering, while powerful, can be subject to rendering slowdowns, particularly due to individual render calls for each block entity. This is something that Flywheel (from Create) optimises.

Looking at the Discord chat you provided, MattiDragon is probably right. The aforementioned issue is avoided as, like he said, the model stays inside terrain rendering (which is significantly faster). You can visualise it simply by imagining the lag from 1000 chests vs 1000 cubic blocks (like dirt or stone) and observing how much faster the cubic blocks are.

As for your options, the choice is up to you.

• If you go with a BE renderer, you will almost certainly have to add support for flywheel (which adds another dependency) to maintain speed. This forces you to program things a little differently. But, the overall code would be far simply and easier to maintain.
• If you choose a model injection, this would be conceptually (not programmatically) easier. This unfortunately has limitations; specifically regarding model updates. It's quite hard (and infuriating) to work out. I had a similar problem when I was writing dynamic models for a charring block. And technically, you'd still be effectively parsing thousands of redundant models.

In summary, each method has it's own pros and cons. I personally opt for the first option as you are way more likely to find support in the create discord, rather than the fabric one (especially for rendering). Regardless of which option you chose, keeping the block data in a block entity itself (even if you avoid the rendering) is still the go-to. This skips the block-state mess, which is the main culprit for memory usage.