IIYAMA

There is also a useful function you can use. https://wiki.multitheftauto.com/wiki/CheckPassiveTimer Which represents DNL291's second way, but with it's own ecosystem.

A combination. - hit events is for starting the timer. - The timer is used to check if everybody is inside of the colshape meets all the criteria. Like if everybody is still alive or inside of a vehicle. For a basic script, bandwidth is only used when a player hits or leaves a colshape. You do not have control over that, since it is always working even if you do not add eventHandlers. But keep in mind that if you use that timer to synchronize the same information over and over, sure that can be bad.

Is freeroam start able? Since the stage resource wants these resources to be working before you can start it: freeroam realdriveby emerlights You can also delete this include xml tag from stage: <include resource="freeroam" /> Which allows you to start it, but first make sure freeroam can start since that is better idea.

Cool When creating your vehicles you can link the ID to the vehicle in a few ways. Either by table: No synchronization server/client Across resources if you use exports. More maintenance (if a vehicle gets deleted) local linkVehiclesToDataBase = { element_to_ID = {}, ID_to_element = {} } function setVehicleByDataBaseID (ID, vehicle) linkVehiclesToDataBase.ID_to_element[ID] = vehicle return true end function getVehicleByDataBaseID (ID) return linkVehiclesToDataBase.ID_to_element[ID] end function setDataBaseIDByVehicle (vehicle, ID) linkVehiclesToDataBase.element_to_ID[vehicle] = ID return true end function getDataBaseIDByVehicle (vehicle) return linkVehiclesToDataBase.element_to_ID[vehicle] end --------- local ID = --... local vehicle = createVehicle(--[[...]]) setDataBaseIDByVehicle (vehicle, ID) -- enables: getDataBaseIDByVehicle (vehicle) setVehicleByDataBaseID (ID, vehicle) -- enables: getVehicleByDataBaseID (ID) Or by ID: setElementID ( vehicle, "vehicle-database-ID:" .. ID) https://wiki.multitheftauto.com/wiki/SetElementID Less maintenance Synchronization server/client Across resources Problem that can occur: Double ID's created by other resources or ID overwrite by other resources. + https://wiki.multitheftauto.com/wiki/GetElementID https://wiki.multitheftauto.com/wiki/GetElementByID

You can loop through all vehicles and check if their plate is the same as the item in the database. But it is easier and more efficient to set an identifier when you create the vehicle. What is used as your database primary key per vehicle?

I am not sure why you want to pass the plate into that function. But the function requires a player, not a plate. Basically this would give you the closest vehicle from the player that executed the event: local vehicle = getNearestVehicle( client ) But if you also want to pass the plate as well, sure that is also possible. Adding a second argument: local vehicle = getNearestVehicle( client, vehicleplate ) And adding second parameter: function getNearestVehicle( player, vehicleplate ) Note: If you do this, you will have to do something within this function with the plate, else it has no functionality.

Did you actually select something from the list? (and is it still selected when you clicked the button?)

So yes. Since you clicked on the button, which makes the button the source and not the gridlist. So that condition will never be true. Just change it to: if gridlist then -- or: if isElement(gridlist) then -- < if you do not trust anything Now you check if the gridlist is actually created. How does it feel to debug like this? Line for line until you know where and what the problem is.

<A> Now debug each condition until you find the one that isn't met: iprint("function call") if button == "left" and state == "down" then iprint("correct mouse button") if source == gridlist then iprint("source is correct") local Selected = DGS:dgsGridListGetSelectedItem(gridlist) -- keep in mind that this variable starts with a capital S if Selected ~= -1 then iprint("did select something Selected") <B> You can also do it like this, debugging literally the condition, before doing the condition itself: (which takes more time to set-up, but gives also a lot more information) iprint("correct mouse button:", button == "left" and state == "down", ">input>", button, state) if button == "left" and state == "down" then iprint("source is correct:", source == gridlist, ">input>", source, gridlist) if source == gridlist then local Selected = DGS:dgsGridListGetSelectedItem(gridlist) -- keep in mind that this variable starts with a capital S iprint("Selected is correct:", Selected ~= -1, ">input>", Selected ) if Selected ~= -1 then Normally I start with <A>, finding out the location of the problem and then do <B> to figure out what is actually going on. (Edit, it seems like \[ B \] makes my text bold...)

Any errors? Does the function SellBttn... gets called after clicking? (Just the function, not all the condition within)

You will have to run this part, when the data is available: (line 7 until 11) local items = getElementData(localPlayer, "weaponmodel") column = DGS:dgsGridListAddColumn(gridlist, "Weapons", 0.5) for k, v in ipairs(items) do row = DGS:dgsGridListAddRow(gridlist, v[1]) DGS:dgsGridListSetItemText ( gridlist, row, column, v[1] ) end local items = getElementData(localPlayer, "weaponmodel") And if you only do this once, you probably do not need elementdata. addEvent("onLoadOwnWeapons", true) addEventHandler("onLoadOwnWeapons", localPlayer, function (items) column = DGS:dgsGridListAddColumn(gridlist, "Weapons", 0.5) -- < this line can be moved back to it's original spot. for k, v in ipairs(items) do row = DGS:dgsGridListAddRow(gridlist, v[1]) DGS:dgsGridListSetItemText ( gridlist, row, column, v[1] ) end end, false)

When the event onLoadOwnWeapons is fired, your data is ready to be used.

The second situation is obvious, because the data isn't available yet. The first and third are a little bit strange. Maybe it is for some unknown reason also related to the timing. Debug code: -- serverside -- BEFORE line 12 newTable.tickCount = getTickCount() -- verification -- line 12: setElementData(source, "weaponmodel", newTable) -- AFTER line 12 triggerClientEvent(client, "onLoadOwnWeapons", client, newTable) -- client addEvent("onLoadOwnWeapons", true) addEventHandler("onLoadOwnWeapons", localPlayer, function (items2) local items = getElementData(localPlayer, "weaponmodel") iprint("\n\nitems:", items, "\n items2:", items2, "\n\n") end, false) And compare those values. (+ screenshot)

Yup, As the resource stated: Might be able to modify it, so that you reduce the camera updates to 1/3 of the total fps, but I am not sure if that looks nice since it is an inconsistent frame rate.

Then you first need to learn Lua. After that you need to learn a little bit from MTA scripting. (where to find stuff, how to read syntax, what is an element?) And when know the basics from both worlds, it would be the right moment to ask these kind of global questions. Sure, it is fine to ask these questions in your current programming state, but will not be very educational for yourself.

It does matter which incorrect value you see, since it can point to the direction of the problem.

onClientResourceStart triggers later than the moment you try to attach the addEventHandler below.

onClientPlayerJoin doesn't trigger for the localPlayer, only for the remote players (players other than yourself). Use onClientResourceStart instead. Or use onPlayerJoin serverside, if you are not using triggerClientEvent event directly after that event (, then it doesn't matter if the client has loaded his resource). But if you are planning that in the future, then keep using onClientResourceStart. https://wiki.multitheftauto.com/wiki/OnPlayerJoin

There is an up and down state. (press/release) https://wiki.multitheftauto.com/wiki/OnDgsMouseClick function BttnClick(button, state) -- button: left/right/middle -- state: up/down if button == "left" and state == "down" then end end

I already gave you the components that are in my first post. I don't think I can explain it any better, unless you ask specific questions. DX is an (after) effect, not an element, therefore those rectangle/text things on your screen are nothing but "AIR". Which means that if you want to check if you clicked on them, you need to check if the cursor position is within the position of the things you are about to draw. If the concept of DX-UI is unclear, how about you try something that shows DX and but works as a GUI? There is also a whole wiki . @thisdp did a very good job including all features from the original GUI and more.

Yes, when you use onClientRender, it will create the same GUI every frame. So if you have 60 fps, you will create 60 GUI's per second. The big difference between DX and GUI? DX is just an effect drawn on the te screen(every frame), while a GUI is actually a ready to use user interface. Use the following function on your GUI element(s). https://wiki.multitheftauto.com/wiki/GuiSetVisible To show and hide them. A variable state "openPanel", can be handy for the current state, but a variable value change will not be able to automatically close or open the gridlist. The function call 'guiSetVisible' is required.

When you cancel the event, the tires can't be flatten. So you probably will have to do that manually. https://wiki.multitheftauto.com/wiki/OnClientVehicleDamage element theAttacker, int theWeapon, float loss, float damagePosX, float damagePosY, float damagePosZ, int tireID >>> Set clientside (for people with high ping AND can also be used to prevent an overflow of data between client and server, since you do not have to communicate with the server when the tire is already flatten): https://wiki.multitheftauto.com/wiki/SetVehicleWheelStates > triggerServerEvent Set serverside: (Now other players should be able to see it, I am not sure if this is required because I do not know if this tire state is streamed when the setVehicleWheelStates function is called on clientside.) https://wiki.multitheftauto.com/wiki/SetVehicleWheelStates Or do not cancel the event when a tire is hit.

This: results[1].password returns nil? First take a look in what is inside (this in most of the cases gives you the solution right away): inspect("Input password:", password, "\n Database results:", results) https://wiki.multitheftauto.com/wiki/DbExec dbExec doesn't support callback functions. It returns true when the connection is successful. This does not give you any information if the value is correctly set. dbExec(function() --triggerClientEvent(player, "loginSuccess", token) end, See here how to do that correctly (for insert): https://wiki.multitheftauto.com/wiki/DbPoll

When I was playing sa-mp 4 years back, players were teleporting all over the place and hard to hit, so I don't think that so called "animation lock" is not there for nothing. Note: The slide glitch can cause de-sync, since it brings the player in a glitch state. I think the developers from MTA decided to put correct synchronization above free-movement(by glitches). You can use this easy weapon switch resource, if you want some more free-movement. sa-mp is indeed like the original game, it is just a shell around the original.

You will have to add it when the server is not running. Because when the server stops, the loaded ACL/XML-DOM will be saved again. (which is old data from before the server has been started)