What does it do exactly?
This script allows members of certain whitelisted jobs to use a GPS tracker that allows them to be
tracked by other job members across the map in realtime.
Showcase:
Requirements
|
|
| Code is accessible |
~90% accessible |
| Subscription-based |
No |
| Lines (approximately) |
420 |
| Requirements |
See requirements above |
| Support |
Yes |
Where can I get this?
This script is currently purchasable for 7.50€ (without tax) at:
https://kiminazes-script-gems.tebex.io/package/5436539
Features
- ESX and QB support.
- Tracker can be toggled by using an item.
- Tracker will be disabled when removing the item.
- Configurable option that only shows the other members when your tracker is also active.
- Shows the actual characters name in the legend on the map.
Performance
- Client Side: idle 0.00ms, in use (depends on the amount of blips)
- Server Side: idle 0.00ms, in use (depends on the amount of blips)
Detailed performance breakdown
| type |
num players |
performance (ms) |
| Players in scope |
50 |
0.17 |
|
25 |
0.10 |
|
10 |
0.06 |
| Players outside of scope |
50 |
0.15 |
|
25 |
0.09 |
|
10 |
0.05 |
| Players in and outside scope |
10&10 |
0.09 |
Patchnotes
Can be found on Github
2 Likes
Hey, very nice Script. Is it also possible, that a Tracker will be deactivated when the Tracker is removed from Inventory??
1 Like
Yes, when the item is removed from inventory, and there are no more trackers in the inventory, it will automatically be disabled 
1 Like
Is this script resmon tested with more than 30 - 60 players? if, for example, 10 of them are police officers who have activated the tracker? if so, how is the performance?
Tested, yes. But you are right, I did not check for the resmon during those tests. (resmon was tested with low player count but all of them using their tracker)
Didn’t really have the time yet (Merry Christmas 
), but I’ll make sure to get you proper numbers tomorrow (if not, then the day after).
I have done some more specific testing with exact numbers for you
But first of all an explanation:
I did different tests for the different cases. All mentioned players had their tracker on at the same time.
- The first three tests go only over players that are in scope (loaded and updated client side) and call a few more natives.
- The next three tests go only over players that are out of scope (out of range of the player and updated via lerping the position over the syncInterval (defaults to 2.5sec)) and call less natives.
- The last test combines both and goes over 10 players in and 10 players out of scope.
| type |
num players |
performance (ms) |
| Players in scope |
50 |
0.17 |
|
25 |
0.10 |
|
10 |
0.06 |
| Players outside of scope |
50 |
0.15 |
|
25 |
0.09 |
|
10 |
0.05 |
| Players in and outside scope |
10&10 |
0.09 |
While doing these tests I also ran the profiler on server side and found that the script is taking more performance than in my initial tests (though it’s still perfectly fine for server side). I already started optimizing in this regard and will push an update soon
Mostly because of calling too many ESX/QB functions. I am caching those results now and it already looks way better.
1 Like
