IIYAMA

I don't think that would be an issue. You can always optimise it later if it doesn't work as intended: Use multiple files instead. Or downloading only the ones of the peds in range. You can compile the file, (without obfuscation!), to speed up the downloading and loading time of the file. https://luac.multitheftauto.com/

If you want to know that, then I recommend to take a closer look at the community resources (inspiration). https://community.multitheftauto.com/index.php?p=resources&s=list&name=&descr=inventory&category=

The more entities it finds, the more performance it cost. (!!!especially if you loop over them) 1. A way to improve performance could be done by only get the streamed in players. getElementsByType("player", root, true) For example if you are drawing name-tags on players, you want to draw them only on players close by. By pre narrowing down the segment of players, this will reduce the amount of loops you are going to preform. for key, player in ipairs(getElementsByType("player", root, true)) do 2. And switching to a more basic loop could also help a lot with the performance. for i=1, #table do end 3. If the element type isn't a player, scoping the function to the resource which creates a specific element, could also help with performance. getElementsByType("vehicle", resourceRoot, true)

You can combine the tables first with for example this method table.merge. (make sure to copy the code) And then loop through them. Keep in mind that the table.merge method is mutating the first table. (mutating = changing the content of the table, instead of returning a new one) table1 = {1,2,3} table2 = {4,5,6} ---- local newTable = {} table.merge(newTable, table1, table2) -- or with table names table.merge(newTable, {"table1"}, table1, {"table2"}, table2)

I am not sure why you would invent a new format for your data. You can just use JSON, supported by PHP, JavaScript, Nodejs and even MTA. local vehicles = { {model = 411, slot = 1}, {model = 562, slot = 2}, {model = 562, slot = 3}, } local dataString = toJSON(vehicles) -- text -- https://wiki.multitheftauto.com/wiki/ToJSON -- https://wiki.multitheftauto.com/wiki/FromJSON Normally I wouldn't use JSON for my vehicles, since you want MySQL to take care of that by having a separated vehicle table. Which allows me to fire MySQL queries to find the data, instead of having Lua parsing the JSON data and blocking the MTA thread. But if you are not very familiar with MySQL, JSON is the second best option.

The easing? -- The first 7 of this table are used: local strEasingTypes = { "Linear", "InQuad", "OutQuad", "InOutQuad", "OutInQuad", "InElastic", "OutElastic", "InOutElastic", "OutInElastic", "InBack", "OutBack", "InOutBack", "OutInBack", "InBounce", "OutBounce", "InOutBounce", "OutInBounce", "SineCurve", "CosineCurve" } local images = math.max(math.ceil(7 * ((getTickCount() % 14000) / 14000)), 1) local move = interpolateBetween(3, 0, 0, -06, 0, 0, ((getTickCount() - startTicking) / 5000), strEasingTypes[images])

Not random, but it does it's thing. 14000 / 7 = 2000 ms each image. local images = math.max(math.ceil(7 * ((getTickCount() % 14000) / 14000)), 1) getTickCount() % 14000 This gives you a value between 0 and 13999 in milliseconds. This value counts up, resets and counts up again. (getTickCount() % 14000) / 14000) Value between 0 and 0.999999999. 7 * ((getTickCount() % 14000) / 14000) Value between 0 and 6.9999999 math.ceil(7 * ((getTickCount() % 14000) / 14000)) Value between 0 and 7. (very small chance that the value is 0) math.max(math.ceil(7 * ((getTickCount() % 14000) / 14000)), 1) Value between 1 and 7.

You can make peds immortal like this: Server: -- top of the script local immortalPedsParent = createElement("immortalPedsParent", "immortalPedsParent-" .. getResourceName(getThisResource())) Client: addEventHandler("onClientPedDamage", getElementByID("immortalPedsParent-" .. getResourceName(getThisResource())), function () cancelEvent() end) Server: -- when creating an immortal ped local ped = createPed(skin,x,y,z,rotZ) setElementParent(ped, immortalPedsParent) But keep in mind that other scripts might interfere.

That is correct, it is not the same. setElementData does not modify the parent<>child relationship. It only makes a reference between the 2. setElementParent does modify the parent<>child relationship: And therefore you can use call-propagation. Using the destroyElement function on the parent will also apply the function on it's children.

Feel free to try. Controller, docs included: https://web.archive.org/web/20130728213352/http://crystalmv.net84.net/pages/scripts/npc_hlc.php Sequencer, docs included: https://web.archive.org/web/20130728213506/http://crystalmv.net84.net/pages/scripts/npc_tseq.php

Place the following line setElementParent(fire, wood) between: setPedAnimation (source,"BOMBER","BOM_Plant", -1, false, false, false, false) -- < setTimer(function() When destroyElement(wood) is called, propagation is applied and the same function will be executed for it's children. Which is in this case the fire element.

It can be an issue with very large maps. Loading a map outside of Lua is faster as it eliminates calls between Lua and C/C++. When I created the draw-distance resource, it created some issues when generating lowLOD objects all at once. This is of course clientside, but I guess a server wouldn't like it either. (Not sure if the Lua map implementation uses coroutines, but that would add some complexity for the external scripting implementations)

Most gun sounds exist out of multiple small sounds. Maybe that is the issue?

For example jumping.

Position synchronization is already handled by the server. Better to try something else.

More consistent and at the right timing. Not sure about 'smoother'.

The 100ms function is not the issue. The issue is the synchronization with the server. Which means that the syncer has to keep track of what the ped is actually doing. And only send a message to the server and other players when the ped is doing something else.

That data rate is a bit too high, especially if you are sending the data separately, that is a multiplier after all. All data merged in to 1 packet/message: triggerServerEvent/triggerClientEvent Do not send data double. If you set the ped to sprinting, do not tell the other players that over and over.

Yes A small one, you have to fill in the blanks: --[[...]] Syncer (clientside): triggerServerEvent(--[[...]]) Server: addEvent(--[[...]]) function functionName (ped, action, status) -- get all players except for the one that triggered the the event -- local players = getElementsByType("player") for i=1, #players do if players[i] == client then table.remove(players, i) break end end -- -- triggerClientEvent(players, --[[...]]) end addEventHandler(--[[...]]) Other players (clientside): addEvent(--[[...]]) function functionName (ped, action, status) end addEventHandler(--[[...]])

Every function that makes the ped do anything, that also includes the "forward" state. (You are able to do that. Take a closer look at the zombie resource. That is if you want that.)

It looks pretty good. I have seen worse. One of the reasons for the stuttering is because some ped interactions are based on each client individuality. At the moment the peds are resynced by the syncer (position, rotation and velocity are being reset), the interactions that are set by the syncer player does not match up with the non syncer players. Interactions like: Animations Initial running speed Jumping etc. That being said, there is always some variation of stuttering involved when streaming element orientations. How to solve this interaction de-sync problem? You might want to consider doing some of the ped interactions serverside. Or the same way as the streamer works: You set an <animation/interaction> for your ped Send a message to serverside. Serverside sends a message to all other clients (excluding yourself). And those clients set the <animation/interaction>.

open the file meta.xml Remove the following line: <min_mta_version client="1.5.4" server="1.5.4" /> The script will start, but some of the new features will not work (like increased draw distance for vehicles and peds). You could notice some errors in the console at the following lines, but that should be fine. https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/main_c.lua#L259 https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/main_c.lua#L260 https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/main_c.lua#L267 https://gitlab.com/IIYAMA12/draw-distance/-/blob/master/scripts/main_c.lua#L268

Is that really necessary? All you have to do is start the script. [v1.0.2] The script will start reading the element tree of running resources and mirror the objects with lowLOD elements. That is all there is to it at the very basic.

yea give it a try. ?