1. Guest, as per the stickied thread, this forum has not been in use since 2014. All bugs and feature requests should be posted to JIRA.

Feature Prevent signs/entites from being sent to client with configurable view distance?

Discussion in 'Bugs & Feature Requests' started by Sway, Jun 5, 2013.

  1. Sway

    Artist Supporter

    So i was thinking today, with all the signs i have on my spawn for first timers; What if it was possible to remove the client lag cause by signs? md_5 implemented a view distance per world, so i assume it may be possible to prevent signs and certain other blocks from being sent to the client with a configurable view distance.

    How would it work?
    When a player is x amount of blocks away from signs or another block, they will not see them until they are within the defined range set in the configuration/bukkit.yml so signs and items frames or other blocks will no longer cause fps lag for players with bad hardware.

    Of coarse if this were possible, there would be many other things that can be added to prevent certain blocks and or entities from being sent to the client.

    I have no idea if this would be possible, and if it would have an impact on the servers performance, but if you can manage to get this working i myself and I'm sure many others would love it..
     
    #1 Sway, Jun 5, 2013
    Last edited: Jun 5, 2013
    • Agree Agree x 2
    • Like Like x 1
  2. that would be nice, it would also help with the amount of signs in towny shops when towns situate their shops right next to each other...
     
  3. Doable but...

    Data about the world (and the view-range setting) is sent to you in chunks; 16x16x256 blocks. View-range indicates the radius of chunks around the player that they get sent. Now, when chunks are sent, they're sent in a packed format - and to unpack it requires a gzip pass, and then you have to search through a 4096 array for anything that is a sign. Times 16. For one chunk.

    So, doable, but it'll eat up stupid amounts of resources doing it; on top of that, the proxy will then have to keep it's own set of data as to "what can the player see" - which will add to memory consumption. Then you get the point that it will have to store the signs in memory, so it can send them later; and then you'd have to send a block update for each sign.

    Ehh... nice idea but... :p
     
  4. Spout can do this, go get spout.​
    iirc, optifine can do this too.
     
    • Disagree Disagree x 2
  5. Sway

    Artist Supporter

    Pfft spout.
     
    #5 Sway, Jun 5, 2013
    Last edited: Jun 6, 2013
    • Agree Agree x 2
  6. md_5

    Administrator Developer

    This is what entity tracking range is?
    (aside from signs, which we could add later)
     
    • Agree Agree x 1

  7. You're right, and again I stuck my foot in my mouth by badpoasting at 4am; I was under the impression it was a feature request for BungeeCord (oh, hello there footer Forums > Spigot .... derp).

    I'm going to sleep now.

    *hangs head in shame*
     
  8. Sway

    Artist Supporter

    So this is possible? =D
     
  9. md_5

    Administrator Developer

    Its already done for entities.
     
    • Like Like x 1
  10. Tile Entity Sending limit would be a nice feature, but would have to be done on a chunk radius and not block radius.

    I have some ideas for implementing this but will need to wait till im done with some featurework on my server.

    But reducing Tile Entities to 1 chunk radius def would improve client side lag.

    If the client behaves correctly, it may be something that can even be hard coded (you need to ensure a tile entity interactable by player has been sent) and then get immediate benefits w/o worry of figuring out config updates

    It would also improve performance a little bit and reduce bandwidth by not sending tile entity packets.

    my only concern would be be jukeboxes where you can hear the sounds farther away, but can make exclusions.
     
    #10 Aikar, Jun 6, 2013
    Last edited: Jun 6, 2013
    • Like Like x 1
  11. Sway

    Artist Supporter

    That is something i was thinking about before i posted this, So i guess it would benefit both players and the servers performance if done correctly.
     
  12. joehot200

    Supporter

    Agreed, not knowing about this thread i was planning to post the same suggestion today.
     
    • Funny Funny x 1
  13. You'd have to make exceptions for everything redstone though, otherwise it'd look mighty weird...
     

  14. Why? How often do you think people study Redstone operation from more than 32 blocks away?
     

  15. You said 1 chunk radius so figured you meant 16 blocks, at that point you'd need exceptions for redstone - 32 blocks not so much.
     
  16. joehot200

    Supporter

    I would want to set this to lower values than 32 because my spawn has quite a few signs in it - hence causing some lag.
    Also why cant it just be for signs, instead of other stuff?

    Or we could always leave the members wondering "How the hell does that work with no redstone" :D.
     
  17. Youd still see the block...

    tile entities are essentially metadata stores that says "this special block is configured with these settings"
     
    • Informative Informative x 1
  18. joehot200

    Supporter

    Aha. This means that it would not show lit redstone, but that it WOULD show lit glowstone lamps, as lit glowstone lamps are another item/id, wheras lit redstone isnt?
     
  19. it would really all be figured out when its actually implemented... it might not work at all, client could go wonky.

    as for the 1 chunk radius, that would include the chunk your in still, so 3x3, so 32 max, but 17 min~
     
    • Informative Informative x 1