DiSaMe

getElementMatrix That's how I made the tags sprayable on vehicles in my Drawtag script.

Anubhav, please, stop, that doesn't make any sense...

If you want to get the value from the table, then you must store it into the table first object_table = {} --creating and storing the object object_table[some_index] = createObject(...) --destroying the object destroyElement(object_table[some_index]) object_table[some_index] = nil -- although object no longer exists, its identifier value is still there, so we assign nil to remove that value and free the memory

Not by using non-existent functions, I guess?

isLineOfSightClear processLineOfSight

Perhaps because 'setWeaponProperty' is server-sided while "onClientResourceStart" is client-sided?

No table? Obviously, there is a table (that's how data is stored in SQL databases), and the error messages say exactly what's wrong: the table has 9 colums, therefore takes 9 values for each row, but the query string passed to 'executeSQLQuery' only has 8 values. Same with another error - there's no column 'huntersReached'. The table in the database is clearly different from the one that is specified in table creation query in this script. Excuse me, but that doesn't make any sense.

addEvent addEventHandler triggerServerEvent --or setElementData -- element data is synced if you set it for server-side elements unless you explicitly specify not to sync it Use loops for i = 1, 5 do outputChatBox(tostring(i)) end Outputs: 1 2 3 4 5 The code inside the loop block (therefore 'outputChatBox' too) will be executed 5 times, with different 'i' value every time.

Or just draw the chart pixel by pixel into render target.

It's not like we can tell the functions if you don't say what exactly you need to do. Gang system doesn't really need functions.

Calling 'setElementData' triggers "onElementDataChange"/"onClientElementDataChange". If these events cause 'setElementData' to be called, you get an infinite recursion. You could make a variable that stops the execution of event handler if element data is being reverted. An example: local revertingData addEventHandler("onElementDataChange", root, function(dataname, oldvalue) if revertingData then return end revertingData = true setElementData(source, dataname, oldvalue) revertingData = nil end) 'setElementData' call in this handler will cause the same handler to be called recursively, but the checking of 'revertingData' variable will prevent the subsequent recursive calls.

And it still won't work because the parent of all markers is 'ele'. That's it, if you want to abstractly link values, so that knowing one value would allow you to get another, it's better to use tables than parent/child hierarchy.

Events have 'hidden' variables, one of which is 'source' (more info about them: https://wiki.multitheftauto.com/wiki/Event_system). 'Hidden' variables are actually global variables that are set before the handler is executed and unset after it's done. Every event has source which is an element related to that event (In case of "onPlayerJoin" it's the player who joined), and if there's additional data, it's passed via function parameters. As for "providing parameters" in 'addEventHandler', no, you don't provide parameters when you pass the function as a value. -- this will call 'someFunction' and pass 'someOtherFunction' as an argument: someFunction(someOtherFunction) -- this will use the return value of 'someOtherFunction' as the argument for 'someFunction': someFunction(someOtherFunction(someArgument)) -- this has the same effect as 'someFunction(someOtherFunction(someArgument))': local returnval = someOtherFunction(someArgument) someFunction(returnval) When you pass 'whenPlayerJoins' as an argument to 'addEventHandler', that means MTA will call 'whenPlayerJoins' function every time "onPlayerJoin" event is triggered. The parameters passed to the handler function depend on event. It's not so much different from what you can do in C: void someFunction(int (*funcPtr)(int funcArg)); int (*someOtherFunction)(int funcArg); int main() { someFunction(someOtherFunction); return 0; } (Not sure if syntax in this example is correct) Basically, if you have 'someFunction' and 'someOtherFunction' defined, this will call 'someFunction', passing 'someOtherFunction' as an argument, and if 'someFunction' calls 'funcPtr', it will call the function that was provided. The difference is that C, as a low level language, requires function parameter lists to be predefined and matching (both 'funcPtr' and 'someOtherFunction' accept one integer), while Lua doesn't make it all that strict.

It seems to be planned, but if it's so critical that you can't wait, you can script the compression in Lua.

A function can be made local, look at this example: local function testFunction () end Each function you create without the 'local' will automaticly be created as a 'global' function. I have no idea what's the exact difference between them but there is something haha. Maybe it's because of the scope for other files, but not sure if this is because of the OOP version of LUA... That's wrong. Every value can be accessed from anywhere it is passed to. All I can see in your example is that you're creating a function and storing it to a local variable 'testFunction'. Yet, I don't see such things like "local" or "global" values, no matter if they're numbers, strings, tables or functions. The line 'local testNumber = 1' doesn't create a "local number" either.

I don't understand this either. After all, function cannot be "local" or "global", it's just a value which, like any other value, can be stored in local and global variables.

DX drawing functions do exactly what their names say, they draw, and drawing means changing the colors of pixels on the screen.

Only low LOD (level of detail) objects can be seen from long distances. You need to create another object and set it as low LOD counterpart of existing object using this function: setLowLODElement When objects become invisible because of long distance, low LOD objects become visible.

getGroundPosition

Then maybe you should try drawing them closer to camera?

setWeaponProperty("weapon_name", "weapon_skill_level_to_affect", "property_name", property_value) ...

destroyElement

showCursor And even if there was no such argument, there's still a function setControlState which can make you walk.

onClientPreRender?

[CSG]NOki, you seem to find the problems in the script when they're actually not in there. If client-side functions do not work (but other functions do), then the script is clearly server-sided, which is either specified explicitly in meta.xml or not specified, in which case MTA uses it as server-side script by default.