alt:V is a fantastic GTA:V client that has a lot of Roleplay Servers and unique scripts that adapt to a user's wants and needs. However, if you are one of those people that wants to pursue writing script you may run into some issues.
There's a bit of a trick to using everyTick or setInterval on the client-side. If you use too many you're going to bog down the client's performance. Things such as falling through the map or even the map just outright not loading will occur if you do not give the client some lead room to keep processing the game.
The best thing that you can do is turn off your intervals and everyTicks when they are not being used. I know how bizarre that sounds because you need these tick events to process or show things.
So let's talk about what can be done to help solve performance issues.
Turn Off Unused Intervals and Ticks
It's a very simple pattern that you will eventually end up using one way or another when you are writing code on client-side. However, some people just don't seem to understand how to turn off an interval or an everyTick.
let tickNumericValue = alt.everyTick(someFunction);
let count = 0;
function someFunction() {
count += 1;
if (count > 5000) {
alt.clearEveryTick(tickNumericValue);
tickNumericValue = null;
}
}This little bit of code shows you how to turn off an everyTick after the count is greater than 5000. That means we've accomplished what we need out of it and we'll just turn it off.
Your completion criteria for turning off a tick will always vary.
Make the Server Pre-Process
If you have a lot of people in your server you may want to look at pre-processing the data you feed to your client so they spend less time calculating and more time playing.
There's a simple theoretical pattern that I will be adding into Athena to help process players, coordinates, and other information to be sent to the client.
That pattern basically involves splitting your entire world into a grid. The smaller the grid is the better your performance will likely be. However, too small and it'll be mostly worthless.
Imagine a grid covering the entire GTA:V world. This grid has an indexing system or some form of key to value identifier to help you identify what block of the world the player is in. When the player enters a ColShape in the grid they are assigned that grid identifier value. Let's say it's A1.
Now that the player has entered A1 we can look up all the information we need to relay to the player regarding what is inside of A1.
This can include things like:
- Tree Locations
- Rock Locations
- ATM Locations
- Post Office Boxes
- Gas Station Pumps
- etc
We can define this information for the individual blocks by pre-processing the coordinates during the build process of the code and placing it inside of a shared folder. This will allow players to download all coordinate locations and have them split up into a pre-defined grid format.
This now allows the player to easily grab location data in a much quicker way. You won't have to do any expensive ray casting (unless you want to) and you'll easily be able to propagate world interactions based on small grids.
Drawing HUD Elements
The GTA natives are pretty compelling for writing a basic HUD system for your game mode. However, they use everyTicks and you want to use them sparingly.
It's highly recommended that you implement your very own HUD system by using CEF or a WebView. This should help lower the amount of processing needed to draw text, images, etc.
You can simply use a single everyTick to store the various player data harvested from natives to push into your HUD based on a set amount of time.
