tabarra
feat(menu): players blips
Feature: Menu option to disply players blips on map, coords fetched server side, so all players will be displayed no matter if onesync is on or off.
This would be really great if this came in TxAdmin. Is there any way I can test it?
@daZepelin Thanks for the PR, and for the effort making it really close to our usual design specs.
But i'm not super sure how i feel about this.
As a feature, it's cool, but the practicality and UX/UI don't feel super refined.
One of our main concerns for most menu features is "how would that work if the server has over a thousand players online?", which is a real scenario for many txadmin servers.
I'm worried about the server-side performance impact on the 2 seconds loop. Can you measure that and show us what it would looks like for 500 and 1000 players?
On sv_playerlist.lua we don't even get the player coords, and we still doing dynamic delay to make sure we won't lag big servers.
And for that playerlist (menu playerlist), we even gave up on doing coords on the server because of how much event data would be transferred, coords are super big and take many bytes to be sent through the events. Now consider 5 admins with the player blips on, on 1000 players, how many mbps would that be uploaded?
Also for 1000 players, what would the game map look like? is it visualizable? laggy?
Maybe showing all individuals be too hard, maybe aggregate them into grids? maybe show a single one if you click on him in the menu playerlist?
Thanks indeed for our concenrns and insights on this. I did some testing on this and it's performance as if there was 2000 players online and that's my conclusion
I did not really concern the network load on this, but 2000 players data would be around 80-90 kilobytes for one refresh to be sent to client if the values are sent as integer and nearly twice as much in float, but I think ints can do just fine. Sending data to client only for players who have their coordinates changed significantly would do even better, but that would cost server hardware load.
Talking of server load, I did not notice any noticable impact on it at all, as per resmon on server side, but always smaller yield per tick could used, that would obviously end up with higher timeout between refreshes, but that should be expected on servers with higher load.
Client performance with 2000 players did indeed get some impact as that dropped around 10 fps with over 2000 blips on the map. But I had a concept in my head for reworking the blips already and bundle players to a single blip if there are more than one of them within a specific radius. As what I and my team experienced in our server already, is that it's quite difficult to understand the spread of players around the map if the blips get on top of each other.
To be hornest I am pretty happy with this idea as staff from a few servers found it really useful, so I would be happy to work on it and improve it for it to be implemented in txadmin, hoping more servers would find use in it, but only if you @tabarra think it is worth a try and work.
Thanks for the tests.
Right now my workload is more focused on backend core changes to prepare for a frontend migration and multiserver.
As you can see in the open PR list, our menu stuff is kinda frozen since right now if there is any bug in the client side code it would be really really hard for us to even know it since it doesn't print on the console anymore.
Before merging anything menu-related, we need to remove a few prints and convince Cfx to start printing txAdmin errors again, so a reasonable ETA for merging this PR would be 1~2 months, is that ok?
How about using this native to group/ungroup blips depending on player count in a specific grid area + zoom level?
https://docs.fivem.net/natives/?_0x1363A998
The bigger issue here would surely be the hard coded blip limit?
With there being a hard coded limit on the amount of blips, if a server already has a decent amount of blips (for example, vMenu alone adds a huge amount of blips), hitting that limit would be a quite a big concern at high player counts?
Due to the complexity of this PR related to the usability of this feature with 1k+ players on the server, I decided to close it.
Thank you very much for the PR though, really appreciate - even though I couldn't prioritize trying to solve the potential issues.
For anyone in need of this, I think there are other alternative resources to do that in game or outside.