DiSaMe

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?

Although you can't change weapon properties per player, some effects can be achieved in other ways, and in your particular case, damage could be more or less handled manually: https://wiki.multitheftauto.com/wiki/On ... ayerDamage . By "more or less" I mean, it might become more complicated when vehicle damage and some other stuff comes into play.

In 5.1, only metamethod for userdata is mentioned: http://www.lua.org/manual/5.1/manual.html#2.10.1 In 5.2, metamethod is used for both tables and userdata: http://www.lua.org/manual/5.2/manual.html#2.5.1 Which means you can't do it in 5.1.

How do you know when you arrive at some destination? Do you calculate the distance in the beginning and then count down while walking? I doubt it, I think you're aware of the distance all the time and only stop when you see that you have arrived at the destination. So peds should work the same way, they must continuously check their position and see if they have arrived or not.

destroyElement ?

@myonlake Not sure what "sorting" you are talking about. Apart from element data not having "sorting" functionality at all, "sorting" here does not make any sense in the first place...

MTA streamer can handle up to 65536 objects. SA-MP, on the other hand, has no built-in streamer and its object limit is 1000.

What?

triggerClientEvent createObject destroyElement ?

Instead of drawing it pixel by pixel you could draw it row by row out of horizontal lines (1 pixel height rectangles) using dxDrawRectangle.

... getElementMatrix You can't keep the image at the same position from the vehicle's point of view just by using position. Obviously, rotation makes difference. And matrix is the most straightforward and intuitive way to represent the rotation.

You didn't say what the problem is, but it seems like you use the arguments incorrectly. 2nd argument of triggerServerEvent is the source of the event, and function arguments come after it. --client triggerServerEvent("someEvent", someElement, "aaaa", "bbbb") --server function handlerOfSomeEvent(arg1, arg2) -- 'source' is the same as 'someElement' was on the client -- 'arg1' is "aaaa" -- 'arg2' is "bbbb" end

toggleControl bindKey setControlState