zu einem zentralen menüplugin wie blacky es vorschlägt, habe ich mir auch schon detaillierte gedanken gemacht, und sogar angefangen, eines zu schreiben. das ganze ist aber bei genauerer betrachtung schwieriger als zunächst gedacht.
1) nehmen wir an, die menüs sollen in eine warteschlange aufgenommen werden, und ausserdem unterschiedliche prioritäten haben können.
nun wurde ein spieler TKt, und sieht das forgive-menü. dieses hat natürlich die höchste priorität. danach wird ein kick-vote gestartet, um einen spieler zu kicken, der eine niedrigere priorität hat. bevor der spieler das forgive-menü schliesst, oder es vom plugin geschlossen wird am rundenanfang, ändert der kick-votespieler seinen namen. danach wir das kickvote-menü, das schon in der warteschlange ist, einen falschen namen im vote anzeigen. man müsste also eine callback-funktion benutzen, um den menütext vom plugin zu erfragen, in dem moment, in dem das menü angezeigt wird.
2) ausserdem, damit das das forgive-plugin das menü wieder beenden kann, müsste es eine ID oder einen handle auf den warteschlangeneintrag erhalten, wenn es das menü aufruft. dieses könnte dann zum schließen des menüs genutzt werden, bzw. dem entfernen aus der warteschlange, wenn es noch nciht angezeigt wurde. wenn man nun aber ein plugin hat, dass für denselben spieler mehrere menüs in die warteschlange schieben kann (allein die möglichkeit reicht), z.B, ein umfangreiches voting-plugin, das zwei votes schnell hintereinnander anzeigt, während der spieler noch im forgive-menü ist, dann kann das vote-plugin die warteschlangeneintrags-handles nicht mehr in einem einfachen array über MAX_PLAYERS speichern. es müsste dateien oder ähnlich verfahren her, um sich die handles zu merken, und daten die damit assoziiert sind. ziemlich komplizierte geschichte wenn ihr mich fragt.
3) ein weiteres gedankenmodell: man sieht einen vote, hat aber noch nicht geantwortet. in dem moment wird man TKt, und bekommt das forgive-menü, da es höhere priorität hat. bei diesem vorgang müsste das vote-plugin informiert werden, dass es entweder das menü erneut anzeigt, oder diesen spieler bei der auswertung nicht mit berechnet.
4) der aufgabe des zentral-plugins, die ganzen handles und callbacks zu speicher, ist nur mit dateien zu realisieren, was nciht wirklich performant und übersichtlich ist.
wie ihr seht, ist das eine so komplexe sache, dass nichtmal ich mich getraut habe, weiter daran zu schreiben.
folgende prototypen müsste eine passende include-datei mindestens haben haben (einige davon habe ich auch schon implementiert):
Code: #define HANDLE_INVALID 0
enum priority {
PRIORITY_LOWEST,
PRIORITY_LOW,
PRIORITY_NORMAL,
PRIORITY_HIGH,
PRIORITY_HIGHEST
};
enum cancelReason {
REASON_TIMEOUT,
REASON_SUPERSEDED,
};
#define FLAG_NOBUYTIME (1<<0)
#define FLAG_NOSUPERSEDE (1<<1)
#define FLAG_NOENQUEUE (1<<2)
forward register_callback(
&hCallback,
Function[] );
forward register_menu(
&hMenuHandle,
hDisplayCallback,
hSelectCallback,
hCancelCallback = HANDLE_INVALID );
forward menu_enqueue(
hMenu,
id,
timeout = 0,
priority:Priority = PRIORITY_NORMAL,
flags = 0,
&hQueueItem = HANDLE_INVALID );
forward menu_cancel(
&hQueueItem );
forward get_menu_selectdata(
HLData,
&key,
&hMenu = HANDLE_INVALID,
&hQueueItem = HANDLE_INVALID );
forward get_menu_displaydata(
HLData,
&userindex = 0,
&hMenu = HANDLE_INVALID,
&hQueueItem = HANDLE_INVALID );
forward get_menu_canceldata(
HLData,
&userindex,
&cancelReason:reason = REASON_SUPERSEDED,
&hMenu = HANDLE_INVALID,
&hQueueItem = HANDLE_INVALID );
und ich habe niemals ein plugin damit geschrieben. in der praxis könnten noch weitere probleme auftauchen, an die ich bisher nciht gedacht habe.
|
Kommt ein Vote (es kommt ein neuer "menu" Text), dann macht er HANDLED zur Auswahl und er wertet die Eingabe zu Deinem Menü und der Vote-Text verschwindet. Es bleibt keine Möglichkeit mehr, noch mal etwas für den Vote abzustimmen, da er es dem Menü zugeordnet hat.
