Excessive cable network size issues
sfPlayer1 opened this issue ยท 3 comments
Version:
- Minecraft: 1.16.4
- Forge: 35.1.1
- Powah: 2.3.3
Issue description:
powah:energy_cable adds a huge amount of data for each individual tile entity to the ChunkData network packet, blowing well past the 2 MiB uncompressed packet size limit (>3 MB in this case).
There are several problems:
- The client likely doesn't need all this data, if any. Forge allows to differentiate between data to save and data to sync through the appropriate TileEntity method overrides
- The data itself looks unusually bulky, indicating that it may accumulate stale nodes or just be constructed very inefficiently
- The cable network is persisted, which is generally fragile and should be reserved for special uses such as support for huge grids that can keep operating normally while partially chunk-unloaded
- Every CableTile appears to keep the network info instead of some global/per-world network notation that is being referenced indirectly. I'd at most expect a record of the few directly connected things if that can't be inferred otherwise.
This likely also causes excess memory and cpu overhead. According to the player who placed the cables the setup shouldn't be extremely large, but significantly extensive as one may expect to wire a moderate base up. I unfortunately don't know any details there.
See https://files.player.to/tmp/powah-decoded.zip for the decoded NBT of the most problematic chunk data packet
That's normal because you're using lots of forge energy blocks attached to cables, also the pos list are not syncable because I use it only on the server
also the pos list are not syncable
I'm not quite sure what you're saying there, but the lists definitely are being synced. There's one very practical piece of evidence for that (the cables prevented people from logging into FC because the sync packet was too big), it's also quite easy to see in code:
SChunkDataPacket
calls TileEntity#getUpdateTag
(no link, but you can easily check in your dev environment)
AbstractTileEntity#getUpdateTag
calls AbstractTileEntity#write
AbstractTileEntity#write
calls CableTile#writeSync
which writes the pos lists.
I agree with Player, this system of storing the connections is broken (or at least problematic) in general. Especially points 3 and 4 are important IMO.
Oh my mistake I thought I fixed it before , also I found that I used getUpdateTag
instead of writeSync
in AbstractTileEntity#getUpdatePacket, I will fix it!