Ohay! Today I wish to share with you some information I’ve found throughout testing today.
First, I wish to say I am working on a system that steps over those limitations, rendering them obsolete.
I wish to talk about: Checkpoints, Textdraws and Blips.
Let’s begin with Checkpoints (All testing is done through C#)
There’s a hardcoded limit of 64 checkpoints at a time (Using the API nativedb wrapper).
You can’t create more than that. So some kind of ‘streaming’ needs to be managed, so we only stream the closest checkpoints. Since we don’t really care about a checkpoint that is more than 200, 300 units away.
So, you need to hold a list of all checkpoints and in every frame load closer checkpoints and unload checkpoints far away. I am using a 200 units draw distance. Meaning only the checkpoints in a 200 units radius of the player are actually shown. Remember that if more than 64 checkpoints exist in that radius, it will not create some of them.
Moving on to draw text
The DrawText API / native function is pretty useful if manipulated correctly. You can simulate a floating 3d text label. My inital goal was to have ‘mission triggers’ like in GTA Online (Checkpoints with text on them). Unfortunately, these DrawText calls are limited to 32 per frame. My fix? Again, streaming.
First of all, let’s specifically handle the 3d text problem. We will stream 3d text label at a certain draw distance (just like chekcpoints). This draw distance can be even twice shorter. Then, we also need to make sure the text is visible, and no object is blocking it. This can be done using the native db ray casting (shape test). Another check would be to check if the textdraw position is on the screen.
Blips
Well, good news is there are not hardcoded limitations. Bad news, too many blips can cause visual bugs in the map. No frame downside - but testing a thousand (1000) blips was okay. Only the big map was visually bugged.