Warmonger

Dodam jeszcze że jeśli inny plugin nie ingeruje w pev_max_health

Miejscem pluginu, który modyfikuje maksymalne punkty życia (MHP) i nie modyfikuje pev_max_health, jest /dev/null.
Obecność jakiegokolwiek pluginu, który działa w ten sposób sprawia, że wirusowo, żaden inny, który modyfikuje MHP, nie będzie działał poprawnie.

 

Pisanie pluginu, który z założenia ma być niekompatybilny z innymi jest irracjonalne, tak samo jak pisanie w założeniu, że taki plugin ma jakiekolwiek szanse się pojawić na serwerze.

A tworzenie pluginu, który ma celowo być niekompatybilny z innymi, gdyż koegzystencja z innymi pluginami działającymi w ten sam sposób jest niemożliwa nasuwa mi tylko jeden wizerunek:

 

To tak jakbyś napisał plugin, który wyłącza wszystkie inne pluginy, gdyż istnieje możliwość, że jakiś inny plugin wyłączy jego samego.

 

Pisanie pluginów w ten sposób sprawia, że potem wgranie innych powoduje problemy, które nie powinny mieć absolutnie miejsca.

Dlatego należy pisać pluginy poprawnie i dlatego Twój pomysł jest nie tylko nie trafiony, ale i niebezpieczny dla stabilności serwera.

Każdorazowo, pisząc plugin, którego używanie eliminuje możliwość używania jakiegokolwiek innego pluginu czy modyfikacji modyfikującej MHP, przyczyniasz się do wielogodzinnych udręk niedoświadczonych adminów, którzy Twój plugin wgrają na serwer i setek graczy, którzy na takim serwerze odczują boleśnie Twoje irracjonalne myślenie, a w ostateczności przyczynisz się do kolejnych, zupełnie zbędnych i bezwartościowych tematów na AMXX.pl

 

Zachowaj czystość. Nie zaśmiecaj forum. Nie pisz takich pluginów.

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? 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.

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

• 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_MAPY

wię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

Dodałem zdarzenie gdy gracz patrzy na konkretny piksel, Ciężko było użyć silnika, bo np pod kątem byt nie będzie dokładnie takiego rozmiaru co piksel. Pomogła matematyka. Kod wciąż wymaga optymalizacji, ale zaczęło się coś dziać