Skocz do zawartości

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.
  • Rozpoczynaj nowe tematy i odpowiedaj na inne
  • Zapisz się do tematów i for, aby otrzymywać automatyczne uaktualnienia
  • Dodawaj wydarzenia do kalendarza społecznościowego
  • Stwórz swój własny profil i zdobywaj nowych znajomych
  • Zdobywaj nowe doświadczenia

Dołączona grafika Dołączona grafika

Guest Message by DevFuse
 

Pawlo^^ - zdjęcie

Pawlo^^

Rejestracja: 08.10.2010
Aktualnie: Nieaktywny
Poza forum Ostatnio: 11.03.2014 22:47
-----

#485254 "Zrozumieć Plugin."

Napisane przez dasiek w 30.11.2012 21:26

Na wstępnie - nie jestem jakiś pr0 - jednak chciałbym wam przybliżyć pisanie pluginów przez ten poradnik ponieważ żeby zacząć cokolwiek robić trzeba to zrozumieć ;)
Pragnę wam przedstawić mój sposób rozumienia pisania pluginów. Co prawda może być w nim wiele sprzeczności, nie dopowiedzeń i innych badziewów ale chcę uniknąć pisania regułek definicji i innych sformułowań których 98% z was (w tym i ja) nie zrozumie...

Zacznijmy stwierdzeniem ze plugin to 'opisany zestaw czynności' które serwer wykonuje. Nie jasne?
Wyobraźmy Sobie że człowiek to taki 'serwer' i ma ochotę na zupę chińską w 5 minut (który jest pluginem). Więc bierze opakowanie z zupką otwiera ją , wlewa do jakiegoś tam garnka z wodą miesza, gotuje, wlewa do miski , bierze łyżkę i je. Na opakowaniu mamy zestaw takowych instrukcji co mamy wykonać zeby zrobić zupkę - które człowiek rozumie. Tak samo nasz plugin - gdy chcemy np dać graczowi hp za zabójstwo musimy opisać w pluginie takowe dodawanie.

Do scriptingu nie wiele nam potrzeba. Wystarczy dowolne narzędzie do edycji plików tekstowych (tak jak nontatnik , notepad++ etc) otwieramy plik i piszemy. Jak wiadomo - plugin na serwer ma rozszerzenie amxx. Ale nasze kody mają rozszerzenie sma których serwer nie rozumie. Etap zmiany pliku sma na amxx to kompilacja (nie komplikacjia, konfrontacja, konwencja czy inne stwierdzenia z tego forum) czyli zamiana naszego pluginu na taką postać którą zrozumie nasz serwer. Odwołując się do przykładu wyżej. Zupa chińska jak sama nazwa wskazuje jest po chińsku i nie wszyscy rozumieją ten język. Więc ludzie z biedry (tu jako kompilator) przetłumaczyli instrukcje robienia takowej zupki tak żeby każdy polak ją zrozumiał.i Wuola.

Czas na trochę teori (tak tak, obiecałem że jej nie będzie ale cuż - niektórych rzeczy inaczej się wyjaśnić nie da) opisanej Łopatologicznie.
Na początku ważna rzecz. Nasz plugin (w innych językach programowania jest ta sama bajka) musi działać (to wiadomo), być jak najkrótszy (Plugin dłuższy nie oznacza że jest lepszy ale o optymalizacji Kodu powiem potem) i być jak najszybszy (i nie chodzi tu o to żeby zamiast czegoś na 5 sekund dawać na 3 - chodzi o szybkie działanie - To też przybliżę potem).

Patrząc na sam początek widzimy biblioteki. Są one zbiorem konkrenych funkcji z których będziemy korzystać aby nasz plugin działał tak jak chcemy. Bardzo Trudno mi to opisać więc odwołam się do naszego smakowitego przykładu - Zapakowana zupa chińska. Aby cokolwiek z nią zrobić trzeba ją najpierw otworzyć. Więc zaglądamy do szuflady i tam znajdujemy nożyczki. Bierzemy je i przecinamy opakowanie. Gdy chcemy wsypać jej zawartość szukamy naczynia, więc bierzemy miskę i do niej wsypujemy makaron z niej. Przydało by się wstawić gorącą wodę na nią i zalać miskę , więc bierzemy czajnik z kuchenki , podchodzimy do kranu, nalewamy wodę do niego i wstawiamy. W tym przykładzie Kolejno szuflada, Szafka z miskami, Kuchenka i Kran to biblioteki a w nich znajdują się konkretne rzeczy. Nie rozumiecie? Trochę wyobraźni. To teraz trzasnę kodzik do "przygotowania zupy" to co już tu opisałem :)

Uświadamiamy naszemu pseudo "serwerowi" żeby przygotował się na skorzystanie z tych rzeczy

#include <szuflada>
#include <szafka>
#include <kuchenka>
#include <kran>

No dobra. Czas na funkcje.

Głowna funkcją w naszych pluginach będzie plugin_init() . Służy on tak naprawdę do przygotowania serwera na pewne wydarzenia i rzeczy. W nim rejestrujemy moment śmierci, Obrażeń, startu rundy, odrodzeniu gracza i wszystkiego innego co dzieje się na serwerze (a jest tego naprawdę dużo). Rejestracje omówię na podstawie - czyli rejestracji wpisanej rzeczy w kosnoli.
register_clcmd (żeby zrozumieć przetłumaczę - rejestruj_klientakomende) uświadamiamy nasz plugin żeby zwrócił uwagę gdy gracz wpisze coś w konsoli. Po otwarciu nawiasów wpisujemy to na co ma plugin zwrócić uwagę - przecinek - co ma wykonać (funckje) po wpisaniu tego (złapaniu momentu).
Tyle chyba o tym. Brak takiej funkcji nie spodoba się serwerowi i odmówi on posłuszeństwa (plugin nie będzie działał).

Drugą funkcją z której często będziecie korzystać to plugin_precache. Łopatologicznie - w nim przygotowujemy pliki z których będziemy korzystać w pluginie tj. modele, dźwięki, spr'y i inne. Bez takiego przygotowania plików plugin Nie będzie działał a nawet wyłączy nam serwer. Znasz uczucie kiedy robisz Sobie płatki na mleku, wsypujesz płatki do miski a okazuje się że nie ma mleka? "Nasz serwer czuje to samo!" kiedy chce skorzystać z modelu/dźwięku na któy nie był przygotowany.

Dobra - żeby nie było że jesteśmy sadystami. Serwer ma swoje ograniczenia Większość może zapytać - jak to ? Czemu? A temu. Sytuacja jest podobna jak święta lub rodzinne spotkania u babci. Siedzisz , nigdzie nie wyjdziesz a na dodatek słyszysz miłe babcine "Może coś jeszcze? Na pewno nie jesteś głodny?" i mimo wyraźnego i stanowczego "Oj nie babciu" dostajesz porcje "dla pułku wojska". Wedle świętej zasady "nie czyń drugiemu co Tobie nie miłe" dotyczącej również naszych serwerów i stanowisk pracy nie mścimy się na nim po babcinych obiadach. Im serwer ma więcej modeli/dźwięków/Sprów/Plików/wadów itp do obsłużenia tym woliej pracuje i gracze są niezadowoleni. Oczywiście nie dotyczy się tylko i wyłącznie plików obsługiwanych. Również zmienne ( o których później ) mają swoje ograniczenia. Wszystko starajmy się robić jak najprościej.

To lecimy ze zmiennymi. Po co one? Bez nich ciężko cokolwiek pisać (aczkolwiek - można) Są to "rzeczy" którymi operujemy w pluginie żeby ułatwić sobie (i naszemu serwerowi) życie. Nie jasne? To teraz spróbuje to wyjaśnić.
Przyjmijmy że interesuje nas Życie gracza. Naszym pluginem pytamy o to serwer.
My - "Siema Serwer. Słuchaj - rzuć informacją o życiu Gracza o ID 1" (przypominam że (prawie) wszystko bazuje na liczbach)
Serwer - "Ty Stary no ja nie wiem."
Co w takim razie? W dokumentacji znajdujemy że w pewnej bibliotece jest możliwość zapytania o życie gracza. Więc dajemy znać serwerowi.

My - "Serwer słuchaj - amxmodx wie ile Gracz 1 ma hp. Weź go zapytaj bo ja nie umiem"
Serwer - "Te amxmodx Ile gracz 1 ma hp"
amxmodx - "100!"
Serwer - "Ma 100 Hp "
My - "dzięki"

W tym momencie mamy 5 operacji. Każemy serwerowi pytać o daną rzecz bibliotekę serwer wykonuję tą operacje, operacja zwraca wynik, wynik jest przejmowany przez serwer i serwer przekazuje go nam. No dobra Wszystko fajnie tylko to dla nas nie korzystne gdy robimy kilka operacji.

My - "Serwer rzuć hp gracza 2"
Serwer - "amxmodx daj hp gracza 2"
amxmodx - "95"
Serwer - "95"
My - "dzięki."
--Wykonuje operacje--
My - "Daj znowu hp gracza 2 bo nie pamiętam"
Serwer - amxmodx-serwer-my
-- operacja --
My - "daj znowu"

Serwer-amxmodx-serwer-my

Nie długo? Nie łatwiej byłoby Stworzyć zmienną w której zapamietamy takowe Hp? Wtedy wykonamy tylko jedno zapytanie - wykorzystamy serwer raz i wszyscy będą zadowoleni.


My - "Serwer rzuć hp 3 - ja zapiszę sobie ją"
Serwer - "amxmodx daj hp 3ki"
amxmodx - "50"
Serwer - "50!"
My - zapisujemy 50 do zmiennej.


Pomaga to też zautomatyzować plugin. wyobraź Sobie - że do życia mamy dodać 5. i co szybciej wykonać? Stworzyć zmienną i do niej dodać 5 czy sprawdzić każdą mozliwą kombinacje? Odpowiedź wiadoma ;)

Wracając do Funkcji. Z nimi jest zasada podobna jak ze zmiennymi - ułatwiamy Sobie nimi życie. Nie we wszystkich miejscach możemy operować konkretnymi danymi (sprawdzenie zadanych obrażeń gracza przy jego Respie - chyba ze w odpowiednim momencie Zapiszemy ją do zmiennej) ale przede wszystkim by zmienić nasze 100 linijek w 20. Jak? z Grubsza wyjaśnię to na zasadzie dodawania kilku broni do gracza.

Jeśli nasz gracz "Zrobi coś!" ma dodawać mu 3 bronie i ammo do nich. Za to jak gracz zrobi "Co innego!" ma mu dodać tamte 3 bronie , ammo do nich i dodatkowe dwie. Jak to wygląda?

if(Zrobi coś)
{
//Dodaje Bron1//Dodaje Ammo2

//Dodaje Bron2
//Dodaje Ammo2
//Dodaje Bron3
//Dodaje Ammo4
}
if(Coś innego!)
{

//Dodaje Bron1//Dodaje Ammo2

//Dodaje Bron2
//Dodaje Ammo2
//Dodaje Bron3
//Dodaje Ammo4

//Dodaje Bron_dodatkową1//Dodaje Ammo_dodatkową2

//Dodaje Bron_dodatkową2
//Dodaje Ammo_dodatkową2
}


Działa? No zadziała. Ale to nie to. Wykonamy jedna rzecz dla obu i kiedy będziemy chcieli zmienić musimy to robic w dwóch miejscach. A gdybyśmy uświadomili serwerowi żeby wykonał jedną rzecz w której będzie dodawanie 3 broni a w "Cos innego!" dodali dodatkowe dwie? Wygląda to tak


public nasza_funkcja()
{

//Dodaje Bron1//Dodaje Ammo2

//Dodaje Bron2
//Dodaje Ammo2
//Dodaje Bron3
}
if(Zrobi coś)
{
nasza_funkcja();
}
if(Coś innego!)
{

nasza_funkcja();
//Dodaje Ammo4

//Dodaje Bron_dodatkową1//Dodaje Ammo_dodatkową2

//Dodaje Bron_dodatkową2
//Dodaje Ammo_dodatkową2
}

Jakim Cudem To działa? :blink: Otóż w momencie kiedy gracz "Zrobi Coś!" Dajemy znak serwerowi żeby Wykonał nasza_funkcja() a jak już wykona to żeby dalej Działał od momentu wywołania Funkcji. Czyli w "Coś Innego!" doda bronie i doda Dodatkową. Tworzenie funkcji jest nam potrzebne w wyłapaniu momentów (Eventów) na serwerze - a w niej dajemy obsługę. Tadam :)


Mam nadzieję ze w pewnym sensie "Rozjaśniłem" wam Sprawę z Kodowaiem. Poradnik ten będzie Uzupełniany w miarę potrzeb (jak będzie kilka osób które czegoś nie rozumieją proszę pisać - swoimi sławami będe to dodawał o ile będe miał o tym pojęcie:D )

Niedługo zrobie na nim porządki - pogrupuję Poradnik tak żeby był przejrzysty. ;)

ZAKAZ KOPIOWANIA! Poradnik ma prawo być tylko tu i na moim blogu.
  • +
  • -
  • 49


#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
  • 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
[kotwica='wstep']Wstęp[/kotwica]
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)
Tym samym, poszczególne pluginy mogą być od siebie zależne, a ich kolejność ma znaczenie.
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>

public plugin_init(){
register_plugin("Nauka AMXX", "0.1", "benio101");
}
Przypomnijmy, w pierwszej linijce zaimportowaliśmy wymaganą zawsze dla AMXX, bibliotekę amxmodx.
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 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)
#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ę 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:
#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.


#573192 [ROZWIĄZANE] Pytanie odnośnie postawienia serwera CS na linux

Napisane przez Zabijaka Gryps w 23.09.2013 20:32

Użyj screena:
screen -A -m -d -S nazwa ./hlds_run dalsze parametry
  • +
  • -
  • 1


#573234 [ROZWIĄZANE] Pytanie odnośnie postawienia serwera CS na linux

Napisane przez Zabijaka Gryps w 24.09.2013 06:01

To dajesz bez zmian, nazwa - dajesz sobie nazwę jaką chcesz dla tego screena, jest ona po to, że jesli chciałbyś odpalić kilka screenów to żebyś wiedział który jest od czego żeby ewentualnie w danego wejść lub wyłączyć. No i dalej już standardowo ./hlds_run i parametry.
  • +
  • -
  • 1


#572823 Problem dotyczący wielu amxbans na osobnych serwerach.

Napisane przez freetu w 21.09.2013 18:25

zaloguj sie do admina

strefa adminów -> strona -> ustawienia -> nazwa ciasteczka

Sprawdź czy przypadkiem nie masz w każdym amxbansie taką samą nazwę ciasteczka.

 


  • +
  • -
  • 1


#572882 Problem dotyczący wielu amxbans na osobnych serwerach.

Napisane przez freetu w 21.09.2013 23:53

Nie jestem pewny w 100% pewny, ale chyba tak.

Możesz ewentualni jeszcze zróbić taki test - wyczyść wszystkie cookie we wszystkich przeglądarkach jakie masz zainstalowane. Następnie zaloguj się na jakieś konto np. w Firefoxie, po tym spróbuj się zalogować w innej przeglądarce na to samo konto tylko że w innym amxbansie (w którym nie powinieneś móc się zalogować). Jeśli nie zalogujesz to znaczy że jest to wina tego że masz wpisane wszędzie tą samą nazwę cookie's ;)


  • +
  • -
  • 1


#233729 Bany 5-minutowe nie działają.

Napisane przez G[o]Q w 05.04.2011 21:47

ustawienia strefy na www nie pokrywaja sie z czasem na serverze i czasem wychodzi na to ze gracz dostal bana na 5 minut a ban wygasl godzine temu :D
  • +
  • -
  • 1


#233431 Problem z banhistory menu

Napisane przez Milek w 05.04.2011 09:32

To jest niedokonczony projekt :)

Tylko czekac kiedy ogarna updata.
  • +
  • -
  • 2


#228312 Psychostats - instalacja na więcej niż 1 serwerze

Napisane przez bakaj w 21.03.2011 18:54

Zalezy jak chcesz zabezpieczyc plik stats.cfg. Jezeli nie chcesz, zeby ktos mial dane dostepu do Twojej bazy danych przez wpisanie np : www.twojastrona.pl/psychostats/stats.cfg, to umiesc ten plik przed public_html, tylko utworz nowy folder i wrzuc tam stats.pl i stats.cfg z 2 serwera:) Tylko pozniej poprawnie wpisz linie wywolywanie do crona.
  • +
  • -
  • 1


#227855 Psychostats - instalacja na więcej niż 1 serwerze

Napisane przez bakaj w 20.03.2011 20:11

Musisz miec 2 bazy. Stworz osobny folder na drugie staty, a pliki stats.pl i stats.cfg rowniez musisz umiescic w innym folderze. Miejsce nie ma znaczenia, bo sciezke do wywolywania skryptu stats.pl wpisujesz w cronie.
  • +
  • -
  • 1


#210265 Sklepik

Napisane przez szczepaneto w 28.01.2011 14:54

proszę :)http://www.speedysha...9/Diablomod.sma


#209101 Ustawienie danej szybkosci po zmianie broni

Napisane przez sebul w 24.01.2011 23:20

No tak też można, ale myślę, że te rozwiązanie z tym taskiem w plugin_init nie jest takie złe (na pewno lepszy niż wykonywanie tego w "client_PreThink"), a tym bardziej, że u mnie funkcja ze zmianą prędkości zajmuje tylko 363 znaków (po znacznym przerobieniu), więc dużo do wykonania nie jest. No ale jak już zostało to wspomniane, to napiszę jak zrobić to z tym taskiem w "RoundStart".
Znajdź
public RoundStart(){
for (new i=0; i < 33; i++){

dodaj pod
set_task(get_cvar_float("diablo_klass_delay")+0.1, "ustaw_predkosc", i);

następnie znajdź
public set_speedchange(id) {

i dodaj przed
public ustaw_predkosc(id) {
if(is_user_alive(id)) set_speedchange(id);
}

  • +
  • -
  • 4


#178300 Problem z ninją i paladynem.

Napisane przez Loganek w 09.10.2010 14:32

[Tutorial] Problem z naświetlaniem Ninji? Znaczek widoczności! - Nieoficjalny polski support AMX Mod X
oraz
[5.8d/5.9l] Naprawa long jumpa u Paladyna - Nieoficjalny polski support AMX Mod X
  • +
  • -
  • 1