DiSaMe

If you need the server to start the movement of ped for everyone, then yes, you need to trigger the event for everyone. MTA does not sync control states, and that's why server does not have ped control state functions.

You're probably only triggering the event for syncer.

First of all, it won't crash anything, second, it won't cause the stack overflow, and third, it doesn't have to do anything with server apart from file contents being read and sent to client. Last, but not least, while it's much more inefficient than it could be done, the code is still far from making noticeable performance decrease on its own. The problem is the way the camera fading is controlled. It's not a good thing to reverse the effect of fadeCamera(true) with fadeCamera(false). Instead, you should simply not call fadeCamera(true). Since this particular case is related to compiled script, the closest thing would be replacing fadeCamera function in that resource with the one that doesn't do anything. function fadeCamera() end You can add this script into that resource (preferably before other files in meta.xml, though that might not be necessary, depending on what compiled scripts do inside). Then, whenever that resource calls fadeCamera, it will call this empty function rather than the real one, which will prevent the resource from fading camera in/out.

https://wiki.multitheftauto.com/wiki/DownloadFile

There is no magical way to make everything work the way you want. If you want server-side physics to keep all things working outside client sync range, you need to script them. Updating the position in the way I suggested prevents something what makes look sync worse, something that makes peds appear in positions where they're actually not. It prevents peds from being shown moving when they're not moving. Does it prevent peds from moving? No, because they're not actually moving in the first place.

Using setElementPosition...

They cannot be given a syncer if they're too far away, but if you keep them visible in their true position, you will avoid the situation when ped is near the player but still doesn't take damage. If you want them to take damage in any case, then you should sync it yourself when onClientPedDamage event is triggered.

I use getElementSyncer (to find out if ped is unsynced) and setElementPosition, it puts the ped at specified position, updating it for all clients. Unfortunately, it also includes the clients that are far away and should not care, which is the waste of bandwidth when many peds are present, but inefficient is still better than broken.

I think this might be the result of lack of updates for unsynced elements. The ped that is too far from all players to have a syncer will not be updated. Its AI might cause it to approach the player and they will be seen nearby client-side, despite the fact that they're actually further. When I make peds, I take care of unsynced ones by updating their position via script.

local addCommandHandler_real = addCommandHandler function addCommandHandler(...) local added = addCommandHandler_real(...) if added then local commandName = ... outputChatBox("Added command: "..commandName) end return added end

Taking care of things instead of leaving them to programmer is one of the purposes of high-level programming languages. So it doesn't feel right when the program that uses Lua for scripting doesn't do that. Programmer is responsible to make sure that invalid arguments are not passed to the functions. But failure to do so doesn't crash MTA - instead, an error or warning message is produced. Similarly, it should also take care of other programmer errors it is capable of detecting. I don't even see the destruction of element without removing the event handlers as a mistake. I see event handlers as a part of element they're attached to, similar to element data. When element is destroyed, everything that's part of it should be destroyed. As for reuse of element identifiers, I wrote about it a few days ago in this forum. Failure to remove all references to element upon its destruction is definitely a programmer's mistake. However, it is possible for a host program that uses Lua scripting to avoid the reuse of element identifiers and reduce the negative consequences of that mistake. My own program that uses Lua for scripting uses full userdata wrappers (whose lifetime is managed by Lua) to point to data allocated in C. When C data is destroyed, pointer in the wrapper is set to NULL to indicate nonexsistence of that data. As a result, no data with a particular identifier will ever get created until the last reference to this identifier is destroyed. Therefore failure to clean up the variables might not be different from memory leak (data structures allow access of those values but algorithms might not do anything about it), while in MTA it affects newly created elements and causes incorrect results to be silently produced.

If they still use memory, isn't that a problem of MTA itself? It doesn't make much sense for MTA to destroy elements without cleaning up the information which will never be used again.

I just did some testing and got 131042 unique element values. Further creating elements resulted in already used value being reused. In contrast, doing the same on my program resulted in 6360000 unique values before I stopped it (because it was eating memory really fast ). Therefore I think the way MTA handles elements is not really good. While the scripts should take care of cleanup anyway, reuse of element values that are already used by variables allows the problems to go unnoticed, and unique values can be guaranteed by using full userdata wrappers.

Is that similar to dangling pointers in C, where allocated memory is coincidentally put where some invalid pointer has already been pointing? I've thought of such problem occuring in MTA but since I clean up my tables, I never faced it. However, if element can be created with the value that's already assigned to a variable, that's design flaw. I'm making a program that's also scriptable in Lua and I avoid the problem by using full userdata wrappers. When C creates an object, it also creates a full userdata in Lua. This userdata holds the pointer to object, so it's a wrapper. Lua scripts can only see the wrapper. When object is destroyed, the pointer contained in the wrapper is set to NULL, so the program knows the value is not a valid object anymore. However, since that wrapper is full userdata whose lifetime is managed by Lua, new wrappers cannot be allocated at the same position in memory. As a result, no new wrapper will ever get the same position until every single variable holding the previous wrapper is assigned something else and the previous wrapper is garbage collected. Which means the scripts that don't clean up the tables will eventually make the program run out of memory instead of silently producing incorrect results.

That doesn't make much sense... The reason is that ammo data is only kept as long as the ped is streamed in. If the ped is streamed out after or while the weapon is given (that includes giving the weapon right after ped creation when it's not streamed in yet), then upon streaming in it will only have one bullet. The workaround is to give the weapon again, which can be done using repeatedly executing timer. Edit: oops, didn't notice "Never mind, I found a way to fix this" message.

I don't know any. What I was saying is that MTA already gives users enough possibilities in this case, so streaming is something what scripts and not MTA itself should deal with. People are often suggesting things which MTA is already capable of. They used to suggest such features like bone attachments or ped traffic, but that has been possible to do by scripting for a long time already. If you're the only one who needs the object count limit to be increased or removed, then I guess you have to script the streamer yourself or pay someone to do it.

Understand what? What's so efficient about continuous data transfer over network every time the object has to be streamed in/out? Where's all evidence that a properly scripted Lua object streamer is less efficient than SA-MP object streamers?

SA-MP? Did I just read "SA-MP"? Are you trying to say that server-side streaming for all players with communication over network is faster and more efficient than locally-running Lua script which only streams objects for local player? To be honest, that makes no sense at all.

I don't know if this issue is serious enough, but the fact that markers work incorrectly still remains true. Events are supposed to be triggered when the player enters the marker. Now they can be triggered when the player doesn't really enter the marker. That's obviously incorrect behavior. Now the best workaround is creating a collision tube. Adding the conditional statement based on height will prevent the actions from taking place when player enters the marker from above. Doesn't happen often, but still possible, and using collision tube for detection is more accurate. As for keeping the old scripts working, maybe some compatibility option could be provided (like 'legacy' argument for 'getElementMatrix'), but it's very unlikely that there are any scripts which rely on such incorrect and unintuitive behavior. So this is it, I'm not the one to decide if fixing the markers is worth it, but that would do more good than bad.

x == y or z This expression will check if either of conditions "x == y" and "z" is true. If "z" is anything besides nil or false, the condition will be satisfied. It's the same as this expression: (x == y) or (z) If you need to check if x is equal to either y or z, you need to make it this way: x == y or x == z

dbExec is a function that doesn't deal with results in any way. If you need to get a result from the database, use these functions: dbQuery -- to execute the query dbPoll -- to get results from the query

Um... Using variables, tables, element data or whatever other stuff you can find for general purpose data storage, probably?

createObject destroyElement getElementPosition

== operator checks if the values are the same, which they're not in this case. To check if the value inside the GUI element matches any value inside such table, you would need to through it: local gui_text = guiGetText(variable) -- stores the contents of the edit box into 'gui_text' local matches = false for key, value in ipairs(table) do -- loop through table, executing the following block of code for each value if tostring(value) == gui_text then matches = true break end end if matches then -- edit box content mathces a value inside the table else -- no table value is the same as the content of edit box end But it would be much simpler if you used the values as the keys of the table: table = {["1"] = true, ["2"] = true, ["3"] = true, ["4"] = true, ["5"] = true} ----------------- local gui_text = guiGetText(variable) if table[gui_text] then -- value of 'gui_text' is inside the table else -- value of 'gui_text' is not inside the table end

Using detachElementFromBone function which is documented inside the text file in that resource, I guess?