Element count

[Scooby]

Hi, i wonder if someone could clarify a few things for me, over the years i seem to have built up a lot of resources on the server... almost 100 and ive noticed over this time that it takes longer to connect, especially if u reconnect. im not talking about the actual download time but once the downloads have completed, sometimes you can be sat there with a black screen for 5 - 10 - 20 seconds waiting for everything to start up.

ive been working on some of the scripts i first made to make them more efficient,

im using the normal SA map with around 2000 vehicles (ive removed 3000), also, 1600 elements for properties (icon + marker), rpg/races/gangwars/casino etc.. (a lot is serverside but whatever cant be created serverside is clientside)

so what i want to know is: does this sound excessive? i know the element limits etc but what is a reasonable amount to use? or is what im talking about not affected by the element count?

basically i dont want to just keep adding more and more scripts with elements if thats whats causing slow connecting.

[AGENT_STEELMEAT]

The actual element limit is 65535 (I think). I personally love to make use of the element system - however, you do need to know how to ensure you don't lag down the client. I would suggest looking through some of your scripts for ways to increase efficiency.

One trick that some people don't know about are using the last two arguments of getElementsByType(). One example is if you have 6000 housing pickups (that use colshapes and objects, not actual 'pickups'), and you want to iterate through all of them on every render to animate them. Many people might do:

  
for _, pickup in ipairs(getElementsByType("housingPickup")) do 
     if isElementStreamedIn(pickup) then 
          --stuff 
     end 
end 
  

Rather than call isElementStreamedIn for all pickups, a better way is to have a single housingPickupRoot element, and use that as the parent element for all pickups. Then, you can do:

  
for _, pickup in ipairs(getElementsByType("housingPickup", housingPickupRoot, true)) do 
     --stuff 
end 
  

This way, only elements that are children of the housingPickupRoot element and are streamed in are iterated through. I have tested this personally and found a noticeable difference.

Hope this helps.

[Scooby]

Thanks for the quick response and detailed reply, im still none the wiser tho lol.

with my property system, i use markers, i have around 850 around the map, with a property icon in the marker (which im planning on removing to cut down on the 850 icons )

i agree cycling thu them isnt easy and im sure there are ways i can improve efficiency in a lot of my scripts.

what i want to know is, will it make much difference if i have 800 markers to having 1800 markers, will it increase the lag we're experiencing when joining the server.

what is a safe limit of elements to use? yes i know its possible to use 65535, but whats a good workable amount?

or am i ok to use 65535 without even noticing any difference?

[AGENT_STEELMEAT]

The bigger your server, the more resources you'll need, quite simply. I remember when I used to work on FTA we had a serverside element count of 3000, and a clientside element count of 7000 (we had a big housing system). There was some lag when we used to make the pickups dance by default, but since then an option was added to have them sit still. The reasonable limit is whatever your server can handle - optimization is key.

[Scooby]

ah ok thanks... i might add a few more eventually then

we didnt like the spinning mta pickups as much as the ones we were used to in VC (when a player dies and drops their weps), so we wrote a resource to drop them in a circle around the player, theyre destroyed after 30 seconds and this way and players can drop and pickup ones they want or dont want.

im just trying to cut down on the lag spikes we're getting, one being searching thru all the properties to find the ones which u own when u join the server... a lot of things have had to be removed because of the lag spikes its causing searching thru elements etc.

we've even halved the slots from 128 down to 64 (which everyone now complains about because the server is full most of the time)

well thanks a lot for the info, i keep at it i guess