IIYAMA

<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)

I gave you an answer that would give your image a background color. If the answer is not helpful, then your question is incorrect. I also noticed before that your previous comment (hidden) was very toxic and disrespectful. Now you are trying to provoke a: Please behave yourself. LOCKED

Use a second label[+] or use a gridlist instead. Put another image behind that. Just use a 1x1 size image with a single color. Disable the image as well, to make sure it doesn't goes in front of the other image.

Afaik there is a Mouse up and down state. The second argument.

Hmm, not sure. I haven't seen another one. Instead of this, you can also rotate this: dxDrawImage(Radar.posX + Radar.size, Radar.posY, -Radar.size, Radar.size, uMaskShader); Instead of: dxSetShaderValue(uMaskShader, "gUVRotAngle", math.rad(iCameraRotation + 180)); You could also try dxSetBlendMode ("overwrite"). I am not sure if it will overwrite the color or applying negative result and therefore doing the same as an inverted mask. > Never tried that before.

You are not the only person that tried to create this. For my projectile I used the basic function: https://wiki.multitheftauto.com/wiki/DxDrawLine Which did indeed work. Created nice quality lines. While doing this project there was 1 wall I hit with project that ended up making it a failure. The map-draw resource required heavily on realtime updates for all 3 dimensions: x, y and z. Depending on the height of the camera, the order and opacity for each element was adjusted. This was required because the maps did also have multiple (building) floor. Which ended up in too many draws on a single rendertarget. While my computer could easily handle it, that was not for everybody the case. This was more or less the :~ty math I used:

That only happens on a local server, since clients/players normally can't change the server `realtime`. Or your code is clientside by accident.

Maybe stopping the engine does work as well. It is not as if I have already tried it before.

Did you try to capture the pixels, transfer them to a new texture (and maybe enable mipmaps if needed)? (do not do this every frame) That way you wouldn't lose your rendertargets either after minimizing etc.