ds1-e

@redditing You might check out my tutorial which explains data system based on tables -

On topic: Just for anyone wondering, i solved that by using cancelEvent() in onClientPlayerDamage attached to root (had already existing handler, but just for localPlayer).

Don't use fileDelete for client-side scripts, i consider cache="false" in meta.xml more reliable for that.

Of course it is, 2016 here

Why not, probably won't use it, but would be nice to look at it.

@IIYAMA I've looked into it again probably realised why there's a lot of non-confirmed hits. Apparently, there's some delay before bullet will hit player. Do you think scripting dealing damage via onClientPlayerWeaponFire + processLineOfSight will work out? Damage would be handled by victim. I'm curious, because i do not have opportunity to test it, and would like to know what you think about it.

There's no 100 % protection way, but at the moment is the best thing you can do.

Just compile them with highest level of obfuscation. For client-side scripts use cache="false" in meta.xml aswell.

Second example works fine, i've just tested it. About differences: - Example A register event with anonymous function. - Example B register event with non-anonymous function. How does it affect your code? Considering that you would want to remove this event handler, it will be not possible in A example (probably possible with searching _G). And for me it looks awful. So i prefer using B way over A.

One resource: No need for use exports (which are slow) or triggers. Direct access to functions. If you want to introduce/change something - you need to restart whole mod. Several resources: In order to have all functionality exports are needed or triggers. Using functions through exports/triggers (if function is in other resource). If you want to introduce/change something - you just restart desired resource. In other words, one resource for best performance, or several resources for elasticity. LUAC compiles (and obfuscates code if selected), compiling script converts it directly to Lua bytecode, therefore client/server doesn't need to do that.

Viva la MTA, good job everyone!

@85242 you could try aswell changing 2nd argument of dxUpdateScreenSource. As far i remember that's how i solved it.

Radziłbym wyjaśnić sytuację na forum/discordzie serwera na którym grałeś. To jest oficjalne forum MTA, i administracja nie ma władzy nad poszczególnymi serwerami (toteż nie możemy w związku z tym nic zrobić).

Очень легко. Понадобилось бы просто добавить: 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.