majqq

Очень легко. Понадобилось бы просто добавить: addEventHandler(...) Внутри той же функций, переменная там существует. Вместо того, что бы сразу его добавлять.

I've found example of IIYAMA which should explain buffer (he taught me that! :D) For element data it might look different. At the moment i can think of disabling sync (4th argument). And with help of tables do the rest. Do not treat this code as a full solution, but more like a example. -- Client function onClientReceiveData(pData) local cachedData = false for i = 1, #pData do cachedData = pData[i] setElementData(cachedData[1], cachedData[2], cachedData[3], false) end end addEvent("onClientReceiveData", true) addEventHandler("onClientReceiveData", root, onClientReceiveData) function onClientDataSync(pData) -- end addEvent("onClientDataSync", true) addEventHandler("onClientDataSync", localPlayer, onClientDataSync) -- Server local buffersTable = {} function setElementDataWithBuffer(pElement, pKey, pValue, pTimeout) if not buffersTable[pElement] then buffersTable[pElement] = setTimer(function(pElement) if isElement(pElement) then triggerClientEvent(root, "onClientReceiveData", pElement, buffersTable[pElement]) end buffersTable[pElement] = nil end, pTimeout, 1, pElement) end return setElementData(pElement, pKey, pValue, false) end function onPlayerLogin() --triggerClientEvent(source, "onClientDataSync", source, buffersTable) end addEventHandler("onPlayerLogin", root, onPlayerLogin) In order to make it work, you would need to track all changes applied with custom element data implementation (since it do not sync). While on tables it would be way easier to do. Perhaps, there's other way but i don't think so. There's no reason to update data continuously, rather than on change. Maybe with help of events. You can use trigger to have a communication between two resources (not sure if event with same name on two different resources it's possible, but should be). local importedCache = exports.cache:getClientFiles() -- getting client files (they are loaded in different resource) -- Iterating over table, saving some data... triggerEvent("onClientCacheLoaded", localPlayer) -- I couldn't get any other solution. Since exports take some time, and due of different script order, i am triggering event which exist on same side (it could be different side though). To let know that files are ready to use. It would work even if event is registered later than script which catch loaded files.

Thank you for clarifying 🙂

If you could go with tables, then do it. From my own experience, i'd say that tables are way more efficient rather than element data. However you should remember about few things, when it comes to passing data (doesn't matter if it's element data or tables). 1) How often data is passed - the less - the better (use timers for reduction, aka buffers; collect pack of data, and then send it after 100-200 ms). 2) How much data do you pass - if you do not need to pass whole data, then don't do it (unless on init). Send certain values. 3) How you pass data - it should be well maintained to avoid issues. With tables it's easier to do. Haven't using using element data for a long time, but i'm pretty sure that: setElementData(client, "data", true) -- equals to 1 triggerClientEvent So every call of element data is one trigger, which is pretty bad. Imagine that you need to set 30 data at once (feels bad). You can see that tables won here local dataTable = {} local playerElement = getPlayerFromName("SERIOUSLY?") dataTable[playerElement] = {} dataTable[playerElement][1] = "First index." dataTable[playerElement][2] = "Second index." triggerClientEvent(root, "onClientDataSync", resourceRoot, dataTable) -- 1 call setElementData(playerElement, "First index", true) -- 1 call setElementData(playerElement, "Second index", true) -- 2 call -- Element data will trigger separately for each call. 4) Don't do those: local players = getElementsByType("player") local playerElement = false for i = 1, #players do playerElement = players[i] triggerClientEvent(playerElement, "onClientEvent", playerElement) end This will cause that triggerClientEvent will be called * count of players. Instead do: local players = getElementsByType("player") triggerClientEvent(players, "onClientEvent", resourceRoot) Since triggerClientEvent accepts table of players. And it would be just one call. Extra code to test by @IIYAMA. local sendingDelay = 100 -- ms local fps = 60 local timeSlice = 1000/fps local dataReduction = sendingDelay/timeSlice print("~"..(dataReduction - 1 ).." x times LESS per "..sendingDelay.."ms") You can see how certain delays affect server when passing data. If you have any other questions, feel free to ask. PS: Recently element data got some update with subscription mode, but i still advice to go for tables if you can

Afaik the right order is: COL -> TXD -> DFF.

Try changing: setPedAnimation (source,"FOOD","EAT_Burger",nil,false,false,nil,false) To: setPedAnimation(source, "FOOD","EAT_Burger", -1, false, false, false, false, -1, false) For future please use "Code", help yourself and others. If you want you can use newer version of DayZ mode because yours is very outdated. https://github.com/NullSystemWorks/mtadayz

Set loop to false in setPedAnimation.

Replace it with empty model. Model IDs are available here. https://wiki.multitheftauto.com/index.php?title=Weapons

Faster, and working way. function getNearestPlayer() local pX, pY, pZ = getElementPosition(localPlayer) local playersTable = getElementsWithinRange(pX, pY, pZ, 10, "player") local nearestPlayer = false local currentPlayer = false for i = 1, #playersTable do currentPlayer = playersTable[i] if currentPlayer ~= localPlayer then nearestPlayer = currentPlayer break end end return nearestPlayer end

Attach with trigger, it will be shown for all players, but do not forget to create object directly on client-side. Delay before attached object will appear wouldn't be significant.

This topic is from 2014. I doubt that he would answer you. Did you tried to make attachment on client-side? If you create object at server-side then no wonder why it's delayed.

You should fix it, before your server will die out of endless triggering. addEventHandler("onClientRender", root, function() triggerServerEvent("GetItem", root)--give an order to make this event "getItem" run in server per frame end) Trigger client/server even should be well maintained. Right now, you call this function every frame, what if more players will join?

Using source variable isn't safe. function EventName() if client then outputChatBox("Hi player!", client) end end addEvent("EventName", true) addEventHandler("EventName", root, EventName) https://wiki.multitheftauto.com/wiki/Script_security

Perhaps it's your issue: distance*0.033 It's a text scale.

Just do: tabla = {} Before loop.