{"id":159060,"date":"2024-09-28T13:32:40","date_gmt":"2024-09-28T11:32:40","guid":{"rendered":"https:\/\/hifivem.com\/?p=159060"},"modified":"2026-08-15T19:30:00","modified_gmt":"2026-08-15T17:30:00","slug":"gleichzeitige-nutzung-von-esx-qbcore","status":"publish","type":"post","link":"https:\/\/rpcrate.com\/de\/simultaneous-use-esx-qbcore\/","title":{"rendered":"Gleichzeitige Nutzung von ESX und QBCore: Warum das nicht machbar ist"},"content":{"rendered":"

Direkte Antwort:<\/strong> F\u00fchre ESX und QBCore nicht als zwei autoritative Kerne f\u00fcr dieselben Spieler aus. Beide k\u00f6nnen technisch als FiveM-Ressourcen starten, aber sie modellieren Identit\u00e4t, Jobs, Geld, Inventar, Callbacks und Events unterschiedlich. Ohne eine speziell entwickelte Br\u00fccke und eine deklarierte Quelle der Wahrheit wird duplizierter Zustand unsicher und schwer wiederherstellbar.<\/p>\n

Warum zwei Kerne kollidieren<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Bereich<\/th>\nRisiko mit zwei Autorit\u00e4ten<\/th>\nErforderliche Kontrolle<\/th>\n<\/tr>\n<\/thead>\n
Identit\u00e4t<\/th>\nEin Spieler kann nicht zusammenh\u00e4ngende ESX- und QBCore-Datens\u00e4tze erhalten.<\/td>\nEine kanonische Identit\u00e4t und explizite Zuordnung.<\/td>\n<\/tr>\n
Geld und Jobs<\/th>\nUpdates k\u00f6nnen abweichen oder doppelt angewendet werden.<\/td>\nEine zust\u00e4ndige Komponente f\u00fcr Schreibzugriffe und gepr\u00fcfte Konvertierungsregeln.<\/td>\n<\/tr>\n
Inventar<\/th>\nElemente, Metadaten und Speichersemantik unterscheiden sich.<\/td>\nEine Inventarautorit\u00e4t; Adapter an der Grenze.<\/td>\n<\/tr>\n
Events und Callbacks<\/th>\n\u00c4hnliche Gameplay-Aktionen k\u00f6nnen nicht zusammenh\u00e4ngende Framework-Handler ausl\u00f6sen.<\/td>\nGepr\u00fcfte Adapter mit eigenen Namensr\u00e4umen statt globaler Spiegelung.<\/td>\n<\/tr>\n
Abh\u00e4ngigkeiten<\/th>\nEine Ressource kann den falschen Kern erkennen oder eine nicht unterst\u00fctzte API verwenden.<\/td>\nGenaue Abh\u00e4ngigkeits- und Startreihenfolgetests.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Was ist machbar<\/h2>\n

Ein Server kann f\u00fcr eine bestimmte Ressource einen Kompatibilit\u00e4tsadapter betreiben, wenn dessen Schnittstelle klar begrenzt ist und ein Framework ma\u00dfgeblich bleibt. Qbox dokumentiert beispielsweise eine QB-Bridge und ihre Grenzen. Das unterscheidet sich davon, zwei vollst\u00e4ndige Wirtschafts- und Spielermodelle nebeneinander zu betreiben.<\/p>\n

Entscheidungs-Checkliste<\/h2>\n
    \n
  1. Benenne den autoritativen Kern f\u00fcr Identit\u00e4t, Jobs, Geld und Inventar.<\/li>\n
  2. Liste die genauen Legacy-Ressourcen auf, die die Migration blockieren.<\/li>\n
  3. Bevorzuge den Austausch oder die Portierung einzelner Ressourcen. Nutze eine Bridge nur, wenn ihre Schnittstellenvorgaben dokumentiert und \u00fcberpr\u00fcfbar sind.<\/li>\n
  4. Teste nicht autorisierte Aufrufe, Wiederverbindungen, Neustarts und teilweises Abh\u00e4ngigkeitsversagen.<\/li>\n
  5. Wenn beide Kerne dieselbe Dom\u00e4ne schreiben m\u00fcssen, stoppe und \u00fcberarbeite vor der Produktion.<\/li>\n<\/ol>\n

    Umfang und Einschr\u00e4nkungen<\/h2>\n

    Es gibt keine universelle Antwort f\u00fcr jeden Fork oder eigenen Adapter. Eine sorgf\u00e4ltig entwickelte Bridge kann einen begrenzten API-Bereich \u00fcbertragen, muss aber Zust\u00e4ndigkeiten, Fehlerverhalten und Persistenzregeln festlegen. \u201eQB-kompatibel\u201c belegt keine vollst\u00e4ndige QBCore-Kompatibilit\u00e4t auf einem anderen Framework.<\/p>\n

    Prim\u00e4re Quellen<\/h2>\n