Forum
Użytkownicy
Kalendarz
Dodatki SourceMod
Moja zawartość
Mężczyzna
mp_fadetoblack 0 mp_forcecamera 0 mp_forcechasecam 1ustaw tak
- 1
Witamy w Nieoficjalnym polskim support'cie AMX Mod X
Witamy w Nieoficjalnym polskim support'cie AMX Mod X, jak w większości społeczności internetowych musisz się zarejestrować aby móc odpowiadać lub zakładać nowe tematy, ale nie bój się to jest prosty proces w którym wymagamy minimalnych informacji.
|
Guest Message by DevFuse
K1noS
Rejestracja: 06.03.2012Aktualnie: Nieaktywny
Poza forum Ostatnio: 13.02.2015 10:02
#636962 Podczas smierci widze tylko 1 druzyne
Napisane przez
w 06.05.2014 17:12
#634184 Nie mogę zrobić ssów
Napisane przez
w 23.04.2014 09:59
dopisz do plugins.ini amxbans_ssban.amxx
#367889 [ROZWIĄZANE] Jak dodać sam obrazek do motd.txt
Napisane przez
w 20.02.2012 15:46
<body style="background:url(adres obrazka); background-repeat:no-repeat;"></body>
lub
<img src="adres obrazka" alt="" />
- 3
#477125 Informacje wstępne, czyli Jak zacząć Scripting AMXX
Napisane przez
Gość
w 09.11.2012 19:47
Tutorial dla początkujących
Informacje wstępne
Scripting AMXX
[kotwica='cel']Cel[/kotwica]
Nauka tworzenia pluginów AMXX
Wymagania
Na samym początku zadajmy sobie pytanie: czym są pluginy AMXX i jak działają.
Pluginy AMXX to algorytmy modyfikacji rozgrywki na serwerach HLDS, pisane w języku Pawn,
zrozumiałym dla ludzi i zapisywane pod postacią plików SMA, które w wyniku kompilacji przybierają
postać kodu niezrozumiałego dla człowieka, ale zrozumiałego dla AMXX, zapisywane pod postacią
plików AMXX, które komunikują się z serwerem HLDS poprzez Metamoda:P, zmieniając rozgrywkę.
[kotwica='istota']Istota[/kotwica]
Tym samym, plugin komunikuje się z Metamodem:P, a Metamod:P z silnikiem gry (serwerem HLDS).
Musimy pamiętać, że każda wymiana informacji pomiędzy serwerem a silnikiem gry, zużywa liczne
zasoby sprzętowe i należy zadawać możliwie jak najmniej zapytań do silnika gry poprzez Metamoda:P.
[kotwica='plugins_ini']Plugins.ini[/kotwica]
Plik plugins.ini zawiera listę pluginów, które zostaną załadowane do AMXX i będą wykonywać swoje
algorytmy, komunikując się z serwerem HLDS poprzez MetaModa:P, modyfikując przebieg gry.
Jednak kolejność pluginów wpisanych w pliku plugins.ini nie jest bez znaczenia.
Zwróćmy teraz uwagę na sposób działania AMXX, czyli interakcję z serwerem gry.
AMXX pozwala nam, poprzez MetaModa:P, na następujące operacje:
Należy zatem zwracać uwagę na kolejność pluginów w pliku plugins.ini, przy czym algorytmy
kolejnych pluginów, od góry pliku plugins.ini, wykonywane są proporcjonalnie sekwencyjnie.
Przykładowo, jeśli w pluginie pierwszym od góry pliku plugins.ini, zablokujemy możliwość mówienia,
to w pluginie drugim od góry, nie zostanie zarejestrowane powiedzenie na sayu określonej wartości.
W odwrotnej kolejności tych pluginów w pliku plugins.ini zaś, będzie to z kolei możliwe do wykonania.
[kotwica='AMXMODX']AMXMODX[/kotwica]
Pierwszą, podstawową biblioteką, jaką będziemy musieli załączyć do naszego pluginu, jest AMXMODX.
W tym celu, dodajemy na samej górze naszego kodu SMA następującą linijkę kodu
AMXX posiada parę publicznych, predefiniowanych funkcji, a oto one:
[kotwica='plugin_natives']plugin_natives[/kotwica]
Ta funkcja wywoływana jest jako pierwsza, tuż po załadowaniu pluginu do pamięci AMXX.
W niej należy zainicjować wszelkie natywy do współpracy z innymi pluginami, czyli sprawić,
by możliwa była kompleksowa komunikacja pomiędzy funkcjami poszczególnych pluginów.
Jak już pisałem, funkcje ładowane są kolejno, od góry pliku plugins.ini, tak więc kolejność jest istotna.
[kotwica='plugin_precache']plugin_precache[/kotwica]
Ta funkcja wywoływana jest po załadowaniu wszytkich pluinów z natywami, lecz jeszcze przed pełnym zainicjowaniem
serwera HLDS i to w niej należy zarejestrować wszelkie wymagane do pobrania przez Użytkowników pliki niestandardowe,
z których będzie korzystał plugin, by powiadomić klienta gry o konieczności pobrania tych plików przed ustaleniem połączenia.
W tej właśnie funkcji należy zarejestrować wszelkie modyfikatory skryptów startowych serwera HLDS, by móc
w nie ingerować, zanim zostaną załadowane i wykonane skrypty startowe, uniemożliwiając ich identyfikację.
[kotwica='plugin_init']plugin_init[/kotwica]
Ta funkcja wywoływana jest podczas inicjalizacji pluginu, po pełnym załadowaniu funkcji startowych serwera.
W tej funkcji należy zarejestrować nasz plugin przy użyciu funkcji register_plugin o następujących parametrach
Warto zidentyfikować plugin w celu późniejszego testowania stanu pluginu i odnalezienia go na liście pluginów.
Składnia argumentów funkcji nie wymaga chyba większego komentarza, w przypadku wątpliwości zapraszam do manuala.
[kotwica='przyklad']Przykład[/kotwica]
Na tym etapie, potrafimy już stworzyć i zarejestrować pierwszy plugin, nie robiący praktycznie nic.
W trzeciej linijce zainicjowaliśmy publiczną funkcję plugin_init, wykonywaną po pełnym załadowaniu skryptów startowych HLDS.
Przypominam, że funkcja plugin_init winna być funkcją publiczną, inaczej może nie zostać ona wykonana w oczekiwanym momencie.
W czwartej linijce, rejestruję plugin i na tym kończy się działanie naszego testowego pluginu, który praktycznie nie zmienia rozgrywki.
W funkcji plugin_init należy także zarejestrować wszelkie nasłuchiwacze zdarzeń, jak śmierć gracza, czy nowa runda.
[kotwica='plugin_cfg']plugin_cfg[/kotwica]
Ta funkcja wywoływana jest tuż po plugin_init i służy konfiguracji pluginu, m.in. pobraniu zmiennych globalnych z silnika gry,
ustanowieniu połączenia z bazą danych, czy pobrania innych, istotnych danych do współpracy pluginu z zasobami zewnętrznymi.
[kotwica='register_event']register_event[/kotwica]
Pierwsza z funkcji, którą poznamy, pozwala na przechwycenie wybranych zdarzeń, które dokonywane są na serwerze.
Tutaj odwołuję do niezwykle istotnej strony, na której wypisane są zdarzenia silnika HLDS wraz z argumentami:
Half-Life 1 Game Events
Teraz spróbujemy przechwycić funkcję śmierci, w tym celu musimy zarejestrować w funkcji plugin_init nasłuchiwacz tego zdarzenia
Drugi parametr oznacza funkcję publiczną, która będzie wywoływana w momencie wystąpienia tego zdarzenia. Trzeci parametr
wynosi "a", gdyż DeathMsg jest eventem globalnym. Tym samym utworzymy sobie funkcję publiczną DeathMsg i damy zabójcy 200$.
[kotwica='read_data']read_data[/kotwica]
Jak możemy wyczytać z powyższego linku, DeathMsg posiada cztery argumenty. Nam wystarczy pierwszy argument, czyli id zabójcy.
Za pomocą funkcji read_data
możemy odczytać dany parametr funkcji, ponieważ pierwszy argument
to numer identyfikacyjny zabójcy, ten właśnie numer pobierzemy i zapiszemy do nowo utworzonej zmiennej killer.
Teraz będziemy chcieli nagrodzić zabójcę, przekazując mu dodatkowe 200 dolarów za zabójstwo.
W tym celu, skorzystamy z funkcji z biblioteki cstrike, cs_set_user_money.
[kotwica='import_biblioteki']Import biblioteki[/kotwica]
Aby móc skorzystać z tej funkcji, musimy najpierw zaimportować kolejną bibliotekę,
w tym celu dodajemy do naszego kodu następującą linijkę (najlepiej pod bilioteką amxmodx)
[kotwica='sprawdzenie_obecnosci_gracza']Sprawdzenie obecności gracza[/kotwica]
Teraz dochodzimy do niezwykle istotnej rzeczy, którą musisz zapamiętać raz na zawsze!
Operując na jakimkolwiek graczu, upewnij się, że gracz może zostać danej operacji poddany.
W przykładzie, chcemy dodać pieniądze graczowi, jednak zanim to zrobimy, musimy się upewnić,
czy gracz jest jeszcze na naszym serwerze. Zawsze mógł rzucić granat, wyjść z serwera, a opiero po chwili
nastąpi zdarzenie śmierci. Co się stanie przy próbie dodania pieniędzy graczowi, którego nie ma na serwerze?
Na pewno jest to niepotrzebne zapytanie do silnika gry, dużo większe zużycie zasobów sprzętowych, a także stale
powiększające się logi błędów. Na dłuższą metę, takie właśnie błędy skutkują dużymi lagami bądź crashami serwera.
Tym samym, użyjemy funkcji is_user_connected, w celu sprawdzenia, czy gracz jest jeszcze na serwerze.
Pamiętajmy, że aktualnie killer reprezentuje numer identyfikacyjny zabójcy, jednak w różnych funkcjach, możemy różnie
identyfikować poszczególne byty czy zdarzenia. Przy okazji, każdy byt na mapie ma swój własny, unikalny numer identyfikacyjny,
jednakże numerem identyfikacyjnym gracza jest numer z zakresu od 1 do maksymalnej liczby graczy włącznie. Tym samym, numer
bytu, będący większy lub równy 1 i nie większy, niż maksymalna liczba graczy na serwerze, oznacza na pewno gracza. (niekoniecznie online!)
Jak można zauważyć, nie mamy wprost funkcji dodającej pieniądze. W związku z tym,
musimy jako drugi parametr funkcji cs_set_user_money podać sumę 200
i obecnej liczby dolarów gracza, pobieranej przy użyciu funkcji cs_get_user_money
[kotwica='zwracana_wartosc']Zwracana wartość[/kotwica]
W nowo utworzonej funkcji DeathMsg, zwrócimy na końcu odpowiednią wartość.
Dostępne wartości do zwrócenia:
PLUGIN_CONTINUE
Domyślna wartość, przerywająca dalsze wywołanie funkcji, jednak przez każdy inny plugin, a także silnik gry,
zdarzenie zostanie wywołane. Po prostu nic niżej od tego polecenia nie zostanie wywołane w tej danej jednej funkcji.
PLUGIN_HANDLED_MAIN
Dalsze wywołanie funkcji nie będzie możliwe, podobnie, jak w przypadku PLUGIN_CONTINUE, dalej wszystkie
pluginy będą mogły odnotować tę funkcję, jednak event ten zostanie zablokowany dla silnika właściwego gry.
PLUGIN_HANDLED
Dalsze wywoływanie funkcji zostanie przerwane, a ani silnik gry nie odnotuje tego eventu, ani, w przeciwieństwie
do PLUGIN_HANDLED_MAIN, żaden z kolejnych pluginów, wypisanych poniżej od tego obecnego w plugins.ini.
Nam wystarczy PLUGIN_CONTINUE, bowiem nie chcemy blokować śmierci w silniku, ani pozbawiać informacji o śmierci
kolejnych pluginów. Na koniec zmienimy nazwę pluginu na odzwierciedlającą rzeczywiste zastosowanie pluginu. Gotowy kod:
Tym samym, właśnie napisaliśmy swój pierwszy plugin, który daje dodatkowe 200 dolarów za zabójstwo.
Tutorial napisany, choć z drobnym opóźnieniem, z okazji Światowego Dnia Jakości.
Jeśli przypadnie on Wam do gustu, to mogę pokusić się w wolnym czasie o napisanie kolejnych
części, jako kontynuację, z rozwinięciem wątku i coraz bardziej zaawansowanymi przykładami Scriptingu.
Informacje wstępne
Scripting AMXX
[kotwica='cel']Cel[/kotwica]
Nauka tworzenia pluginów AMXX
Wymagania
- Znajomość obsługi AMXX
- Umiejętność programowania
- Podstawowa znajomość Pawna
- Racjonalne tworzenie algorytmów
- Umiejętność korzystania z manuala
- Edytor Pawna wraz z kompilatorem AMXX
Na samym początku zadajmy sobie pytanie: czym są pluginy AMXX i jak działają.
Pluginy AMXX to algorytmy modyfikacji rozgrywki na serwerach HLDS, pisane w języku Pawn,
zrozumiałym dla ludzi i zapisywane pod postacią plików SMA, które w wyniku kompilacji przybierają
postać kodu niezrozumiałego dla człowieka, ale zrozumiałego dla AMXX, zapisywane pod postacią
plików AMXX, które komunikują się z serwerem HLDS poprzez Metamoda:P, zmieniając rozgrywkę.
[kotwica='istota']Istota[/kotwica]
Tym samym, plugin komunikuje się z Metamodem:P, a Metamod:P z silnikiem gry (serwerem HLDS).
Musimy pamiętać, że każda wymiana informacji pomiędzy serwerem a silnikiem gry, zużywa liczne
zasoby sprzętowe i należy zadawać możliwie jak najmniej zapytań do silnika gry poprzez Metamoda:P.
[kotwica='plugins_ini']Plugins.ini[/kotwica]
Plik plugins.ini zawiera listę pluginów, które zostaną załadowane do AMXX i będą wykonywać swoje
algorytmy, komunikując się z serwerem HLDS poprzez MetaModa:P, modyfikując przebieg gry.
Jednak kolejność pluginów wpisanych w pliku plugins.ini nie jest bez znaczenia.
Zwróćmy teraz uwagę na sposób działania AMXX, czyli interakcję z serwerem gry.
AMXX pozwala nam, poprzez MetaModa:P, na następujące operacje:
- Zarejestrowanie danego zdarzenia czy wartości (np. odczytanie liczby pieniędzy danego gracza, czy zaobserwowanie wybuchu bomby)
- Modyfikowanie danego zdarzenia czy wartości (np. zmiana punktów życia danego gracza, czy przedłużenia czasu trwania oślepienia)
- Zablokowanie danego zdarzenia czy usunięcie wartości (np. brak obrażeń od granatów, czy usunięcie limitu posiadanych dolarów)
- Wywołanie danego zdarzenia (np. zabicie gracz, teleportacja gracza na respawn wrogów, czy pozbawienie gracza jego broni)
- Tworzenie danego zdarzenia czy wartości (np. zabicie vipa lub ucieczka terrorystów, czy stworzenie nowych cvarów)
Należy zatem zwracać uwagę na kolejność pluginów w pliku plugins.ini, przy czym algorytmy
kolejnych pluginów, od góry pliku plugins.ini, wykonywane są proporcjonalnie sekwencyjnie.
Przykładowo, jeśli w pluginie pierwszym od góry pliku plugins.ini, zablokujemy możliwość mówienia,
to w pluginie drugim od góry, nie zostanie zarejestrowane powiedzenie na sayu określonej wartości.
W odwrotnej kolejności tych pluginów w pliku plugins.ini zaś, będzie to z kolei możliwe do wykonania.
[kotwica='AMXMODX']AMXMODX[/kotwica]
Pierwszą, podstawową biblioteką, jaką będziemy musieli załączyć do naszego pluginu, jest AMXMODX.
W tym celu, dodajemy na samej górze naszego kodu SMA następującą linijkę kodu
#include <amxmodx>
AMXX posiada parę publicznych, predefiniowanych funkcji, a oto one:
[kotwica='plugin_natives']plugin_natives[/kotwica]
Ta funkcja wywoływana jest jako pierwsza, tuż po załadowaniu pluginu do pamięci AMXX.
W niej należy zainicjować wszelkie natywy do współpracy z innymi pluginami, czyli sprawić,
by możliwa była kompleksowa komunikacja pomiędzy funkcjami poszczególnych pluginów.
Jak już pisałem, funkcje ładowane są kolejno, od góry pliku plugins.ini, tak więc kolejność jest istotna.
[kotwica='plugin_precache']plugin_precache[/kotwica]
Ta funkcja wywoływana jest po załadowaniu wszytkich pluinów z natywami, lecz jeszcze przed pełnym zainicjowaniem
serwera HLDS i to w niej należy zarejestrować wszelkie wymagane do pobrania przez Użytkowników pliki niestandardowe,
z których będzie korzystał plugin, by powiadomić klienta gry o konieczności pobrania tych plików przed ustaleniem połączenia.
W tej właśnie funkcji należy zarejestrować wszelkie modyfikatory skryptów startowych serwera HLDS, by móc
w nie ingerować, zanim zostaną załadowane i wykonane skrypty startowe, uniemożliwiając ich identyfikację.
[kotwica='plugin_init']plugin_init[/kotwica]
Ta funkcja wywoływana jest podczas inicjalizacji pluginu, po pełnym załadowaniu funkcji startowych serwera.
W tej funkcji należy zarejestrować nasz plugin przy użyciu funkcji register_plugin o następujących parametrach
register_plugin(const plugin_name[], const version[], const author[])
Warto zidentyfikować plugin w celu późniejszego testowania stanu pluginu i odnalezienia go na liście pluginów.
Składnia argumentów funkcji nie wymaga chyba większego komentarza, w przypadku wątpliwości zapraszam do manuala.
[kotwica='przyklad']Przykład[/kotwica]
Na tym etapie, potrafimy już stworzyć i zarejestrować pierwszy plugin, nie robiący praktycznie nic.
#include <amxmodx>Przypomnijmy, w pierwszej linijce zaimportowaliśmy wymaganą zawsze dla AMXX, bibliotekę amxmodx.
public plugin_init(){
register_plugin("Nauka AMXX", "0.1", "benio101");
}
W trzeciej linijce zainicjowaliśmy publiczną funkcję plugin_init, wykonywaną po pełnym załadowaniu skryptów startowych HLDS.
Przypominam, że funkcja plugin_init winna być funkcją publiczną, inaczej może nie zostać ona wykonana w oczekiwanym momencie.
W czwartej linijce, rejestruję plugin i na tym kończy się działanie naszego testowego pluginu, który praktycznie nie zmienia rozgrywki.
W funkcji plugin_init należy także zarejestrować wszelkie nasłuchiwacze zdarzeń, jak śmierć gracza, czy nowa runda.
[kotwica='plugin_cfg']plugin_cfg[/kotwica]
Ta funkcja wywoływana jest tuż po plugin_init i służy konfiguracji pluginu, m.in. pobraniu zmiennych globalnych z silnika gry,
ustanowieniu połączenia z bazą danych, czy pobrania innych, istotnych danych do współpracy pluginu z zasobami zewnętrznymi.
[kotwica='register_event']register_event[/kotwica]
Pierwsza z funkcji, którą poznamy, pozwala na przechwycenie wybranych zdarzeń, które dokonywane są na serwerze.
Tutaj odwołuję do niezwykle istotnej strony, na której wypisane są zdarzenia silnika HLDS wraz z argumentami:
Half-Life 1 Game Events
Teraz spróbujemy przechwycić funkcję śmierci, w tym celu musimy zarejestrować w funkcji plugin_init nasłuchiwacz tego zdarzenia
register_event("DeathMsg", "DeathMsg", "a");
Pierwszy parametr, zgodnie z dokumentacją, oznacza nazwę zdarzenia.Drugi parametr oznacza funkcję publiczną, która będzie wywoływana w momencie wystąpienia tego zdarzenia. Trzeci parametr
wynosi "a", gdyż DeathMsg jest eventem globalnym. Tym samym utworzymy sobie funkcję publiczną DeathMsg i damy zabójcy 200$.
[kotwica='read_data']read_data[/kotwica]
Jak możemy wyczytać z powyższego linku, DeathMsg posiada cztery argumenty. Nam wystarczy pierwszy argument, czyli id zabójcy.
public DeathMsg(){
new killer=read_data(1);
}Funkcja DeathMsg wywoływana jest w momencie wystąpienia zdarzenia śmierci.Za pomocą funkcji read_data
możemy odczytać dany parametr funkcji, ponieważ pierwszy argumentto numer identyfikacyjny zabójcy, ten właśnie numer pobierzemy i zapiszemy do nowo utworzonej zmiennej killer.
Teraz będziemy chcieli nagrodzić zabójcę, przekazując mu dodatkowe 200 dolarów za zabójstwo.
W tym celu, skorzystamy z funkcji z biblioteki cstrike, cs_set_user_money
.[kotwica='import_biblioteki']Import biblioteki[/kotwica]
Aby móc skorzystać z tej funkcji, musimy najpierw zaimportować kolejną bibliotekę,
w tym celu dodajemy do naszego kodu następującą linijkę (najlepiej pod bilioteką amxmodx)
#include <cstrike>Przypomnijmy, jak powinien wyglądać nasz obecny, pełny kod:
#include <amxmodx>
#include <cstrike>
public plugin_init(){
register_plugin("Nauka AMXX", "0.1", "benio101");
register_event("DeathMsg", "DeathMsg", "a");
}
public DeathMsg(){
new killer=read_data(1);
}
[kotwica='sprawdzenie_obecnosci_gracza']Sprawdzenie obecności gracza[/kotwica]
Teraz dochodzimy do niezwykle istotnej rzeczy, którą musisz zapamiętać raz na zawsze!
Operując na jakimkolwiek graczu, upewnij się, że gracz może zostać danej operacji poddany.
W przykładzie, chcemy dodać pieniądze graczowi, jednak zanim to zrobimy, musimy się upewnić,
czy gracz jest jeszcze na naszym serwerze. Zawsze mógł rzucić granat, wyjść z serwera, a opiero po chwili
nastąpi zdarzenie śmierci. Co się stanie przy próbie dodania pieniędzy graczowi, którego nie ma na serwerze?
Na pewno jest to niepotrzebne zapytanie do silnika gry, dużo większe zużycie zasobów sprzętowych, a także stale
powiększające się logi błędów. Na dłuższą metę, takie właśnie błędy skutkują dużymi lagami bądź crashami serwera.
Tym samym, użyjemy funkcji is_user_connected
, w celu sprawdzenia, czy gracz jest jeszcze na serwerze.Pamiętajmy, że aktualnie killer reprezentuje numer identyfikacyjny zabójcy, jednak w różnych funkcjach, możemy różnie
identyfikować poszczególne byty czy zdarzenia. Przy okazji, każdy byt na mapie ma swój własny, unikalny numer identyfikacyjny,
jednakże numerem identyfikacyjnym gracza jest numer z zakresu od 1 do maksymalnej liczby graczy włącznie. Tym samym, numer
bytu, będący większy lub równy 1 i nie większy, niż maksymalna liczba graczy na serwerze, oznacza na pewno gracza. (niekoniecznie online!)
public DeathMsg(){
new killer=read_data(1);
if(is_user_connected(killer)){
// Dodawanie pieniedzy
}
}
Teraz skorzystamy z natywów biblioteki cstrike i dodamy zabójcy 200 dolarów.cs_set_user_money(killer, cs_get_user_money(killer) + 200);
Jak można zauważyć, nie mamy wprost funkcji dodającej pieniądze. W związku z tym,
musimy jako drugi parametr funkcji cs_set_user_money
podać sumę 200i obecnej liczby dolarów gracza, pobieranej przy użyciu funkcji cs_get_user_money
[kotwica='zwracana_wartosc']Zwracana wartość[/kotwica]
W nowo utworzonej funkcji DeathMsg, zwrócimy na końcu odpowiednią wartość.
Dostępne wartości do zwrócenia:
PLUGIN_CONTINUE
Domyślna wartość, przerywająca dalsze wywołanie funkcji, jednak przez każdy inny plugin, a także silnik gry,
zdarzenie zostanie wywołane. Po prostu nic niżej od tego polecenia nie zostanie wywołane w tej danej jednej funkcji.
PLUGIN_HANDLED_MAIN
Dalsze wywołanie funkcji nie będzie możliwe, podobnie, jak w przypadku PLUGIN_CONTINUE, dalej wszystkie
pluginy będą mogły odnotować tę funkcję, jednak event ten zostanie zablokowany dla silnika właściwego gry.
PLUGIN_HANDLED
Dalsze wywoływanie funkcji zostanie przerwane, a ani silnik gry nie odnotuje tego eventu, ani, w przeciwieństwie
do PLUGIN_HANDLED_MAIN, żaden z kolejnych pluginów, wypisanych poniżej od tego obecnego w plugins.ini.
Nam wystarczy PLUGIN_CONTINUE, bowiem nie chcemy blokować śmierci w silniku, ani pozbawiać informacji o śmierci
kolejnych pluginów. Na koniec zmienimy nazwę pluginu na odzwierciedlającą rzeczywiste zastosowanie pluginu. Gotowy kod:
#include <amxmodx>
#include <cstrike>
public plugin_init(){
register_plugin("Dodatkowe 200 dolarow za zabojstwo", "0.1", "benio101");
register_event("DeathMsg", "DeathMsg", "a");
}
public DeathMsg(){
new killer=read_data(1);
if(is_user_connected(killer)){
cs_set_user_money(killer, cs_get_user_money(killer) + 200);
}
return PLUGIN_CONTINUE;
}
Tym samym, właśnie napisaliśmy swój pierwszy plugin, który daje dodatkowe 200 dolarów za zabójstwo.
Tutorial napisany, choć z drobnym opóźnieniem, z okazji Światowego Dnia Jakości.
Jeśli przypadnie on Wam do gustu, to mogę pokusić się w wolnym czasie o napisanie kolejnych
części, jako kontynuację, z rozwinięciem wątku i coraz bardziej zaawansowanymi przykładami Scriptingu.
#280544 Autoresponder/Advertiser - advanced version
Napisane przez
w 09.08.2011 23:27
Plugin co jakiś czas (ustawiany cvarami) wyświetla na chacie różne reklamy, informacje, itp. Jest to przeróbka istniejącego już pluginu, ale ta wersja przepisana jest na nowo, działa na dynamicznej tablicy array (dlatego też kod jest dużo krótszy) oraz ma więcej opcji. Reklamy można ustawić tak, aby wyświetlały się one na konkretnych mapach, mapach z określonym prefixem (np. de, cs, itp.), od określonej ilości graczy (znajdujących się na serwerze), do określonej ilości graczy, czy też w określonych godzinach. Opcje te można ze sobą łączyć, np. "na y mapie" z "od x ilości graczy", "na mapie o prefixie y" z "do x ilości graczy" oraz "od x do y godziny", itp. Nie zalecane jest łączenie ze sobą opcji "na y mapie" z "na mapie o prefixie y" oraz "od x ilości graczy" z "do x ilości graczy".
Reklamy można "kolorować" poprzez tagi ([normal], [team], [green]) oraz został dodany tag ([.you]), dzięki któremu możemy w reklamie wyświetlić nick gracza oglądającego reklamę.
Przykładowe reklamy znajdują się już w "advertisements.ini".
Spoiler
UWAGA!! 20.04.2013
Ważna aktualizacja pluginu, która eliminuje możliwość wyłączenia się serwera przy ustawieniu zbyt długiej wiadomości, do tego kod pluginu został "odświeżony".
ad_react_all "1" // 1 - pokazuj odpowiedź na dany tekst każdemu na serwerze, 0 - pokazuj tylko temu kto napisał ad_rand_min "40" // minimalny odstęp pomiędzy reklamami ad_rand_max "60" // maksymalny odstęp pomiędzy reklamami
Standardowa.
ad_manager_array.sma 9,45 KB 2414 Ilość pobrań
ad_manager_array.amxx
advertisements.ini 1,63 KB 5122 Ilość pobrań- 62
#215248 Easy End Round Sounds
Napisane przez
w 12.02.2011 21:59
Nowa wersja http://amxx.pl/topic...end-round-sound
Pewnie niektórzy powiedzą że jest już coś takiego a no jest 
czym wyróżnia się ten plugin ?
- Optymalny
- Opcja pokazywania playlisty
- Łatwość dodawania nowych utworów (żadnego dodawania do pliku .ini plugin sam to robi !)
- Cvary pozwalają naprawdę dużo zmienić
- Informacje dla graczy o granym utworze (4 sposoby wysyłania wiadomości można je łączyć
) - Obsluga wav i mp3 (moga byc pomieszane)
- Możliwość wyboru czy plugin ma iść po kolei czy losować grany utwór
piszcie co dodać/zmienić w pluginie
@Update
- Drobny bug
@Update2
- Naprawa drobnego bugu
- Dodanie możliwości wybrania kanałów wysyłania wiadomości o granym utworze
- Poprawki estetyczne
@Update 3
- Dodanie menu przy komendzie /roundsound
- Dodanie możliwości tworzenia playlisty przez usera (roundsound_playlist_on)
@Update 4
- Filtracja utwórów wcześniej wczytywało wszystko nie tylko pliki mp3/wav
@Update 5
- Nazwy plikow moga mieć w sobie spacje wczesniej nie mogly
@Update 6
- Naprawa bugów
@Update 7
- Drobne Zmiany
//tag widoczny przy komunikatach wysyłanych przez plugin roundsound_tag AMXX.PL //w jaki sposob ma wysylac informacje o granym utworze a - center b - hud c - status text mozna laczyc np ab - pokaże w hudzie i center jeśli podamy nic nie wyświetli sie nigdzie roundsound_information_play abc //jak czesto ma sie pojawiac info o dostepnych komendach ustawienie na 0 wyłącza pokazywanie informacji roundsound_information_show 300 //sciezka do folderu z muzyka dla CT podajemy bez sound/ wazna jest wielkosc liter roundsound_ct_path misc/CT //sciezka do folderu z muzyka dla TT podajemy bez sound/ wazna jest wielkosc liter roundsound_tt_path misc/TT // 0 - nie mozna uzyc komendy /playlista 1 - mozna plugin sam generuje playliste 2 - mozna admin musi stworzyc playliste (folder configs pliki ctplaylist.txt i ttplaylist.txt) roundsound_playlist_on 1 //czy mozna uzyc komendy /roundsound pozwalajace na graczowi na wylaczenie/wlaczenie dla siebie roundsounda roundsound_roundsound_on 1 //ma odgrywac utwory po kolei czy losowo 0 - po kolei 1 - losowo roundsound_mode 0
w czacie
/roundsound
i
/playlista
Dodawanie utworow do grania odbywa sie poprzez wrzucenie pliku do folderów do których podalismy sciezke w cvarach 
Jeśli chcemy wysyłać poprzez tutor musimy wrzucić pliki która są w archiwum tutor.rar 
(włączone wszystkie flagi tutor został usunięty)
sound.rar 2,27 MB 9563 Ilość pobrań
roundsound.sma 10,21 KB 9465 Ilość pobrań
roundsound.amxx
- 92
#514978 [ROZWIĄZANE] Say /cennik
Napisane przez
w 14.02.2013 15:02
Siema. Poszukuje pluginu który po wpisaniu w sayu /cennik pokazuje cennik wszystkiego co można kupic. I aby plik tekstowy będzie mozna edytowac.
#232956 Na deathrun`a staty i rank
Napisane przez
w 03.04.2011 18:39
Na deathrun`a staty i rank
v0.5
Pomysłodawca: hiroshima @ Deathrun Time Rank Stats - AMXX.pl: Support AMX Mod X
Liczy czas od spawna do zetknięcia z bytem końcowy. Wygląda on jakoś tak:
Najlepsze czasy graczy są zapisywane w bazie danych. Miejsca spawnu tego bytu końcowego określa admin komendą dr_finish (flaga CFG, chyba H). Pozycja jest zapisywana automatycznie.
Po przejściu mapy wyświetlane są różne czasy i międzyczasy, a byt zmienia kolor na zielony.
English translate of cvars:
Komendy gracza:
say /top15
say /rank
say /last
say /best
MySQL
amx_drstats_host "localhost"
amx_drstats_user "root"
amx_drstats_pass "root"
amx_drstats_db "drstats"
Reszta
amx_drstats_save 1|2|3
amx_drstats_timer 0|1|2
amx_drstats_timer_type 0|1
amx_drstats_draw_finish 0|1
amx_drstats_print_result 0|1|2
amx_drstats_chat_prefix "[Speedrun]"
prefix informacji na chat
amx_drstats_top15_page ""
jak tu wpiszesz adres strony www to będzie ona otwierana zamiast czytania top15 w pluginie
dopisuje do tego adresu
Wymagane pliki do kompilacji:
[INC] Director Hud Message - AlliedModders
Dokumentacja AMXX.pl: colorchat.inc
Załączam też jeszcze bardziej wydajną ramkę oraz barneya, bo nie mam modelu guzika.
Konwersja położeń ramki do barneya wymaga wykonania
Instalacja stat WWW:
Wrzuć zawartość DRStats-www.zip na serwer uzupełniając przedtem plik config.php danymi połączenia MySQL
menu.ini zawiera konfigurację poziomego menu
Zmiany:
0.5
- zapisywana data rekordu (tylko nowych)
- narodowość gracza + flagi na stronie
Uwaga: plugin jest kompatybilny wstecz, co oznacza, że przejście z 0.4 na 0.5 niczego nie zepsuje
0.4
- obsługa wielu języków
0.3.2
- opcjonalne wyświetlanie czasu w miejscu czasu rundy, ale kiepsko to wygląda
- załączam plik .amxx, żeby była mniejsza kompilacja
- aktualizacja statystyk na www: tablelk, menu.ini view może być http://link, buforowanie wyjścia
0.3.1
- bufixy:
- czas wyświetlał się po przejściu mapy z niestandardowym bytem końcowym
- top15 działało tylko z importem z www
0.3
- poprawiona ramka (wysyłana była zbyt często i do wszystkich)
- interfejs programistyczny, kilka forwardów i natyw: umożliwia podmianę bytu końcowego bez edycji głównego pluginu
0.2.1
- dodawanie do adresu strony z top15 id mapy
0.2
- nowy cvar: amx_drstats_draw_finish
- nowy cvar: amx_drstats_print_result
- nowy cvar: amx_drstats_chat_prefix
- nowy cvar: amx_drstats_top15_page
- poprawiony nieco wyglada Top15
- zapis pozycji bytu tylko jeśli został zmieniony (oznacza to zwykle 1 zapytanie na mapę mniej)
- drobne poprawki
0.1
- pierwsza publikacja
Jak dobrze pójdzie będzie też zapis SQLite jak ktoś nie ma bazy danych MySQL.
Restart statystyk można zrobić wykonując w bazie danych zapytanie:
v0.5
Pomysłodawca: hiroshima @ Deathrun Time Rank Stats - AMXX.pl: Support AMX Mod X
Liczy czas od spawna do zetknięcia z bytem końcowy. Wygląda on jakoś tak:
Najlepsze czasy graczy są zapisywane w bazie danych. Miejsca spawnu tego bytu końcowego określa admin komendą dr_finish (flaga CFG, chyba H). Pozycja jest zapisywana automatycznie.
Po przejściu mapy wyświetlane są różne czasy i międzyczasy, a byt zmienia kolor na zielony.
English translate of cvars:
Spoiler
Komendy gracza:
say /top15
- lista najlepszych
say /rank
- aktualna pozycja
say /last
- ostatni czas przejścia mapy
say /best
- najlepszy czas przejścia mapy (tego gracza, nie ogólny)
MySQL
amx_drstats_host "localhost"
amx_drstats_user "root"
amx_drstats_pass "root"
amx_drstats_db "drstats"
Reszta
amx_drstats_save 1|2|3
- 1 - zapis po steamid (domyślnie)
- 2 -zapis po nicku
- 3 - zapis po ip
amx_drstats_timer 0|1|2
- 0 - brak odliczania czasu biegu
- 1 - zawsze pokaż czas (domyślnie)
- 2 - tylko jak gracz trzyma TAB
amx_drstats_timer_type 0|1
- 0 - pokazuje czas w lewym dolnym rogu (domyślnie)
- 1 - tam gdzie czas rundy (nie polecam)
amx_drstats_draw_finish 0|1
- 0 - ukrywa byt koncowy (być może żeby postawić coś swojego w tym miejscu np. ModelPlacer`em)
- 1 - pokazuje byt koncowy (domyślnie)
amx_drstats_print_result 0|1|2
- 0 - brak informacji o wyniku biegu (czasy)
- 1 - pokazuje wynik na HUD+info w konsoli (domyślnie)
- 2 - pokazuje wynik na chacie
amx_drstats_chat_prefix "[Speedrun]"
prefix informacji na chat
amx_drstats_top15_page ""
jak tu wpiszesz adres strony www to będzie ona otwierana zamiast czytania top15 w pluginie
dopisuje do tego adresu
mid=ID_MAPYwięc adres powinien to uwzględniać, przykłady
index.php?
index.php?strona=staty&
domena/staty/
Wymagane pliki do kompilacji:
[INC] Director Hud Message - AlliedModders
Dokumentacja AMXX.pl: colorchat.inc
Załączam też jeszcze bardziej wydajną ramkę oraz barneya, bo nie mam modelu guzika.
Konwersja położeń ramki do barneya wymaga wykonania
UPDATE maps SET finishZ = finishZ-36 WHERE finishZ;
Instalacja stat WWW:
Wrzuć zawartość DRStats-www.zip na serwer uzupełniając przedtem plik config.php danymi połączenia MySQL
menu.ini zawiera konfigurację poziomego menu
Zmiany:
0.5
- zapisywana data rekordu (tylko nowych)
- narodowość gracza + flagi na stronie
Uwaga: plugin jest kompatybilny wstecz, co oznacza, że przejście z 0.4 na 0.5 niczego nie zepsuje
0.4
- obsługa wielu języków
0.3.2
- opcjonalne wyświetlanie czasu w miejscu czasu rundy, ale kiepsko to wygląda
- załączam plik .amxx, żeby była mniejsza kompilacja
- aktualizacja statystyk na www: tablelk, menu.ini view może być http://link, buforowanie wyjścia
0.3.1
- bufixy:
- czas wyświetlał się po przejściu mapy z niestandardowym bytem końcowym
- top15 działało tylko z importem z www
0.3
- poprawiona ramka (wysyłana była zbyt często i do wszystkich)
- interfejs programistyczny, kilka forwardów i natyw: umożliwia podmianę bytu końcowego bez edycji głównego pluginu
0.2.1
- dodawanie do adresu strony z top15 id mapy
0.2
- nowy cvar: amx_drstats_draw_finish
- nowy cvar: amx_drstats_print_result
- nowy cvar: amx_drstats_chat_prefix
- nowy cvar: amx_drstats_top15_page
- poprawiony nieco wyglada Top15
- zapis pozycji bytu tylko jeśli został zmieniony (oznacza to zwykle 1 zapytanie na mapę mniej)
- drobne poprawki
0.1
- pierwsza publikacja
Jak dobrze pójdzie będzie też zapis SQLite jak ktoś nie ma bazy danych MySQL.
Restart statystyk można zrobić wykonując w bazie danych zapytanie:
DELETE FROM results
Załączone pliki
-
DR Stats.zip 52,85 KB 6063 Ilość pobrań
-
dodatki.zip 3,9 KB 3950 Ilość pobrań
-
DRStats-www.zip 212,67 KB 4597 Ilość pobrań
- 47
#511978 Zabieranie TT broni
Napisane przez
w 07.02.2013 13:57
#include <amxmodx>
#include <hamsandwich>
#include <fun>
public plugin_init() {
register_plugin("TT bez broni runda", "1.0", "glut1997")
RegisterHam(Ham_Spawn, "player", "Odrodzenie", 1);
}
public Odrodzenie(id)
{
if(get_user_team(id) == 1)
{
strip_user_weapons(id)
}
}
- 1
#511938 Jak usunac muzyczki
Napisane przez
w 07.02.2013 10:34
z public poczatekrundy wywal
switch(get_user_team(id))
{
case 1: client_cmd(id, "spk QTM_CodMod/start2");
case 2: client_cmd(id, "spk QTM_CodMod/start");
}
- 1
#511258 Modele z Dragon Ball'a
Napisane przez
w 05.02.2013 18:03
Robię porządki na dysku 
Znalazłem model gracza.
Znalazłem model gracza.http://speedy.sh/CMzeb/gign.mdl
- 1
#511044 Szukam pluginu że na start dostajemy 35hp oraz tt nie ma noza
Napisane przez
w 05.02.2013 10:21
#511045 Szukam pluginu że na start dostajemy 35hp oraz tt nie ma noza
Napisane przez
Gość
w 05.02.2013 10:28
#include <amxmodx>
#include <cstrike>
#include <fun>
#define PLUGIN "Strip weapon and give HP"
#define VERSION "1.0"
#define AUTHOR "deLL"
public plugin_init() {
register_plugin(PLUGIN, VERSION, AUTHOR)
register_logevent("func_round",2,"1=Round_Start")
}
public func_round()
{
new iPlayers[32], iNum, id
get_players(iPlayers, iNum)
for(new i=0; i<iNum; i++)
{
id = iPlayers[i]
if(cs_get_user_team(id) == CS_TEAM_T)
{
strip_user_weapons(id)
}
set_user_health(id, 35)
}
}
#511113 Modele z Dragon Ball'a
Napisane przez
w 05.02.2013 13:26
Nie napisałeś jakich modeli poszukujesz. Mam tylko takie modele. Od razu mówię, że to nie są modele gracza.
http://speedy.sh/GVFuU/DragonBall.rar
- 4
#495376 [ROZWIĄZANE] komenda /klasy odpalajaca motd index.html
Napisane przez
w 29.12.2012 13:38
podaj adres swojej strony
#include <amxmodx>
#include <amxmisc>
#define PLUGIN "New Plug-In"
#define VERSION "1.0"
#define AUTHOR "AUTHOR"
public plugin_init() {
register_plugin(PLUGIN, VERSION, AUTHOR)
register_clcmd("say /klasy", "klasy")
}
public klasy(id)
{
show_motd(id, "<html>\
<head>\
<title>Title</title>\
<meta http-equiv=^"Content-Type^" content=^"text/html; charset=iso-8859-2^">\
</head>\
<frameset rows=^"100%,*^" frameborder=^"NO^" border=^"0^" framespacing=^"0^">\
<frame name=^"main_frame^" src=^"http://twojastrona.pl/index.html^">\
</frameset>\
</body>\
</html>","Klasy");
}
- 1
