FiveM Programmiersprachen: Lua, JavaScript und C# im Vergleich

FiveM unterstützt offiziell Lua, JavaScript und C#. Wähle die Laufzeitumgebung, die zu deinem Framework, den Fähigkeiten deines Teams und den benötigten Bibliotheken passt – nicht eine vermeintliche universelle Leistungsrangliste. Alle drei können FiveM-Natives aufrufen, Ereignisse verarbeiten und Ressourcen-APIs bereitstellen. Die praktischen Unterschiede liegen in der Laufzeitgrenze, dem Paket-Ökosystem, dem Build-Workflow und dem Code, der bereits von deinen Abhängigkeiten verwendet wird.

Die hier gezeigten Konfigurations- und Codebeispiele beziehen sich auf FiveM für GTA V Legacy. Enhanced hat andere Laufzeit- und Kompatibilitätsregeln; überprüfe die Legacy-zu-Enhanced-Änderungen von Cfx.re bevor du sie auf einen Enhanced-Server anwendest.

FiveM Sprachvergleich

Laufzeitumgebung	Geeignet für	Wichtige Grenze	Typischer Arbeitsablauf
Lua	Bestehende Lua-Frameworks, kompakte Ressourcen und direkte FiveM-Beispiele	CfxLua ist eine modifizierte Lua 5.4-Laufzeitumgebung, keine beliebige System-Lua-Installation	Bearbeite Quelldateien und lade sie über das Ressourcen-Manifest
JavaScript	Teams, die JavaScript/TypeScript und npm-Tools verwenden	Client-Skripte erhalten keine Browser- oder Node.js-APIs; Server-Skripte verwenden FiveMs Node-Laufzeitumgebung	Führe Quellcode direkt aus oder kompiliere beziehungsweise bündele TypeScript zu JavaScript, das im Manifest aufgeführt ist
C#	.NET-Teams, typisierter Domänencode und kompilierte Projekte	Die Ressource muss die von der Cfx.re-Laufzeitumgebung erwarteten Assemblies und Dateien liefern	Erstelle aus einer Cfx.re-Vorlage und stelle dann die Build-Ausgabe bereit

Lua: der direkte Framework-Pfad

Cfx.re dokumentiert CfxLua als modifizierte Lua 5.4 Laufzeit. Das ist wichtig, wenn du FiveM-Code mit älteren Lua-Tutorials vergleichst: Sprachfunktionen und Laufzeitverhalten sollten gegen CfxLua geprüft werden, nicht aus dem Betriebssystempaket eines Servers abgeleitet werden.

Lua ist normalerweise die am wenigsten störende Wahl, wenn das Framework und benachbarte Ressourcen bereits in Lua geschrieben sind. Du kannst Ereignisse, Exporte und gemeinsame Konfiguration in derselben Sprache beibehalten und vermeiden, einen Build-Schritt nur für den Stil hinzuzufügen. Ein kleines Manifest kann separate Client-, Server- und gemeinsame Skripte auflisten. Halte serverseitige Geheimnisse und Berechtigungsprüfungen aus Client-Dateien heraus, auch wenn beide Seiten Lua verwenden.

Die kurze Syntax erleichtert das Scannen von Event-Handlern, ersetzt aber nicht das Interface-Design. Dokumentiere jede Event-Payload, validiere Werte auf dem Server und behandle ein Client-Event nicht als Beweis dafür, dass Geld, Inventar oder Berechtigungen gültig sind.

JavaScript und TypeScript: Beachte, auf welcher Seite der Code läuft

Der offizielle JavaScript Laufzeithandbuch beschreibt die ES2017-Unterstützung und die wichtige Trennung zwischen Client und Server. Clientskripte laufen in der FiveM-Client-Laufzeit ohne Browser- oder Node.js-APIs. Serverskripte nutzen eine angepasste Node.js-Laufzeit. Bei Legacy ist Node.js 16 der dokumentierte Serverstandard; eine Ressource kann Node.js 22 über folgende Option aktivieren: node_version '22' in fxmanifest.lua.

Gehe nicht davon aus, dass ein Paket, das in einem gewöhnlichen Node-Projekt funktioniert, auch in einem FiveM-Client-Skript funktioniert. Platziere Dateisystem-, Datenbank- und serverseitige npm-Abhängigkeiten an der Servergrenze. Für Editor- und TypeScript-Definitionen veröffentlicht Cfx.re die @citizenfx/client und @citizenfx/server Pakete. Diese verbessern die Typüberprüfung, gewähren aber keine APIs, die der ausgewählten Laufzeit fehlen.

FiveM dokumentiert auch Thread-Affinitätsbeschränkungen für einige serverseitige native Aufrufe. Wenn asynchroner Node-Code zum Haupt-Game-Thread zurückkehren muss, befolge die Laufzeitanleitung und verwende setImmediate wo erforderlich. Teste das erstellte JavaScript, das du tatsächlich bereitstellst, einschließlich Source Maps und Startreihenfolge, anstatt nur die TypeScript-Quelle.

C#: Verwende die unterstützte Projektform

Das C# Laufzeitdokumentation bietet aktuelle Projektvorlagen und Build-Anleitungen. Beginne dort, anstatt ein altes Assembly-Layout aus einer nicht verwandten .NET-Anwendung zu kopieren. Eine C#-Ressource hat normalerweise ein Projekt, das die unterstützten CitizenFX-Assemblies referenziert, ihren Code kompiliert und die resultierenden Dateien dort ablegt, wo das Manifest sie laden kann.

C# kann gut passen, wenn das Team bereits .NET-Typen, Werkzeuge und Testverfahren nutzt. Dafür müssen Mitwirkende und CI über das passende SDK und den richtigen Buildbefehl verfügen; das bereitgestellte Artefakt muss zum Quellstand passen. Dokumentiere Vorlage, Zielframework und Release-Prozess im Repository, damit Serverupdates reproduzierbar bleiben.

Das gemeinsame Modell: Manifeste, Natives, Events und Exports

Die Sprachwahl ändert die technischen Vorgaben für Ressourcen nicht. Jede Ressource benötigt ein Manifest namens fxmanifest.lua , das Metadaten und die zu ladenden Dateien deklariert. Client-Code läuft für verbundene Spieler; Server-Code läuft unter FXServer. Geteilte Dateien werden an beide Seiten geliefert, daher dürfen sie keine Anmeldeinformationen oder nur serverseitige Vertrauensentscheidungen enthalten.

• Natives stellen Spiel- und Plattformfunktionen bereit. Prüfe die aktuelle Native-Referenz und ob ein Native auf dem Client oder Server ausgeführt wird.
• Events übertragen Nachrichten innerhalb eines Kontexts oder zwischen Client und Server. Behandle Netzwerkeingaben als nicht vertrauenswürdig und validiere sie serverseitig.
• Exporte stellen Funktionen für andere Ressourcen bereit. Dokumentiere Namen, Parameter, Rückgabewerte und Startabhängigkeiten.
• Abhängigkeiten Gehören in das Manifest oder die Serverstartreihenfolge, wenn eine andere Ressource zuerst verfügbar sein muss.

Ein gemischtsprachiger Server ist normal. Die stabile Grenze ist das dokumentierte Ereignis oder der Export, nicht die Implementierungssprache dahinter. Das ermöglicht es, eine Ressource zu ersetzen, ohne den gesamten Stack neu schreiben zu müssen.

Wie du für ein echtes Projekt wählst

1. Beginne mit dem Framework. Wenn der Server von einem etablierten ESX, QBCore, Qbox oder einer eigenständigen Ressource abhängt, verwende deren unterstützte Erweiterungspunkte und Sprachkonventionen.
2. Liste benötigte Bibliotheken auf. Prüfe, ob jeder Datenbanktreiber, jede UI-Bridge und jedes Paket mit der Client- oder Server-Laufzeit kompatibel ist, in der es ausgeführt wird.
3. Richte dich nach dem Team. Bevorzuge die Sprache, die Mitwirkende überprüfen, testen und pflegen können, nachdem der ursprüngliche Autor gegangen ist.
4. Definiere den Build. Lua kann direkt ausgeliefert werden; TypeScript und C# benötigen normalerweise eine reproduzierbare Kompilierung und ein klares Ausgabeverzeichnis.
5. Erstelle einen Prototyp der Grenze. Beweise einen nativen Aufruf, ein servervalidiertes Netzwerkereignis, einen Export und einen Abhängigkeitsneustart, bevor du die vollständige Funktion erstellst.

Minimale Überprüfungs-Checkliste

• Starte die Ressource auf einem Staging-Server und überprüfe sowohl die Server- als auch die F8-Client-Protokolle.
• Verbinde einen sauberen Client erneut und starte die Ressource neu, um fehlende Dateien oder Annahmen zur Reihenfolge aufzudecken.
• Sende ungültige und nicht autorisierte Event-Payloads und bestätige, dass der Server sie ablehnt.
• Überprüfe die dokumentierte Node-Version oder die .NET-Build-Ausgabe auf dem tatsächlichen Deployment-Host.
• Pinne Abhängigkeitsversionen und bewahre eine Rollback-Kopie der letzten funktionierenden Ressource auf.

Es gibt keinen evidenzbasierten Grund, eine der drei FiveM-Programmiersprachen als universell schnellste oder beliebteste für jede Ressource zu krönen. Wähle Lua, JavaScript/TypeScript oder C# aus den unterstützten Laufzeitfaktoren, dem umgebenden Framework und den Wartungskosten, die dein Team tatsächlich tragen kann.

Laufzeitunterschiede bei Enhanced

Enhanced ändert die JavaScript- und C#-Laufzeitumgebung sowie einige Plattformverhaltensweisen. Verwende die Dokumentation für die genaue Client-/Server-Edition, anstatt Legacy Node- oder Mono-Annahmen darauf anzuwenden. Erstelle und teste Abhängigkeiten gegen diese Umgebung neu.