Andere Menüs übernehmen

ESX legt ein Menü unter einem Typ ab und gibt es an den weiter, der den Typ registriert hat. Wer default registriert, ersetzt also esx_menu_default und kein Script, das ein Menü öffnet, merkt etwas davon.

esx.icons ist aus, weil ESX-Menüs nie Icons hatten: esx_inventory schreibt an jedes Item ein Icon, das nie gezeichnet wurde. esx.html ist an, weil ESX-Scripts HTML in Labels schreiben und es so meinen, etwa den grünen Kontostand. Aus nimmt das HTML heraus, statt es als Text zu zeigen.

ESX.OpenContext und die anderen rufen exports['esx_context'] auf und es_extended tut das nur, wenn eine Resource mit diesem Namen läuft. bridges/esx_context ist so eine: fünf Exports, die an cs_menu weitergeben.

• Ein Kontextmenü zur Zeit, ein neues ersetzt das offene.
• onSelect(menu, element), in menu.eles steht jeder getippte inputValue.
• Eingaben vom Typ text, number mit inputMin/inputMax und radio.
• unselectable und disabled, canClose = false, RefreshContext und PreviewContext.
• Die Taste, die ein Vorschau-Menü fokussiert, ist Bridges.context.focusKey, linke Alt-Taste. Spieler ändern sie unter Einstellungen, Tastenbelegung, FiveM.
• LocalPlayer.state['context:active'] ist gesetzt, solange eins offen ist.

Zwei Hälften. Die Events gehören niemandem, cs_menu hört sie direkt, auch ohne qb-menu. Läuft das echte qb-menu noch, lässt cs_menu ihm die Events, damit niemand zwei Menüs bekommt. Die Exports gehören der Resource, die sie registriert. exports['qb-menu']:openMenu beantwortet deshalb nur eine Resource namens qb-menu und bridges/qb-menu ist genau das.

Gelesen wird die ganze qb-Form: header, txt, icon, disabled, isMenuHeader und params mit event, args, isServer, isCommand, isQBCommand und isAction.

ox_lib lässt sich nicht übernehmen. lib.registerContext ist eine Funktion in ox_lib selbst, keine andere Resource kann dafür einspringen. cs_menu bietet dieselbe Form auf seinen eigenen Exports an und ein Script stellst du bewusst um: lib. durch exports.cs_menu: ersetzen. Siehe ox_lib-Form.