Issue description: Placed screens are unbreakable. Upon trying to break them (or do anything else near them) a lot of upload traffic is generated to the dedicated server

Steps to reproduce:
-place any block in the world
-place a screen on the block (screen controller is not required for the bug)
-attempt to break the screen

Versions:

• Minecraft: 1.12.2
• Forge: 2768
• CompatLayer (only if on Minecraft 1.10 or 1.11): N/A
• McJtyLib: 1.12-3.0.6
• RFTools: 1.12-7.56

Possibly incompatible mods and versions: Unknown, nothing is logged for me to begin to trace

Relevant logs, if any: See above

For a neatly formatted list of mods in use: https://minecraft.curseforge.com/projects/continuity/relations/dependencies . Most mods are on the newest version, or a version from last week. I don't know of a good way to list versions, sorry.

Any updates on this?

screenRefreshTiming was added in 7.58. Does it improve matters?

screenRefreshTiming was added in 7.58. Does it improve matters?

That's what I get for coming here first expecting there to have been a post about it. Unfortunately it does not solve the issue. I set it to 1000 (ms I presume) on both the server and client and get exactly the same amount of upstream data from an empty sign (~4.5 KB/sec). I guess this at least proves that it's not the sign updates causing the issue.

Besides the sign update there is really nothing else from rftools side that is going on so I have no clue what else it can be

AH-HA! I found something! If I insert a random module into the unpowered screen, the excessive network usage vanishes. Remove the module, usage is immediately back again.

So:
Screen with nothing in it, unpowered: issue
Screen with something in it (to blank it), unpowered: no issue
Screen powered with nothing in it: issue
Screen powered, any module (even a blank text module): issue

I was able to confirm this. RedShark just logs this message, repeating over and over:
Recieved a packet from rftools. It has 65 bytes of data. Type is class mcjty.lib.network.PacketServerCommandTyped.

Adding a bit of debug code to McJtyLib, the problem message's contents are basically all just screen.hover(x=-1, y=-1, module=-1).

So looking at the code, the problem is that every time the client renders a screen module, it sends the server a packet saying "nope, the cursor still isn't on top of me".

It looks like the only thing the hovering info is even used for is WAILA/TOP support for screen modules. And looking closer, that code isn't even correct. In particular, bad things will happen if two players are looking at the same screen at once.

Interesting. I do use TOP, but I don't see what the data would be useful for. The screen displays data from the modules, so it would be fairly obvious what modules are in the screen.

If you hover over an item displayed by the storage control screen module, TOP tells you the item's name.
Anyway, I'm working on a fix now.

Ah, that makes sense. I typically use AE for storage so I don't use storage interaction modules.

Fixes are good :D

The bulk of the traffic will be fixed next release. I opened #1877 about things I can do to optimize it even further (and handle the case of two players looking at a screen).

Sorry for the long delay in replying, I've been focusing on finding a job (job hunting SUCKS).

Anyway, I would like to say that I can confirm this fixed on my end, thank you for doing what you do, and keep doing great things :)

Well screens do have to send out a lot of info (depending on what's on them as well) so it is normal that they cause some client-server communcations

Well screens do have to send out a lot of info (depending on what's on them as well) so it is normal that they cause some client-server communcations

I can understand this, but why would they need to send so much from the client back to the server? The server should be handling all the processing and merely sending updates back out to the screen at whatever frequency it's updated. It almost seems like the data is making a round trip unnecessarily or something.

They need to send back the point on the screen that the client is looking at so that the server can send back the information for that specific spot on the screen

Perhaps the polling interval is too high. Sending back "I see this screen, send me the data to render" 20 times a second shouldn't take much. If the screen is trying to selectively update only certain parts, it would be much better to send all the data anyway. By the time you get through all the overhead of sending the requests, you're generating a lot more network traffic than just updating the whole screen. I've estimated that I can have at most 3-4 screens before an area becomes unplayable.

Problem is that the server needs to know what point of the screen the player is looking at to be able to do position specific calculations (like where the user pressed). Also is there actualy a problem here because RFTools screens are used a lot and I doubt this network traffic is really causing issues

Maybe it would be possible to only have that done while that specific screen is being accessed. As it is if the screen is even in view at all this happens, even if it's not being interacted with.

And yes, there is a problem. Not everyone has fancy ultra high speed cable or fiber internet. I, like a good percentage of Americans, am stuck with slow internet. 3Mbps down, 0.75Mbps up. I don't have the option to get faster internet either.

Well it should be only when the screen is in view already. Problem is that I need to do it for viewing too as some modules require that

So there's nothing that can be done to lower the network usage then? In that case, could an option be put in to disable screens? I'd like to not have to remove rftools but it's looking like that may be the only solution.

Hold on. Investigating

Are you in survival or creative? If the latter, are you sneaking while attempting to break it?

Also, does this bug happen to you in an instance with just McJtyLib and RFTools installed? It seems to work for me like that. If not, please figure out which other mod is breaking it.

Are you in survival or creative? If the latter, are you sneaking while attempting to break it?

Creative mode. I'll give that a test on a sacrificial singleplayer world. Regardless, even if I don't try to break them, attempting to place/break/edit/etc... blocks in the same chunk (vanilla signs for instance) triggers the same bout of a ton of network traffic rendering the world unplayable for a few moments until it settles down. The same chunk, from a backup, has no problems with vanilla signs when I don't place RFTools signs down.

As for an instance with just this mod (and it's related dependencies) I would hazard a guess that it does not occur. Unfortunately I have no leads to go on as for what is going on as there is absolutely nothing logged on either the server or the client to go on. Trial and error would take forever on a pack this large, so that's out of the question (it took me a while 15 hour day to troubleshoot a broken mod on a pack much smaller than this). I'll try debugging logging and see if that comes up with anything.

It is intentional that screens cannot break in creative (otherwise you cannot use them or interact with them). To remove a screen use sneak right click with a smart wrench. Not sure about the network traffic though

Trial and error would take forever on a pack this large

Why? Just do a binary search. Even a pack with 500 mods would only take 9 tries to get through.

It is intentional that screens cannot break in creative (otherwise you cannot use them or interact with them). To remove a screen use sneak right click with a smart wrench. Not sure about the network traffic though

That makes sense. I did enable debug logging, it didn't seem to come up with anything unfortunately. There is one mod that seems to have the ability to log packets, but it seems to be suffering from the forge 2768 bug that broke stuff.

Trial and error would take forever on a pack this large

Why? Just do a binary search. Even a pack with 500 mods would only take 9 tries to get through.

I'm not entirely sure what you mean. Are you referring to removing clumps of mods or some such?

What limited information I've been able to gather:
-Each screen uses ~10-13KB/sec of upload (client to server) (seems to vary by screen size) [these are signs with NO MODULES INSTALLED]
-This adds up with each screen added to the area
-This only happens when a screen is actively being looked at (I can be in the same block with my back to the screen and the problem goes away)

If/when RedShark gets fixed I can try to get more data on the issue (pun intended)
I'm also going to have to say that it's unlikely (but not impossible) that it's another mod

I'm not entirely sure what you mean. Are you referring to removing clumps of mods or some such?

Yes. Remove half of the mods and test it. If it works now, you know the problem must be in the half you removed. If not, you know the problem must be in the half that's still there.

I'm also going to have to say that it's unlikely (but not impossible) that it's another mod

That's easy to test. Just create a new instance with nothing else and try it.

I'm not entirely sure what you mean. Are you referring to removing clumps of mods or some such?

Yes. Remove half of the mods and test it. If it works now, you know the problem must be in the half you removed. If not, you know the problem must be in the half that's still there.

I'm also going to have to say that it's unlikely (but not impossible) that it's another mod

That's easy to test. Just create a new instance with nothing else and try it.

Well that didn't take much, with the above mentioned versions of forge, rftools, and mcjtylib the problem still occurs, albeit at about half the rate (~4-5KB/sec per sign). I left the configs stock after the mod generated them. I would guess that with more mods that the screen (and screen modules) can interact with, the issue gets worse (this is just my theory on why the issue is exacerbated in my large pack).

One option that I have would be to reduce the time at which the screens requests information through the config? This is now set to 500ms (so two times per second). If I can make this configurable you can set that to anything you want. Would that help for you?

2.5 KB for an empty screen is too much. That doesn't sound possible as an empty screen has almost no data. How do you know it is caused by RFTools? Can't it also be caused by some other mod collecting info about the object you're looking at?

I tested it on a world with only this mod installed and it had the issue (I mentioned this above but it got buried).

And how are you measuring that exactly? Can you see the names of the packets that are this size?

Unfortunately I don't have any packet tracing, but by testing placing signs in a test server with only this mod I noticed it jump up by 4-5KB/sec of upload per sign placed. I was looking at network utilization by process and connection in netlimiter, so I was only looking at the bandwidth of that minecraft instance to the server. I wish I had more detailed packet logging of packet sizes and what precisely is going on but I don't.

Will be hard to diagnose then. The packet that I'm using myself to send screen data is tiny for an empty screen (just a few bytes). So I have no explanation where that other data is coming from really

I always say more options are better, so it wouldn't hurt. That has me curious though, what all data is sent back to the server during the update that would amount to 2.5 KB (or 5 KB in a large pack) per update per screen visible, with nothing in the screen? Be as technical as you want here, I'm trying to wrap my head around what it's doing.

OK, I have some further information from wireshark. It seems that when signs are placed, a barrage of 130 byte packets get sent back to the server, each having a 76 byte payload (that changes with each packet). The 54 byte packets are general background noise and the actual throughput of them over time adds up to a mere 72 bytes a second (effectively nothing). The 82 length packets are also always present. I have selected one of the problem packets. For reference, this is a 1 block screen that's empty. Timestamps are HH:MM:SS:MS