heros951

jak zginę lub jestem nie żywy to w następnej rundzie nie dostaje się broni

public HLTV_event(){
     for(new i=1;i<=g_iMaxPlayers;i++)
     {
          if(CheckGive(i) && is_user_alive(i)) //tu mamy zabezpieczenie
          {
               give_item(i, "weapon_ak47");
               RemoveGive(i);
          }
     }
}

drugi błąd to taki, że posiada się 1 szt AK47 lecz w rzeczywistości można wyrzucić nieograniczoną ilość broni

Jakbym mógł poprosić przy waszych pluginach o słowo wyjaśnienia przy definicjach bo komendy to samemu uda mi się sprawdzić

#define AddGive(%1) (g_iGive |= (1<<(%1-1))) //Dodaje bit o indexie %1-1 do zmiennej g_iGive

#define CheckGive(%1) (g_iGive & (1<<(%1-1))) //Sprawdza czy bit o indexie %1-1 "jest" w zmiennej g_iGive

#define RemoveGive(%1) (g_iGive &= ~(1<<(%1-1))) //Usuwa bit o indexie %1-1 ze zmiennej g_iGive

#include <amxmodx>
#include <hamsandwich>
#include <fun>
 
new g_iGive;
 
#define AddGive(%1) (g_iGive |= (1<<(%1-1)))
#define CheckGive(%1) (g_iGive & (1<<(%1-1)))
#define RemoveGive(%1) (g_iGive &= ~(1<<(%1-1)))
 
public plugin_init()
{
    register_plugin("Give Weapon", "0.0.1", "Ni3znajomy")
    register_clcmd("say /bron", "cmdGiveWeapon");
    RegisterHam(Ham_CS_RoundRespawn,"player","Spawn",1)
}
 
public cmdGiveWeapon(id)
{
	if(!CheckGive(id))	AddGive(id)

	return PLUGIN_HANDLED
}
 
public client_disconnect(id)	if(CheckGive(id))	RemoveGive(id);
 
public Spawn(id)
{
	if(CheckGive(id))
	{
		give_item(id, "weapon_ak47");
		RemoveGive(id);
	}
}

Krótka przedmowa, czyli o czym ten poradnik

Będzie to poradnik nie o samym tworzeniu menu, lecz o tym jak to, w zależności od sytuacji, robić prawidłowo. Skupię się tutaj wyłącznie na nowym typie menu, który w najnowszym amx umożliwia prawie tą samą funkcjonalność, co stary typ menu, a dużo większą wygodę użycia. Jedynym brakiem tutaj jest brak możliwości utworzenia linii informacyjnej przed pierwszym elementem w menu (czyli zaraz pod tytułem), co jednak można obejść tworząc wielolinijkowy tytuł, o czym na końcu tego tutorialu w ramach bonusu W praktyce będzie to prawie wyłącznie o użyciu info w menu, czyli jak go używać z głową i do czego może się przydać.

Omówienie funkcji zostawiam dokumentacji Najpierw omówię złe praktyki i opiszę dlaczego są złe


1. Konstruowanie switcha w oparciu o info

Często widzę taki "koszmarek" jak sterowanie switchem w handlerze poprzez info, gdzie w info zawiera się numer pozycji, w postaci tekstu. Jeśli nie wiesz o czym mówię, zobacz przykład:

public show_menu(id) {
    new menu = menu_create("Menu serwera", "handle_menu");
    
    menu_additem(menu, "Wyświetl regulamin", "1");
    if(cs_get_user_team(id)==CS_TEAM_CT)
        menu_additem(menu, "Kup AK47", "2");
    else
        menu_additem(menu, "Kup M4A1", "2");
    menu_additem(menu, "Wyświetl top15", "3");
    menu_additem(menu, "Zobacz inne serwery", "4");
    menu_additem(menu, "Przekaż pieniąde graczowi", "5");
    
    menu_display(id, menu)
}

public handle_menu(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }

    new sKey[6], iKey, access, callback;
    menu_item_getinfo(menu, item, access, sKey, 5,_, _, callback);
    iKey = str_to_num(sKey);
    
    switch(iKey) {
        case 1: client_cmd(id, "say /regulamin");
        case 2: daj_bron(id);
        case 3: client_cmd(id, "say /top15");
        case 4: client_cmd(id, "say /serwery");
        case 5: client_cmd(id, "say /przelew");
    }
    
    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

Co tu i dlaczego jest źle? a to, że wymyślamy koło na nowo i marnotrawimy zasoby. Otóż niepotrzebnie używamy 3ciego parametru itemów z menu o nazwie info, aby determinować co klient kliknął w menu, przez co generujemy niepotrzebne utworzenie 3ch zmiennych w handlerze, konieczność pobrania info i przekonwertowania na postać numeryczną + podanie do każdego itemu dodatkowego parametru info, co generuje dodatkowe zużycie zasobów. Może i niewielkie, ale na pewno niepotrzebne Więc na pewno tworzenie menu w taki sposób dobrą praktyką nie jest.


ad 1. Konstruowanie switcha w oparciu o parametr item

Teraz poprawna wersja z użyciem, stworzonego do tego celu, parametru item z handlera, który przechowuje numer tego elementu, licząc od 0, czyli ten sam plugin wyglądać może tak:

public show_menu(id) {
    new menu = menu_create("Menu serwera", "handle_menu");
    
    menu_additem(menu, "Wyświetl regulamin");
    if(cs_get_user_team(id)==CS_TEAM_CT)
        menu_additem(menu, "Kup AK47");
    else
        menu_additem(menu, "Kup M4A1");
    menu_additem(menu, "Wyświetl top15");
    menu_additem(menu, "Zobacz inne serwery");
    menu_additem(menu, "Przekaż pieniąde graczowi");
    
    menu_display(id, menu)
}

public handle_menu(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }

    switch(item) {
        case 0: client_cmd(id, "say /regulamin");
        case 1: daj_bron(id);
        case 2: client_cmd(id, "say /top15");
        case 3: client_cmd(id, "say /serwery");
        case 4: client_cmd(id, "say /przelew");
    }

    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

i gwarantuję, że zadziała tak samo, a nawet lepiej Numeracja w item jest niezależna od numeracji klawiszy w menu, więc każdy additem i tylko additem zwiększa nam numer o 1, zaczynamy od 0 o czym trzeba pamiętać koniecznie. Exit nie ma numeru 0, ale specjalną wartość nazwaną MENU_EXIT, równą -3 (-2 i -1 to odpowiednio wstecz i dalej).


Trochę o samym parametrze info

No dobra, ale czym w końcu jest to info? Ano jest to informacja, którą możemy przekazać do handlerów menu, aby poinformować go o tym, co zawiera dana opcja. W przypadku przykładu 1, gdzie tworzymy je w kodzie statycznie lub prawie statycznie (różni się etykieta itemu pod klawiszem 2 w zależności od drużyny w podanym przykładzie) jest całkowicie zbędne. Jednak może się przydać przy tworzeniu dynamicznego menu. Oto następna zła praktyka:


2. Nieprawidłowe menu z graczami

Przyjrzyjmy się przykładowej implementacji menu do przelewu kasy, w którym możemy wybrać danego gracza i przelać mu pieniądze. Dla uproszczenia przyjąłem, że podaną funkcję show_przelew wywołuje handler z poprzedniego menu wyboru ilości kasy do przelania. Ilość ta jest podana w parametrze wartosc. gWartosci to 33 elementowa tablica globalna:

public show_przelew(id, wartosc) {
    new menu = menu_create("Wybierz gracza do przelania kasy", "handle_przelew");
    
    gWartosci[id] = wartosc;
    
    new players[32], num;
    get_players(players, num);
    for(new i=0; i<num; ++i) {
        new name[32];
        get_user_name(players[i], name, 31);
        menu_additem(menu, name);
    }
    
    menu_display(id, menu);
}

public handle_przelew(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }

    new players[32], num;
    get_players(players, num);
    przelej_kase(id, players[item], gWartosci[id]);
    
    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

Niby wszystko pięknie, na oko i po pierwszych testach działa, bo przecież itemów tworzymy tyle ile graczy, więc item będzie nam zwracał zawsze pozycję w tablicy players, którą zajmował dany gracz. No prawie... Bo co się stanie jak ktoś wyjdzie z serwera albo ktoś na serwer wejdzie? Jeśli nastąpi to w tablicy po indeksie gracza, którego chcemy wybrać to jeszcze pół biedy, ale jeśli przed to kolejność się zmieni. A niestety widziałem takie praktyki w wielu pluginach... No i w tym momencie dajemy kasę nie temu graczowi co trzeba...


ad 2. Prawidłowo działające menu z graczami

Jak to poprawić? użyć info! Tutaj, w przeciwieństwie do przykładu pierwszego, należy go użyć. Więc używajmy:

public show_przelew(id, wartosc) {
    new menu = menu_create("Wybierz gracza do przelania kasy", "handle_przelew");
    
    new players[32], num;
    new name[32], info[25];
    get_players(players, num);
    for(new i=0; i<num; ++i) {
        get_user_name(players[i], name, 31);
        formatex(info, 24, "%08X%08X%08X", wartosc, players[i], get_user_userid(players[i]));
        /*info[0] = wartosc; POPRAWKA - TEGO SPOSOBU WIĘCEJ NIE UŻYWAMY!
        info[1] = players[i];
        info[2] = get_user_userid(players[i]); */
        menu_additem(menu, name, info);
    }
    
    menu_display(id, menu);
}

public handle_przelew(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }
    
    new info[25], access, callback;
    menu_item_getinfo(menu, item, access, info, 24,_, _, callback);
    new tid = hexstr_to_num(info[8], 8); // zaczynamy od 8 znaku i pobieramy 8 z nich, konwertując je z hex na liczbę
    new tuserid = hexstr_to_num(info[16], 8);
    new wartosc = hexstr_to_num(info, 8);
    if(is_user_connected(tid) && tuserid == get_user_userid(tid))
        przelej_kase(id, tid, wartosc);

    menu_destroy(menu);
    return PLUGIN_HANDLED;
}
hexstr_to_num(string[], chars) {
    new result=0;
    for(new i=0; i<chars && string[i]!='^0'; ++i)
        result = result<<4 + (string[i]>'9'?string[i]>'F'?string[i]-'a'+10:string[i]-'A'+10:string[i]-'0');
        return result;
    }
}

Jak widać potrzebne wartości, czyli id gracza i wartość kasy do przelania. Ale co? Przecież to nie jest napis, tylko tablica... A kto powiedział albo gdzieś napisał, że info musi być napisem? Może być tablicą, wszak napis też jest tablicą, tyle że specyficznie interpretowaną więc zastosowanie jak najbardziej prawidłowe. (Znów aktualizacja! Ostatnio odkryłem, że niestety gdy funkcja napotka wartość 0, przerywa całkowicie wczytywanie dalszych wartości! Musimy więc przerobić liczbę na string!) Utworzyłem prosty string z 3 wartości liczbowych w postaci heksadecymalnej. Użyłem dość dziwnej konstrukcji %08F, zapewnia to wypełnienie zerami z przodu tak, aby liczba zawsze zajmowała 8 znaków. Dlaczego każda ma liczba każda w AMX ma 32 bity, jedna cyfra HEX może zapisać 4, dalej chyba już jasne Stworzyłem również funkcję konwertującą string hexadecymalny na liczbę, aby wydobyć ze stringa spowrotem wartości. Dlaczego użyłem HEX? Prościej jest konwertować to na liczbę i zajmuje stałą ilość znaków Teraz już nie martwimy się, że jakiś gracz ucieknie z serwera (no chyba, że ucieka nam gracz, do którego chcemy przelać kasę... ale wtedy po prostu kasa się nie przeleje, chyba że ktoś na miejsce wychodzącego gracza akurat wejdzie, na taki przypadek można zrobić weryfikację nicku lub sid jeszcze) (aktualizowałem kod pluginu zgodnie z sugestią użytkownika sebul) i mamy elegancko zrobione menu Jednocześnie zbędna stała się globalna tablica gWartosci, gdyż wartość kasy przesyłamy w tym samym info, co id gracza.
Mam nadzieję, że przykład ten jasno ilustruje do czego info w nowych menu powinno być używane.


3. Menu statyczne wyboru serwera, przykład nieco gorszy

Teraz jeszcze jeden przykład uzasadnionego użycia info, mimo menu statycznego. Oczywiście na początek ten... może tym razem po prostu gorszy, bo jak najbardziej poprawny przykład, menu serwerów:

public show_serwery(id) {
    new menu = menu_create("Wybierz serwer na który chcesz przejść", "handle_serwery");
    
    menu_additem(menu, "Serwer GunGame");
    menu_additem(menu, "Serwer FFA");
    menu_additem(menu, "Serwer Diablo");
    
    menu_display(id, menu);
}

public handle_serwery(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }

    switch(item) {
        case 0: client_cmd(id, "Connect 23.123.33.22:27033");
        case 1: client_cmd(id, "Connect 12.34.56.78:27090");
        case 2: client_cmd(id, "Connect 98.76.54.32:27010");
    }

    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

Dlaczego przykład jest gorszy? trudniejszy w edycji, musimy w 2ch miejscach zmieniać, gdy chcemy zmienić listę serwerów.


ad 3. Menu wyboru serwera, przykład lepszy, wygodniejszy

Mimo, że poprawny jest, przedstawiam wariant wygodniejszy:

public show_serwery(id) {
    new menu = menu_create("Wybierz serwer na który chcesz przejść", "handle_serwery");
    
    menu_additem(menu, "Serwer GunGame", "23.123.33.22:27033");
    menu_additem(menu, "Serwer FFA", "12.34.56.78:27090");
    menu_additem(menu, "Serwer Diablo", "98.76.54.32:27010");
    
    menu_display(id, menu);
}

public handle_serwery(id, menu, item) {
    if(item == MENU_EXIT) {
        menu_destroy(menu);
        return PLUGIN_HANDLED;
    }

    new ip[32], access, callback;
    menu_item_getinfo(menu, item, access, ip, 31,_, _, callback);
    client_cmd(id, "Connect %s", ip);
    
    menu_destroy(menu);
    return PLUGIN_HANDLED;
}

W ten oto sposób mamy dużo wygodniejsze dodawanie i edycję listy serwerów, bo dla każdego serwera jest to jedna, przejrzysta linia. Dodatkowo drobną modyfikacją można uzyskać listę serwerów odczytywaną z pliku, nvaulta albo bazy SQL, wstawiając odpowiednią pętlę zamiast additem, oraz dodając obsługę jednego z wymienionych. Tutaj, mimo menu statycznego, mamy w pełni uzasadnione użycie info do determinowania akcji podejmowanej przez menu


I na koniec obiecany bonus

Jak wiecie, dzięki starym menu można tworzyć coś, co przypomina, albo i nie przypomina menu, np wyświetlić regulamin na kilkanaście linii i pod nim dać możliwość jego akceptacji. Na nowym menu można dokładnie to samo, wymaga to jednak tricków kilku.

O ile nie ma żadnych problemów, gdy np. chcemy wstawić po każdej opcji w menu linijkę opisującą, albo gdy wszystkie opcje w menu mają być na samej górze, a dodatkowy tekst na dole, gdyż jest coś takiego jak menu_addblank i menu_addtext. Nie możemy ich jednak użyć przed użyciem choć raz menu_additem (nie wiem dlaczego tak twórcy amx głupio zrobili, ale tak zrobili). Jednak jest możliwość ominięcia tego niuansu przez ustawienie potrzebnych nam rzeczy w wielolinijkowym tytule. Tu następne ograniczenie: ustawienie tytułu poprzez menu_create posiada dosyć rygorystyczny limit znaków, musimy więc ustawić to poprzez menu_setprop(menu, MPROP_TITLE, ...) czyli np coś takiego:

    menu = menu_create("Regulamin serwera", "handler");
    menu_setprop(menu, MPROP_TITLE, "Regulamin serwera \yGunGame^n^nNa serwerze obowiązuje\rABSOLUTNY\yzakaz przeklinania^nNie wolno bugować mapy...");

    menu_additem(menu, "Akceptuję regulamin");
    menu_additem(menu, "Nie akceptuję regulaminu");
    menu_addtext(menu, " Nie zaakceptowanie regulaminu wiąże się z 5 minutowym banem");
    menu_setprop(menu, MPROP_EXIT, MEXIT_NEVER);

I w taki sposób uzyskujemy ładny, czytelny regulamin, na nowych menu, z możliwością akceptacji Prawda, że proste

Dziękuję za dotrwanie do końca

Copyright © Wszelkie prawa zastrzeżone
Kopiowanie tego poradnika lub treści w nim zawartych bez wyraźnej zgody autora jest zabronione i będzie ścigane z mocy prawa