1.15.2 How to add a second line to a player's tag

Discussion in 'Spigot Plugin Development' started by Xocky, Feb 17, 2020.

  1. How do you add a second line to a player's exisiting name tag
     
  2. SteelPhoenix

    Moderator

    You don't. You spawn an invisible named entity on the player so it looks like a 2nd line.
     
  3. It’s actually kinda complicated. I’ve tried doing it but didn’t achieve it. Basically you spawn a named entity as mentioned and set it as player’s passenger. Then you need to listen to some event for example sneak event to hide the named entity too. Also, there’s a bug (maybe it’s not but still) and if the player wanna go through a portal with a named entity as a passenger he cannot.
     
  4. What about using teams and SidebarSlot.BELOW_NAME
     
  5. We use this method and it works wonders once you perfect it. There's some difficulties here and there, but it's doable.
     
  6. can confirm, when perfected it is wonderful. Make sure to run this on a packet level though, the resource expenditure can quickly reach a ludicrous level otherwise.

    [​IMG]
     
  7. Care to elaborate more on this? We're currently not doing anything with this on packet level, other than something forcefully refreshing the entity to prevent it from being invisible to the client. This is a bug we had for a long time, and after numerous changes to this system, we finally fixed it, and I think just refreshing the entity like that solved it. Other than that, no packet work. We didn't face any lag. We did eventually, when updating to 1.15, disable the ticking of the entity we use for these names (an enderpearl in our case), which did help things slightly, but not anything close to major.

    Perhaps we are implementing things slightly differently, whereas you may have faced a problem which I have not faced. Or maybe I just haven't noticed it yet.
     
  8. There are things besides the ticking that generate an overhead, for example when you wish to target entities in a certain range. The getNearbyEntities will also fetch you the "hologram" entities. Events will be fired, you would need to cancel the hologram entities from taking damage. You generate a considerable memory overhead too, owing that a real entity will keep track of unnecessary things unlike a packet wrapper.

    And its important to remember that you wont just have a few dozen entities on a large server. Its one thing if you are exclusively working on players, a hundred players are nothing much, but when each player is scattered around the world and generates something like 20-30 mobs in their view distance you quicky wind up with a huge number of entities. Additionally to that, unless I remember wrong, I think that entities are converted to packets on the main thread which adds additional expenditure. Compared to what you use these things for (namely displaying a line of text), its a huge expenditure of performance.

    Compared to the above, the only performance expenditure that you would have when working on a packet level is that you need two hooks for entity spawning and despawning. Everything else can be processed asynchronously by communicating with a number of concurrent mappings.
     
  9. I see. I think I'll keep it for the time being and monitor how much of an impact they still give us. Like I said, we ( @MiniDigger ) have disabled most of the ticking logic for the enderpearl.
     
  10. MiniDigger

    Supporter

    I had thousands of enderpearls on a test server without any issues.
    doing this on a packet level is way more complicated since you need to consider ppl joining after you "spawned" the pearls (and it gets even more complicated for us because of our phasing/instancing system).
    the memory overhead is small compared to the cpu cycles we would spend on spawning the entities every time.
    since we use (a custom fork of) paper, packet flushing is async, so thats not an issue either.
    targeting and other events arent really an issue because of how I disabled the entity ticking, however this is not something you can do without modifying the server.

    and well, we are on 1.15. I would be surprised if we can hold 100 players on an instance, with out without enderpearls.
     
  11. have some faith ;)

    otherwise, take more performance precautions :ROFLMAO:
     
  12. What do you consider as "without any issues"? I mean. Alright. Lets say you have 1000 ender pearls on the server. Actually, lets say you have 10000 ender pearls on your server. Its running fine. You got a perfect 20 TPS. You have no lag spikes. Stuff works fine. Sounds safe right? But you are forgetting something, anything beneath 50ms of per tick computing will be "fine".

    So if you would for example apply 15ms of a ticks computing time for a number of ender pearls, you would still be stuck with 15ms of computing time for a number of ender pearls even if everything else is pushing your server to a 45ms computing time. You need to test things with several thousand chunks in memory, with players actually interacting with things and whatsover.

    And my solution is not more complicated at all. You can hook into the entity spawn and entity destruct packets, which are sent per player. It does not matter when a player joins, they will be notified about the entity nontheless. I dont think you notify players about entities spawning on unrelated phases/instances right?

    But the main advantage is still that you completely decouple things from the main thread except for two packet listeners that can communicate with another thread by utilizing a concurrent mapping/collection of your choice.

    Point taken about 1.15 though. Still upset that they changed to a stream based approach within the AI processing.
     
  13. MiniDigger

    Supporter

    fine as it it didnt show up in profiling, at all.
     
  14. interesting, i will look into this myself too.