My light torque shaft is visually spinning at full speed when it should be stopped. It IS stopped (as in it's not consuming/transmitting power) while it's visually spinning that fast. When it DOES transmit power (like when I spawn an extra cow in), the animations of the generator and the shaft match up perfectly. It's just the idle state that seems to be rendering wrong lately. I can't be sure when I first noticed it, sorry. It might have been as early as 2.2.70 or 71 :s Of course, had I mentioned it at the time, I could be certain but I didn't. It's only now that I've broken and re-placed the shafts and generator that I realise the issue's persisting. actually.. it must've been after the issue of resetting the mob count to zero was introduced and before it was fixed. I hope that's enough info for you to find it quickly.

Gratuitous screenshot to show torque conduit power values and a skeleton riding a cow

I have seen similar issues myself, but it seems to happen to me when I leave an area and return to it -- the client-side rotation data is never updated properly when retuning into render range. For me if I force an energy-state change (e.g. start up the generator to add power) they will immediately begin synching correctly again. This all leads me to believe vanilla (or forge..) is doing some weird caching of tile-entities on the client.

Have a few ideas on how to fix it properly, and at least one known semi-hacky solution (periodically send energy-state regardless of if a change was detected or not).

Hopefully I'll be able to get this one cleaned up soon.

This is what I've noticed, yeah. Apologies again for not catching it before you'd moved on to vehicular and structural goodness. It's only minor and only visual but gee those animations look great when they're synched up.

I have traced this back to a vanilla issue -- it only respects send/receive of block-events within 16 blocks of a player. So, you move >16 blocks away, and the tile stops receiving updates (even though the server is sending them!).

It looks like the only appropriate solution would be custom network handling, sending to all players tracking the tile's chunk. I'll look into doing some batching of these network updates to try and reduce overall network use; could probably be an overall net-gain in network efficiency if I can pull it off appropriately.

Will update this issue shortly when I figure out more precisely how I am going to fix it.

Testing a potential solution of sending custom network packets (no batching). This may have a negative effect on network performance, as I'm fairly certain my custom packets have higher overhead than vanilla block-event packets... will do some profiling to see if I can note a difference.

Will continue investigating packet grouping/batching. It is likely that I can zip/compress all packets going to a single player, and decompress them on the other side/unzip back to indiv. packets. Hopefully I can do this on an abstract/low level, and have it effect my entire network/packet system, for improvements in -all- areas.

It would effect all tile-entities that use vanilla blockEvents -- this is a separate channel than the normal 'description packet', and is meant for more frequent updates of small bits of data. And apparently vanilla never meant it to be critical data, as you cannot rely on the client-tile receiving it.

So yes, it would effect all tile entities that use the block-events system. However, not many do. Most just resend the entire description packet when data is needed.

Chunk loaders -- these are only effective on the server, and they -do- work to keep the chunk loaded. The tile will properly stay loaded on the server (and do its update ticks), and send its initial description packet to any client that comes within tracking range. However they will not make sure that a client receives blockEvent data when they are out of range for it.

Having looked a bit closer at the vanilla stuff, my solution should be pretty darn close to the same from a network efficiency standpoint -- my custom solution maybe writes an extra 32 bits (4 bytes) per packet compared to the vanilla solution... which is just a packetID header -- and I can likely trim this down to 8 or 16 bits...I don't think I'll need more than a full byte for packet ID (would mean I had more than 127 packets...which is crazy).

I couldn't really find any easy room for improve via batching; it would require a full additional network abstraction layer to group/partition/zip up any packets. Will investigate more fully in the future as this could have substantial network bandwidth savings (at the cost of CPU time to encode and decode the zip stream).

Wait, what? "..it only respects send/receive of block-events within 16 blocks of a player. So, you move >16 blocks away, and the tile stops receiving updates (even though the server is sending them!)."
That can't be affecting all tile entities, can it? That's nuts. So.. chunk loaders would have no effect then?

Interesting - and sounds great for now, with the improved batching tucked away as a possible future enhancement if you feel the need and have the time.
Thank you

Hopefully I'll have an updated release later this evening that should have the fix in it. Is fixed in dev, just need to build/package/upload/etc. Should have time after work.