Das Framework-Kompatibilitätsproblem
Die meisten FiveM-Scripts kommen mit einem fest einprogrammierten Framework. Wenn du QBCore fährst, benutzt du QBCore-Scripts. ESX-Nutzer hängen mit ESX-Scripts fest. Standalone-Nutzer basteln sich das meiste zurecht. Agency Scripts wurden mit der gegenteiligen Philosophie gebaut: Das Framework ist ein Adapter, keine Voraussetzung.
Das Adapter-Pattern
Jedes Agency-Script stellt einen kleinen Satz an Lookup-Funktionen bereit: getPlayerData, getInventory, addMoney, removeItem, getJob. Wir liefern Adapter aus, die diese auf QBCore- und ESX-Implementierungen abbilden — out of the box. Für standalone implementierst du die vier oder fünf Funktionen selbst — meist ein Vormittag Arbeit — und jedes Agency-Script ist kompatibel.
Was das in der Praxis bedeutet
Wenn du deinen Server von QBCore auf ESX umstellst (was alle paar Jahre passiert, während sich Frameworks weiterentwickeln), müssen Agency-Scripts weder neu installiert noch neu konfiguriert werden. Du tauschst den Adapter, alles andere läuft weiter. Das ist im FiveM-Ökosystem extrem selten und der Hauptgrund, warum Serverbetreiber sich langfristig auf unsere Tools festlegen.
Welches Framework-Label auf unseren Produktseiten was bedeutet
Wenn eine Produktseite "QBCore, ESX" auflistet, heißt das, dass wir fertige Adapter für beide mitliefern. Steht da "Standalone", meinen wir, dass das Script framework-agnostisch ist — es braucht keinen Adapter und läuft auf jedem Server. In der Praxis ist fast jedes Agency-Script auf standalone-Setups mit einem kleinen Kompatibilitäts-Shim einsetzbar.
Wann du vor dem Kauf fragen solltest
Wenn du ein ungewöhnliches Setup fährst — eigenes Framework, stark modifiziertes QBCore oder etwas Maßgeschneidertes — öffne vor dem Kauf ein Ticket in unserem Discord. Wir sagen dir ehrlich, was funktioniert, was leichte Anpassung braucht und was den Aufwand nicht wert ist. Kein Verkaufsdruck; uns ist lieber, du kaufst ein Script, das passt, als drei, die nicht passen.
So funktioniert das Adapter-Muster in der Praxis
Wenn du ein Agency-Script installierst, enthält der Ressourcenordner ein framework-Unterverzeichnis mit mindestens drei Dateien: qb.lua, esx.lua und standalone.lua. Das Hauptscript erkennt automatisch, welches Framework vorhanden ist, indem es nach dem QBCore- oder ESX-Export sucht. Die passende Adapterdatei wird geladen; die anderen nicht.
Installation auf QBCore
Für QBCore-Server umfasst die Installation typischerweise drei Schritte: Ressource herunterladen, in den Ressourcenordner legen und zur server.cfg hinzufügen. Die Framework-Erkennung ist automatisch. Bei stark modifiziertem QBCore können spezifische Adapter-Funktionen in config.lua überschrieben werden.
Installation auf ESX
Die ESX-Installation folgt demselben Muster. Für ältere ESX-Versionen (vor 1.7): Setze den Legacy-Kompatibilitätsflag Config.ESXLegacy = true, der auf ältere ESX-API-Aufrufe umschaltet.
Installation auf Eigenständig
Eigenständig ist der Bereich, bei dem Serverbesitzer historisch am meisten auf Probleme mit anderen Scripts gestoßen sind. Agency Scripts' eigenständiger Pfad ist explizit und gut dokumentiert. Für jedes Script listet die eigenständige Adapterdatei genau auf, welche Funktionen implementiert werden müssen — typischerweise vier bis acht Funktionen.
Warum das für den Langzeitbetrieb wichtig ist
FiveM-Frameworks sind nicht dauerhaft. Server, die drei oder mehr Jahre in Betrieb waren, haben wahrscheinlich bereits mindestens eine größere Framework-Änderung durchlebt. Agency Scripts' Adapter-Architektur bedeutet, dass eine Framework-Migration nur die Adapter-Schicht betrifft. Deine Daten und Spielerfortschritte bleiben intakt.
Häufig gestellte Fragen
Verwenden alle Agency-Scripts dasselbe Adapter-Muster?
Ja. Jedes bezahlte Agency-Script und die meisten kostenlosen verwenden dieses Muster. Die einzigen Ausnahmen sind reine UI-Ressourcen wie Agency-Loadingscreen und Agency-Notify, die keine Framework-Interaktion haben.
Was, wenn ein neues Framework populär wird und noch nicht unterstützt wird?
Erstelle ein Support-Ticket auf Discord. Wir evaluieren neue Framework-Support-Anfragen basierend auf der Community-Akzeptanz. Für Frameworks mit bedeutenden Communities haben wir historisch innerhalb von 2-4 Wochen Support hinzugefügt.
Voraussetzungen-Zusammenfassung
- QBCore — jede aktuelle QBCore-Version. Automatisch erkannt, null Konfiguration für Standard-Setups.
- ESX — ESX Legacy 1.7+ oder Mainline ESX. Legacy-Flag für ältere Versionen setzen.
- Eigenständig — 4-8 Funktionen pro Script in config.lua implementieren.
Gemischte Framework-Adapter
Für Server mit hybriden Setups — zum Beispiel QBCore-Geld aber benutzerdefiniertes Inventar — ermöglicht das Override-System, bestimmte Adapter-Funktionen in config.lua zu überschreiben, anstatt das Framework zu ändern. Setze deine Framework-Erkennung auf QBCore, überschreibe dann spezifische Adapter-Funktionen, um dein benutzerdefiniertes Inventarsystem anstelle von QBCores aufzurufen. Das Override-System existiert genau für Server mit hybriden Setups.
Wenn eine Eigenständige-Implementierung sinnvoll ist
Einige Server, die technisch QBCore oder ESX verwenden, profitieren dennoch vom Schreiben eines benutzerdefinierten Adapters. Wenn dein QBCore stark modifiziert ist — benutzerdefiniertes Inventar, benutzerdefiniertes Geldsystem, benutzerdefiniertes Job-System — ist ein benutzerdefinierter Adapter manchmal sauberer als zu versuchen, den QBCore-Adapter für jeden Nicht-Standard-Teil zu überschreiben. Schaue auf die Komplexität an: Wenn du mehr als drei oder vier Override-Funktionen schreibst, ist vielleicht ein kompletter benutzerdefinierter Adapter der klarere Weg.
Langfristiger Wert der Adapter-Architektur
Der eigentliche langfristige Wert des Kompatibilitätsansatzes ist nicht nur die Unterstützung mehrerer Frameworks, sondern die Isolierung deines Servers von der Framework-Evolution. Wenn eine Framework-Migration die Adapter-Schicht betrifft, bleiben deine Agency-Phone-Daten, Agency-Admin-Protokolle, Agency-Blackmarket-Transaktionshistorie und Spielerfortschritte in Agency-Minerjob alle intakt. Du tauschst die Adapter-Dateien, aktualisierst config.lua, und die Scripts funktionieren weiter.
Praktische Migrationserfahrungen
Mehrere große Server-Betreiber haben uns berichtet, wie die Adapter-Architektur ihre Framework-Migrationen vereinfacht hat. Ein Server mit 150+ gleichzeitigen Spielern wechselte von ESX zu einem modifizierten QBCore und behielt dabei alle Agency-Scripts und alle Spielerdaten intakt. Die Migration dauerte ein Wochenende statt der befürchteten zwei Wochen — hauptsächlich weil das Agency-Skript-Ökosystem nicht die Hauptarbeit war.
Ein anderer Server migrierte von QBCore zu einem vollständig eigenständigen benutzerdefinierten Framework. Er schrieb einmalig einen benutzerdefinierten Adapter für alle Agency-Scripts zusammen (da die Adapter-Schnittstellen konsistent sind), und die gesamte Agency-Script-Suite funktionierte innerhalb von zwei Tagen. Der gleiche Zeitaufwand hätte für nicht-Agency-Scripts möglicherweise einen vollständigen Ersatz jeder Ressource bedeutet.
Diese Erfahrungen illustrieren den praktischen Wert des Designs. Das Adapter-Muster ist kein theoretischer Vorteil — es ist eine nachgewiesene Zeitersparnis bei echten, großen Server-Migrationen.
Gemeinschaftliche Adapter-Entwicklung
Wenn du einen benutzerdefinierten Adapter für dein eigenständiges Framework schreibst, ist deine Arbeit für andere Server mit ähnlichem Setup wertvoll. Wir ermutigen Serverbesitzer, ihre benutzerdefinierten Adapter-Implementierungen im #custom-adapters-Kanal unseres Discords zu teilen. Andere Server mit ähnlichen benutzerdefinierten Frameworks können von deiner Vorarbeit profitieren, und du bekommst Community-Feedback, wenn dein Adapter Verbesserungen braucht.
Dieser kollaborative Ansatz hat bereits mehrere hochwertige Community-Adapter produziert, zum Beispiel für populäre benutzerdefinierte Frameworks wie bestimmte modifizierte ESX-Versionen und spezifische RedM-Setups. Die offiziellen QBCore- und ESX-Adapter bleiben die von uns gewarteten, aber Community-Adapter für andere Frameworks erweitern die Agency-Script-Kompatibilität erheblich über das hinaus, was wir offiziell unterstützen können.
Zusammenfassung
Agency Scripts baut seine gesamte Produktlinie nach denselben Grundprinzipien: Framework-agnostische Architektur, schlanke Performance-Eigenschaften, klar dokumentierte Konfiguration und eine API, die echte Composability zwischen den Scripts ermöglicht. Kein Script ist eine Insel — jedes ist so gebaut, dass es gut allein und noch besser als Teil des Ökosystems funktioniert.
Für Fragen zur Installation, Konfiguration oder Kompatibilität ist der Agency Scripts Discord der schnellste Weg zur Hilfe. Die Community dort ist aktiv und hilfsbereit, und das Core-Team ist regelmäßig präsent. Für kritische Probleme steht auch ein direktes Support-Ticket-System auf der Tebex-Produktseite zur Verfügung.
Updates für alle Agency-Scripts werden über Tebex-Benachrichtigungen kommuniziert. Active-Business-Abonnenten erhalten neue Scripts automatisch ohne zusätzlichen Kauf. Changelog-Details erscheinen im #changelog-Kanal des Discords, damit du Updates bewerten kannst, bevor du sie auf einem Produktionsserver installierst.