Strainers cause a lot of network congestion

[quat1024]

Strainers, if they are waterlogged and ready to work, always call markDirty from tick:

https://github.com/LordDeatHunter/FabricaeExNihilo/blob/f5e00509d2596418587383908920f9b20ddd4c4d/src/main/java/wraith/fabricaeexnihilo/modules/strainer/StrainerBlockEntity.java#L94

BaseBlockEntity always calls markForUpdate from markDirty:

https://github.com/LordDeatHunter/FabricaeExNihilo/blob/f5e00509d2596418587383908920f9b20ddd4c4d/src/main/java/wraith/fabricaeexnihilo/modules/base/BaseBlockEntity.java#L20-L25

And markForUpdate causes a packet to be dispatched to nearby players, so just like that, 20 packets per second per strainer :(

It looks like barrels also sync in both branches of an if/else: https://github.com/LordDeatHunter/FabricaeExNihilo/blob/f5e00509d2596418587383908920f9b20ddd4c4d/src/main/java/wraith/fabricaeexnihilo/modules/barrels/BarrelBlockEntity.java#L189-L193

I understand that markDirty should be called because timers are being ticked down earlier in these tickers, but it should probably not result in a full sync of the entire NBT tag to clients !

I'm writing a packet logger and strainer syncs are one of the most commonly received packets across all received packets at Blanketcon. Fireblanket includes an optimization that prevents a block entity from syncing the same NBT tag twice in a row, but since these tags include the ticking-down timer, that optimization can't kick in :(

[MattiDragon]

Yeah. Overall the sync code just lasily syncs everything (lazy as in lazy dev). It would be pretty easy to only send necessary data and only when it updates.

[MattiDragon]

Fixed in v1.0.0