Configurazione FiveM VS Code: server di linguaggio Lua, nativi, nessun avviso falso

Apri uno script perfettamente a posto in VS Code e sembra così:

Undefined global `PlayerPedId`.

Ogni nativo, exports, ESX e QBCore riceve una sottolineatura gialla, e i veri errori annegano nel rumore. Questa guida configura VS Code in modo che comprenda Lua FiveM, e ti avverte solo di cose che sono effettivamente sbagliate.

#Installa un server di linguaggio Lua

Nel pannello Estensioni, installa un'estensione Lua language server. Quella ampiamente utilizzata è l'estensione "Lua" di sumneko, che è costruita su Lua Language Server (LuaLS). Ti dà completamento, vai alla definizione, ridenominazione e diagnostica.

Apri la cartella delle risorse come area di lavoro (non un singolo file), in modo che il server possa vedere ogni script e le impostazioni che stai per aggiungere.

#Aggiungi definizioni di nativi FiveM

Plain LuaLS non ha idea di cosa GetEntityCoords accetta. La comunità mantiene tipologie per FiveM / CfxLua: un set di file di annotazione che descrivono i nativi, i globali Cfx.re e la sintassi Lua extra che FiveM consente. Cerca nel pannello Estensioni "CfxLua" o "FiveM natives", o cerca un componente aggiuntivo "FiveM" nel gestore di componenti aggiuntivi LuaLS, e seleziona quello che viene mantenuto attivamente.

Con loro installati ottieni firme quando digiti:

local ped = PlayerPedId()
local coords = GetEntityCoords(ped)

Passa il mouse su un nativo e vengono visualizzati i parametri e i tipi di ritorno. La maggior parte delle tipologie include anche exports, annotazioni lib se aggiungi le definizioni ox_lib, e la tabella cache.

Consiglio: i nomi delle estensioni e le impostazioni cambiano nel tempo. Se un'impostazione di seguito non esiste nella tua versione, controlla il README dell'estensione stessa, che è sempre più attuale di un tutorial.

#Impostazioni dell'area di lavoro

Crea .vscode/settings.json nella root della cartella delle risorse. Questo mantiene le impostazioni con il progetto, in modo che chiunque lo apra ottenga lo stesso comportamento:

{
  "Lua.runtime.version": "Lua 5.4",
  "Lua.runtime.nonstandardSymbol": [
    "/**/", "`", "+=", "-=", "*=", "/=", "<<=", ">>=", "&=", "|=", "^="
  ],
  "Lua.diagnostics.globals": [
    "ESX", "QBCore", "Config", "Locales", "PlayerData",
    "lib", "cache", "exports"
  ],
  "Lua.workspace.checkThirdParty": false,
  "Lua.workspace.ignoreDir": [".vscode", "node_modules", "dist"]
}

Cosa fa ogni parte:

• Lua.runtime.version corrisponde a lua54 'yes' nel tuo fxmanifest.lua.
• nonstandardSymbol dice al parser che l'assegnazione composta di FiveM (x += 1) e gli hash di backtick sono validi. Senza di esso, il codice perfettamente buono è segnalato come errore di sintassi.
• Lua.diagnostics.globals elenca i nomi che lo script definisce da qualche parte il server non può tracciare. Aggiungi il tuo: ESX, QBCore, una tabella Config da config.lua. Se un'estensione di tipologie dichiara già lib e exports, puoi rimuoverli dall'elenco.

Aggiungi solo veri globali. Se silenzi tutto, perdi l'avvertimento che cattura una variabile digitata male, che è una delle cose migliori che l'editor fa per te.

#Ripara gli avvisi che sono reali

Alcuni avvisi sono l'editor che fa il suo lavoro:

local players = ESX.GetPlayers()
for i = 1, #player do   -- 'player' is not defined: should be 'players'
end

Trasforma Lua.diagnostics.globals in un elenco breve e deliberato e ogni Undefined global rimanente è un errore di digitazione o un local mancante. È anche il modo più veloce per trovare globali accidentali, che la guida resmon elenca come fonte di prestazioni e bug.

Per i casi una tantum, un commento inline è meglio di un'impostazione globale:

---@diagnostic disable-next-line: undefined-global
local x = SomeOtherResourceGlobal

#Annota il tuo codice

LuaLS legge i commenti ---@. Poche righe rendono le tue funzioni autodocumentate e danno ai chiamanti il completamento automatico:

---@param plate string
---@param coords vector3
---@return boolean
local function isPlateNear(plate, coords)
    -- ...
end

Se costruisci una libreria che altri script chiamano attraverso exports, mettere questi annessi sulle funzioni esportate ripaga di più.

#Formatta al salvataggio

Installa StyLua (l'estensione per il formattatore StyLua) o usa il formattatore proprio del server di linguaggio. Per StyLua, aggiungi un stylua.toml accanto alle tue risorse:

column_width = 120
indent_type = "Spaces"
indent_width = 4
quote_style = "AutoPreferSingle"

Quindi nelle impostazioni di VS Code:

{
  "[lua]": {
    "editor.defaultFormatter": "JohnnyMorganz.stylua",
    "editor.formatOnSave": true
  }
}

Controlla l'ID del formattatore nel pannello Estensioni se non si attiva. StyLua potrebbe non amare la sintassi solo FiveM come gli hash di backtick, quindi eseguilo su una copia per prima se i tuoi script li usano molto.

#Cerca i nativi

L'editor ti dice la firma; il riferimento ufficiale dei nativi ti dice cosa fa davvero il nativo, con note da altri sviluppatori. Le pagine dei nativi si trovano su docs.fivem.net/natives, e il casella di ricerca trova un nativo per nome o descrizione. Due abitudini aiutano:

• Cerca per quello che vuoi, non il nome esatto: "get closest vehicle", "ped bone".
• Leggi il nativo Cfx.re per primo, quindi il testo di riferimento GTA V, poiché alcuni nativi si comportano diversamente sulla build FiveM.

Per i dettagli client/server, vedi client and server events e Wait and threads.

#Elenco di controllo