savour

@arciCZ In that case remove the formFields and replace it with postData (convert the table to json)

Well, in "embeds" you can embed more than one embed, so you have to put it on another table (table per embed) embeds = { { -- This is embed number 1 title = "Hi", description = " S6066 authored & committed", fields={ {name="1",value="2"}, {name="3",value="4"} }, footer = { text = "Woah! So cool! :smirk:", icon_url = "https://i.imgur.com/fKL31aD.jpg" } } }

You can use "INNER JOIN" but you will need to practice it a little bit (columns with the same name will be prefixed with the table name)

Someone told me that he had bugs retrieving the false values from a json table (makes the value nil, which results of removing it from the Lua table). I didn't really test that bug but it should be fine, you can make some work around if you encountered it, not fatal bugs at the end so you are good to go (still, columns or another table are easier)

IIYAMA's answer is the ideal way to handle that, storing items in a separate table, or use add another columns to your existing table. you can still store a whole table at one cell by the way but maybe you will find it a little buggy. you can store the table in a cell as JSON (text) using toJSON(table), and when you retrieve it use fromJSON()

When you poll the query, it returns a table including other tables, each one represents a row, like this: local dbQ = dbQuery(database, "SELECT * FROM `players` WHERE `serial` = ?", player_serial) local dbR = dbPoll(dbQ, -1) -- in this case you're only expecting one row so the player will be dbR[1] serial = dbR[1].serial name = dbR[1].name -- If you're dealing with multiple entries: local dbQ = dbQuery(database, "SELECT * FROM `players`") -- This will result: { {name = "player1", serial="serial1", ...}, {name = "player2", serial="serial2", ...}, -- and so on } About the dbExec, it will almost have no effect on the performance in your case, the query when the resource start will take some milliseconds ( kind of unnoticeable server lag ), so it should be fine. also you can test the performance by the getTickCount function to make sure everything is good

It means that it will wait for the results from the database, then continue executing, however, if the function didn't receive any value from the query during the `timeout` it will return nil, then continue the execution. for SQLite, you shouldn't worry about that (since it is on the same server, you almost get an instant response) so an ideal value should be -1 (no timeout) if you are dealing with a well-made database and healthy queries. This function, dbExec, doesn't return any value related to the query, it just executes the query, so you don't need a dbFree. (also, dbFree is used on a dbQuery return) and yea, you should use it when you expect no return from it, like creating tables of not exists, updating, dropping/deleting. Use dbPoll if you're expecting a result, dbFree if you don't expect a result (just like using dbExec). i will make it clearer: -- Here, you don't expect a result local qh = dbQuery(connection, "CREATE TABLE IF NOT EXISTS table_name") dbFree(qh) -- This is the same as dbExec(connection, "CREATE TABLE IF NOT EXISTS table_name") -- Here, you are expecting a result local qh = dbQuery(connection, "SELECT * FROM table_name") local result = dbPoll(qh, -1) -- (When using -1 timeout, you don't really need to use dbFree) However, you should use dbFree when setting a 0+ timeout with a chance of failure. It's a server-console command, which means that it's only available on the server's command prompt You should always use it in general. it makes quotes and other stuff to make sure it doesn't contain a second statement (which is the basic SQL Injection) is there. for the loops thing, it return a string and you concatenate it, so you can print it to see the difference, you will understand it more this way. one more thing, string buffering is extremely bad for the performance, instead use a table and concatenate it later.

Show me the error, and the area where it happens

Here you go https://gitlab.com/OwlGamingCommunity/mta-python-sdk

In this case, you need to check to see if any of the two windows are visible, for example: showCursor(guiGetVisible(window1) or guiGetVisible(window2), true) -- or you can make it shorter with oop showCursor(window1.visible or window2.visible, true)

It's totally expected, when you hide the gui at the first time, isCursorShowing will return false after, so when you execute the function again it will show the cursor, as simple as that: not true = false not false = true So, it you only want to hide it, why checking for its visibility showCursor(false, true)

In the first case, the first argument is the player who typed the command, and it's up to you to call it whatever you want. in the second case the source gotta be defined in the parent event/function, also it refers for "which element (player) am i going to trigger this event for?" also, the source is most likely to be hidden, you will find what it refers to when you search about the parent event in the wiki (would be like "The source of this event is ...")

The thing is, marker hits are triggered for a lot of elements (including other markers as well), not just players, so you have to specify that. local respawnMarker = createMarker(2, 0, 2.22, "cylinder", 1.0, 255, 100, 100, 100) function toSpawnIt(player) if source == respawnMarker and getElementType(player) == "player" then spawnPlayer(player, 10, 0, 5) end end addEventHandler("onMarkerHit", resourceRoot, toSpawnIt)

Simple if would do it if getTrainTrack and type(getTrainTrack) == "function" then --... end You can also check if it does exist in the _G table (which contains all global functions provided by mta/Lua)

I think Matrix:getForward() with processLineOfSight should do the purpose