Powah!

Powah!

19M Downloads

Excessive cable network size issues

sfPlayer1 opened this issue ยท 3 comments

commented

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:

  1. 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
  2. The data itself looks unusually bulky, indicating that it may accumulate stale nodes or just be constructed very inefficiently
  3. 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
  4. 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

commented

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

commented

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.

commented

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!