DiSaMe

Did you install the paths into the traffic resource? It says how to do this in the documentation. Put the contents of the path archive into the traffic resource in such way that it would overwrite the maplist.xml. I made the script and the paths separate, so that users would not need to redownload the paths in case I update the script.

I have a 32-bit Ubuntu system and I also have libmysqlclient.so.16, but MTA needs libmysqlclient.so.15, so I googled it, downloaded it and then put it into /usr/lib and now MySQL functions work fine.

How did you edit the model? The world object cannot just move when replacing the model. Maybe you edited it in such way that its all vertices are moved, resulting in movement of its geometric center while the object position remains the same?

From the image which you posted (http://i.imgur.com/r39PlhN.jpg) I can see it does because resolution of the object texture is very low in that image. If you see the same low LOD model when you approach the object, that means the high-detail object has been removed successfully and you just need to do the same with lod LOD object. But if the main object is still present, I have no idea what the problem could be.

Did you only remove the main object or its low LOD object as well?

Well, then you could try another way. Remove the original object with the function: removeWorldModel And then just create the object in the same place.

When you are far from the object, it's invisible. Its low LOD counterpart is shown instead. When you approach the object, it becomes visible. As long as the object which you created is in the exact same position as the world object and alpha/collisions are set to 0/false, there should be no problems - the only effect should be model replacement for the world object. I can't think of anything else to change.

Exactly. If limit for the strings sent to client is 65535 characters and the string couldn't be sent, that means it is longer than 65535 characters. And if you want to send that string without changing minimum client version, you have to workaround this. You could try splitting the string into multiple shorter strings using string.sub function and sending them as separate arguments. If that doesn't help, you could send multiple strings by triggering the event multiple times and joining the strings client-side.

There is no limit. You can put as many values as your computer can store.

Everything is fine with your primary script. Model replacement only has effect when at least one MTA element with that model is streamed in. Probably the simplest way to do what you want would be creating an object with the same model in the same place where the world model is and making it invisible and non-solid using these functions: createObject setElementAlpha setElementCollisionsEnabled When you do this, the object itself won't interact with the world, but because it is streamed in when you approach it, it will cause the model replacement to be visible and in result, the world object will change.

Does the XML file exist client-side? It must be either created in a client-side script or downloaded from the server by putting into meta.xml to exist on the client.

Oh, damn, so my code is useless

Put this code in the resources which use outputChatBox: addEvent("onOutputChatBox", false) _outputChatBox = outputChatBox function outputChatBox(text, visibleTo, r, g, b, colorCoded) local success = triggerEvent("onOutputChatBox", root, text, visibleTo, r, g, b, colorCoded) if success then return _outputChatBox(text, visibleTo, r, g, b, colorCoded) else return false end end Then cancelling the event "onOutputChatBox" will make triggerEvent return false, therefore preventing the true outputChatBox (which was renamed to _outputChatBox) function from being called: function cancelMessage(text, visibleTo, r, g, b, colorCoded) if text == "hi" then cancelEvent() end end addEventHandler("onOutputChatBox", root, cancelMessage)

Also, you could try playing around with runcode resource. It allows you to execute the Lua code typed in using /run (server-sided) and /crun (client-sided) commands.

If the server crashes, then it's a bug of MTA. As long as MTA works properly, in the case of script error it displays a message, not crashes.

It's planned to be fixed: http://bugs.multitheftauto.com/view.php?id=5854

Because you use dxDrawRectangle from the function which is called by the timer, not from the one which is attached to onClientRender.

Matrix which getElementMatrix returns contains 4 vectors. They are 4D vectors because they use homogenous coordinates. For simplicity you can ignore the 4th coordinate of vectors in this case. If we store the matrix into variable m, then m[4] is the position of element. m[1] is the direction from the element to the right (X axis of the element). m[2] points to the front (Y) and m[3] points up (Z). Because only element rotation and not position determines how absolute and relative coordinates of velocity are converted between each other, we only need m[1], m[2] and m[3]. If we have velocity coordinates rx, ry, rz which are relative to the element, then to find absolute coordinates ax, ay, az we need to do these calculations: ax = rx*m[1][1] + ry*m[2][1] + rz*m[3][1] ay = rx*m[1][2] + ry*m[2][2] + rz*m[3][2] az = rx*m[1][3] + ry*m[2][3] + rz*m[3][3] This shouldn't be hard to understand. The more X vector of element extends to the global X direction (m[1][1] is bigger), the more rx influences ax. Similarly, the more X vector points to the sky (m[1][3] is bigger), the higher is the point which is in the right direction from the vehicle (rx causes az to increase). In your case, we need to do the opposite: use ax, ay, az which we got from getElementVelocity to get rx, ry, rz. That would require to get the inverse of the matrix. But if length of the vectors is 1 and they're perpendicular to each other (something what rotation matrix usually looks like), then inverse will be the same as transpose of a matrix (the matrix in which columns become rows and vice-versa). So the code will look something like this: local ax, ay, az = getElementVelocity(element) local rx = ax*m[1][1] + ay*m[1][2] + az*m[1][3] local ry = ax*m[2][1] + ay*m[2][2] + az*m[2][3] local rz = ax*m[3][1] + ay*m[3][2] + az*m[3][3] rx is the element velocity to the right direction, ry is to the front and rz is up. I hope that helps

That's because you simply copied the meta.xml from another resource instead of creating your own. https://wiki.multitheftauto.com/wiki/Meta.xml

Of course, it will work. No matter how you set the target, every moment of time the target destination point is fixed at some location anyway.

Then remake all physics on the server. Use setElementSyncer to disable clients from syncing peds and various calculations to do the physics yourself. That is the most practical solution now.

function outPutFunc(string text) should be changed to function outPutFunc(text)

Simply wrong. Bandwidth is used by syncing and syncing is done when client is the syncer of ped, no matter if client does something with ped control states or not. Setting control states on the client is more efficient than it would be on the server. Using the client, you can just set the target of the zombie in the server and let the clients cope with the rest of the AI, including the control states. Doing everything on the server would require the syncing of different states, such as running and attacking, and that requires additional data transfer. Though if server had physics, players wouldn't need to be syncers and send the ped position data to the server, but that's another topic. So if you want your scripts to be bandwidth-efficient, the best choice is syncing the data smallest possible amount of data (such as target) with players who are near enough, using triggerClientEvent. That depends a lot on the efficiency of your script. Correct me if I'm wrong, but I doubt if it's easy to make such AI script which couldn't be optimized any more.

Both functions are ways to transfer the data from server to client, so that client could set the control states. setElementData is simpler, triggerClientEvent is more flexible. There's no way for the server to control the peds directly. That would require server-side physics to be implemented and that is not easy. Anyway, what's so wrong with client-side scripts?

triggerClientEvent --or setElementData