IIYAMA

This goes wrong. It seems like Jeff has an item with the selected number. Make sure to check the syntax of this function, the function itself and his data in the database.

Add local in front of it, it should be scoped. local targetPlayer = callMember(number) With other words the callMember function does not work correctly. Go debug it! It is not an MTA function, so you will have to search for it in your files.

Is the callMember function not broken then? Or is the number incorrect? Debug this! This loop makes no sense. What if there are accidentally two phones with the same number? for k, v in ipairs(checkID) do Limit the query "SELECT * FROM phones WHERE number = ? LIMIT 1" And get only the first result: if #checkID == 1 then local v = checkID[1]

Send the message to the root. Which includes all players.(currently ingame) triggerClientEvent(root, "showMenu",

That is line 5 for us. If table is higher than 0? OR If table item count is higher than 0? if #result > 0 then

You will need triggerClientEvent for that. exports only work on the same client/server-side. Server (resource 1) triggerClientEvent (source, "fill in eventName", source, itemValue) Client (resource 1) It is important to place the addEvent on the resource that is triggering, this reduces errors: "event isn't added" addEvent("fill in eventName", true) Client (resource 2) addEventHandler("fill in eventName", localPlayer, showPhoneFunction, false)

localPlayer doesn't exist on serverside. It only exist on your own MTA san application, which is clientside. You need to define which player is going to receive the message on serverside. You wrote two times lang1. You forgot to write a fallback when no language is selected. local language = getElementData(source,"language") if not language or language == lang1 then outputChatBox("#FFFFFF "..nickA.. " #00CC40killed #FFFFFF ["..kills.."] #00CC40players!", source,255,0,0,true) elseif language == lang2 then outputChatBox("#FFFFFF "..nickA.. " #00CC40zabil #FFFFFF ["..kills.."] #00CC40hračov na CW!", source,255,0,0,true) end

You are already using elementdata, in the most possible global way. So the selected language is also available there.

Is it just me being blind or are you making a call from serverside to clientside? (Which is not allowed)

Debug the export list and see if the resource can be found. iprint(exports["s_phone"]) Else as I said before, use the call function. That one has never failed for me without a logic error.

You could save it in to an XML file > clientside There is a resource that does that automatic for you: https://community.multitheftauto.com/index.php?p=resources&s=details&id=16187 Including a wiki guide: https://wiki.multitheftauto.com/wiki/XmlSaveData No need for saving such data in to a database, as the user wants to have this info when he joins and not when he logins.

dbPrepareString does not apply changes to the database. The most logic reason I can think of for the dbPrepareString databaseConnection argument, are the string escape rules. But that is also where my knowledge ends. A database has a query queue, so if your timing is correct on Lua, the timing on the database is also correct.

I only gave you the concept of how traffic resource is doing that. You think you wouldn't find an enchanted version of that same code in the traffic resource? I am pretty sure there is, which is where you could start your search + understanding the code.

setVehicleHandling(vehicle, "engineAcceleration", handling.engineAcceleration + 0.4) setVehicleHandling(vehicle, "maxVelocity", handling.maxVelocity + 19)

Take a look at this function: https://wiki.multitheftauto.com/wiki/GetDistanceBetweenPointAndSegment2D This function allows you to calculate the shortest distance between a line and a point. If you did that for every line between the notes, you would be able to figure out which one is the closest to your ped or car.

Too scared to show your code? The people that do not show their code, are often using code that is not theirs and they are very well aware of that. Not sure if that is the case with you, but it is absolutely ? ! ? ! ? ! ? to make sure that nobody can help you anyway!

You know that you already send it right? (That is if you did save that information) Then you do not have to ask it again, which means no extra bandwidth. MTA messages are always in the correct order delivered because of the TCP data transfer protocol. And they will always be delivered, except when the player timed out and get kicked out of the server. If that has happened then you forgot to register which actions are currently going on in your server and also forgot to send that information to the new joined player.

There is no best way. Just be aware of the large amount of downsides of elementdata. Elementdata is nice for some functionalities, but do not use it when you have a scenario where it's features are not being used. Tables are pure for storing data on a player his computer. This data type only exist within a specific resource. It is very fast and clean. And cleans itself after the resource has stopped. Elementdata is a feature, that allows you to bind data on to an element. This data is available on all resources as it has left the Lua environment. Because the data leaves the Lua environment, it is not deleted when the resource stops. It is only deleted when the element is destroyed or when it is manually removed. By default this data is also shared with the server and all other players. Great! (if you want that) > Note: it can also quickly take over a large part of the network bandwidth when over using it. (results in Lag) But luckily it is possible to not share it with the server and the other players. bool setElementData ( element theElement, string key, var value [, bool synchronize = true ] ) Turn that OFF, by set it to false. Be aware: by default it is ON. Another benefit as well as a disadvantage is that element data has it's own event: https://wiki.multitheftauto.com/wiki/OnElementDataChange https://wiki.multitheftauto.com/wiki/OnClientElementDataChange Which gets triggered when the data changes. It is a nice feature, but it also uses a lot of performance. My recommendation Do only pick elementdata when you specific need to bind data to an element to SHARE it with another resource or other players. Do not over use elementdata. Be aware that elementdata is not data stored in your resource, but bound to your elements. Use tables everywhere you do no have to rely of elementdata features. Most of the time a triggerServerEvent is enough to share data with the server. Elementdata is a wild card.

Fade the camera to black. https://wiki.multitheftauto.com/wiki/FadeCamera Move the player out of the area. 0, 0, -10 https://wiki.multitheftauto.com/wiki/SetElementPosition And if the resource you use allows it, a dead player is a good default. (Be aware that you might have to modify the resource killmessages, to not show any death messages when a player despawns) https://wiki.multitheftauto.com/wiki/KillPed De-attach the camera to another position. Recommend far away from the player. 0, 0, 10000 This will make sure no unwanted player events will be triggered. https://wiki.multitheftauto.com/wiki/SetCameraMatrix

Correction. It should be after LEFT JOIN. Because you need first the data and then you set the condition/filter. LEFT JOIN `Item` ON `Player`.serial = `Item`.serial WHERE true

As far as I can remember here: FROM `Player` WHERE ... LEFT JOIN

I would suggest this format: ID (auto incremented) INT | playerSerial TEXT | itemType TEXT | amount INT This allows you lot more flexibility. (based on your current structure) SELECT `Player`.*, `Item`.Bandage FROM `Player` LEFT JOIN `Item` ON `Player`.serial = `Item`.serial Getting all the info of the player and the bandage quantity. The keyword JOIN allows you to join another table. LEFT means that: `Player`.serial = `Item`.serial It will get all the data from the table on the left side. (MAX all the rows of the leftside) Attach data from the table on the right side where possible.

There is 1 important reduction, which is in my opinion the most important one. "Don't tell the otherside what it already knows." So if you reply to my previous post with a confused reaction. Then I know you did that, but also you know that you did that yourself. Now we both know that it was a confused reaction and you do not have to tell me that again, because I already know. If we apply that same concept on a smart ped system. Ped move forwards. Ped move forwards -- do not repeat Ped move forwards -- do not repeat Ped move backwards Ped stop Ped stop -- do not repeat Ped stop -- do not repeat Ped stop -- do not repeat ---‐–––––————— If we want to fake something, we have to approach that a bit differently. For example we have a ped which we want to bounce his head up and down. And yes like this: Up and down while the car his driving. If you program this, the only data that should be used, is the on and off state. When ever the head is up or down, that is irrelevant. The data for the head orientation (up/down) is faked.

It is oke, but a lot patience is required. You need to make up your mind before resume. First of all, you are not dealing with just 2 types of sides. Serverside and clientside. This is what you are dealing with: Your servercode is only running on the server application. But your clientcode is running PER player. (MTA game application) So if there are 3 players in your server. The the same client-code will be running on each machine. > And the important thing about this is, is that each machine is running a copy of the code. Those copies can't communicate directly with each other and do not share data directly with each other. As you can see in the image, the server is always in between. There is no line between client 1 and client 2. So: 1 serverside 3x clientside (with a copy of the code) "Jeff" is not a player. This is a string value, with other words TEXT. If you want to have access to a player called "Jeff", you can use the function getPlayerFromName. This function will search in the server for a player with this name and sends back a value which you could consider a value that helps to identify a specific player. If the player is not in the server, the value will be false, which you could consider as NO to keep it simple. local player = getPlayerFromName("Jeff") if player then -- did we find a player with the name "Jeff" ? end if something then do something if NO then do this not Need a random player for testing? (serverside) local randomPlayer = getRandomPlayer ( )

A specific player. localPlayer is yourself as element. So if I would join your server, then the player that I control is the localPlayer. And the same goes for the player that you control, which is the localPlayer for you.