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
 

Agent - zdjęcie

Agent

Rejestracja: 13.08.2010
Aktualnie: Nieaktywny
Poza forum Ostatnio: 21.05.2018 19:00
*****

#83421 Server Reg Name

Napisane przez Portek w 20.09.2009 17:12

Dołączona grafika
Server reg name to nowy (a w zasadzie stary) projekt przy udziale Miczu, dzięki pluginowi można zarejestrować nick na stronie www, tak aby nikt kto nie zna hasła nie mógł na niego wejść. Rejestracja nicku nie jest wymagana, oznacza to że gracz bez takowej może bez przeszkód grać na serwerze.

Dołączona grafika
Standardowa

Dołączona grafika
- MySQL

Dołączona grafika
srn_sql_host "" // host bazy danych
srn_sql_user "" // użytkownik bazy danych
srn_sql_pass "" // hasło do bazy
srn_sql_db "" // nazwa bazy danych

Uwaga!
Aby gracz po rejestracji nicku mógł dostać się na serwer musi podać hasło w komendzie setinfo _pw "hasło".

Dołączona grafika
Ażeby plugin działał poprawnie należy w pliku config.php ustawić poprawne dane do bazy danych, a następnie wykonać jednorazowo plik sql.php, tak aby zostały utworzone tabele w bazie danych - bez tego plugin nie będzie działał.

W pluginie użyte jest kodowanie haseł w systemie MD5, należy o tym pamiętać jeśli piszesz własny skrypt rejestracji nicków na www.

Dołączona grafika
srn.rar - Główny plugin.
skrypt.rar - Skrypt przygotowany przeze mnie dla własnych celów, z mailową weryfikacją rejestracji (opcjonalnie).

Załączone pliki


  • +
  • -
  • 2


#283177 Leczenie na Stalce

Napisane przez GeDox w 15.08.2011 14:06

Witajcie. Zaprezentuję Wam tutaj łatkę, która uniemożliwia leczenie gracza, który ma Stalker Ring (Dla przypomnienia: Dzięki niemu jesteśmy prawie całkowicie niewidoczni i mamy 5 życia).

Naciskamy CTRL+F i w wyszukiwarce wpisujemy:
public Timed_Healing()

Następnie tuż po:
if (player_b_heal[a] <= 0)
continue

Dodajemy:
if (player_item_id[a] == 17)
continue

I gotowe. Powyższy kod działa, był testowany.
  • +
  • -
  • 7


#194176 [5.9l] Zła redukcja obrażeń po zwiększeniu lvl

Napisane przez sebul w 06.12.2010 00:32

Nie wiem czy ktoś to zauważył, ale po zwiększeniu lvl (czyli i max statów, a dokładniej zręczności), redukcja obrażeń trochę źle działa, gdyż przy 50 pkt w zręczności miało się już praktycznie max % redukcji tych obrażeń, a dodawanie powyżej 50 pkt w zręczność, mało co dawało i tak mając 100 pkt w zręczności, redukcja obrażeń była prawie taka sama jak przy 50 punktach. Oczywiście jest na to rozwiązanie ;]
Znajdź wszystkie
player_damreduction[id] = (47.3057*(1.0-floatpower( 2.7182, -0.06798*float(player_agility[id])))/100)

zamień na
player_damreduction[id] = damachange(X, Y, Z);

Dodaj gdziekolwiek w sma, np. przed "public reset_skill(id)"


I Opcja bez zmiany sposobu obliczeń
stock Float:damachange(maxstat, skill, dziel) {
if(skill > 0)
return (47.3057*(1.0-floatpower(2.7182,-(0.06798/(maxstat/50))*float(skill)))/dziel);

return 0.0;
}
  • zamiast X wpisz maksymalną wartość statystyki, czyli w standardzie jest to 50
  • zamiast Y wpisz statystykę, która będzie w obliczeniach, czyli dla redukcji obrażeń będzie to "player_agility[id]"
  • zamiast Z wpisz liczbę przez którą redukcja obrażeń będzie się dzielić, im większa liczba, tym mniejsza będzie redukcja, w standardzie jest 100

II Opcja ze zmianą sposobu obliczania redukcji, jak dla mnie ta opcja jest lepsza, przy większej ilości punktów dodanych w zręczność, 1 punkt daje więcej niż przy standardowych wyliczeniach
stock Float:damachange(maxstat, skill, Float:dziel) {
if(skill > 0) {
new Float:qwe = float(skill)/maxstat;
new Float:bonus = (2.0-floatpower(2.0, qwe))/(dziel*4);
if(bonus < 0.0) bonus = 0.0;
return bonus+qwe/dziel;
}

return 0.0;
}

  • zamiast X wpisz maksymalną wartość statystyki, np. 50
  • zamiast Y wpisz statystykę, która będzie w obliczeniach, czyli dla redukcji obrażeń będzie to "player_agility[id]"
  • zamiast Z wpisz liczbę zmiennoprzecinkową, przez którą redukcja obrażeń będzie się dzielić, jeśli wpiszesz 2.0 to maksymalna wartość redukcji będzie wynosić 50%, im większa liczba, tym mniejsza będzie redukcja

  • +
  • -
  • 14


#286613 [5.9l] Fireball - wybuchanie na respie, itp.

Napisane przez sebul w 28.08.2011 11:47

W standardzie fb ma to do siebie, że wybucha na respie, moście (na aztecu) czy też na bsie. W temacie dowiecie się jak temu zaradzić ;]

Znajdź całą funckję
Spoiler

zamień na
Spoiler

Przy okazji możecie też usunąć linijkę z
register_think("PowerUp","Think_PowerUp")

bo nie zauważyłem, żeby ona do czegoś służyła...

Kod poprawiony, teraz fb nie wybucha przy zwłokach.
  • +
  • -
  • 13


#48630 GGadu

Napisane przez mgr inż. Pavulon w 11.03.2009 21:23

GGadu
Autor: Pavulon
Wersja: 0.4.2.2


Opis:
Mam nadzieje że jest to pierwszy plugin który umożliwia obsługę GG z poziomu AMXX.
Dzięki niemu mamy możliwość wysyłania wiadomości GG z jak i do gry, wyświetlenie aktualnego statusu serwera, ilości graczy oraz administracji serwera za pomocą GG.
Nie odpowiadam za żadne szkody powstałe w wyniku używania tego pluginu itd.

Instalacja:
Standardowo wrzucić plik .amxx do amxmodx/plugin oraz dopisać go do configs/plugins.ini a .sma do amxmodx/scripting
Wszystkie pliki konfiguracyjne oraz logi będą znajdowały się w katalogu amxmodx/GGadu (zalecane jest stworzenie go ręcznie i nadanie mu odpowiednich praw dostępu {np. CHMOD 777} w celu umożliwienia zapisu), lecz jeżeli przy uruchomieniu nie będzie istniał katalog to zostanie on stworzony i umieszczone w nim zostaną odpowiednie pliki(GGadu.cfg; GGadu.ini; GGadu_bans.ini; GGadu_servers.ini) {wszystko w załączniku}.

GGadu.cfg - plik z cvar'ami

;[GGadu] Umiesc w tym pliku cvar'y do plugin'a.
amx_gg_numer "0"
amx_gg_haslo "0"
amx_gg_opis_on "name w/ GG [ON]nIP: ipnMapa: mapnTimeleft: tlnGraczy: act/max"
amx_gg_opis_off "name w/ GG [OFF] mapchage ?"
amx_gg_opis_refresh "60"
amx_gg_gracze_info "abcdefgh" ;abcdefgh
amx_gg_log "bc" ;abc
amx_gg_log_typ "a" ;ab
amx_gg_losowy_serw "" ;ab
amx_gg_dzwiek "1"

Niezbędne są cvary amx_gg_numer i amx_gg_haslo. Reszty jak nie będzie to przyjmą wartości standardowe.
Konto GG należy wcześniej utworzyć np. standardowym komunikatorem gdyż nie ma opcji rejestracji z serwera.
Zasada dodawania cvar'ów dokładnie taka sama jak np. w amxx.cfg

GGadu.ini - admini gg

;[GGadu] Umiesc w tym pliku numery GG adminow wraz z ich flagami dostepu oddzielone spacjami, po jednej linijce dla admina np:
;nr_gg flagi_admina "nick" "flagi_dostepu"
;12345678 abcdefghijklmnopqrstuwvxy "SYS-OP" "bc"
;1234567 abcdefghijklmnopqrstuwvxy "ADMIN" "b"
;Srednik na poczatku oznacza ze dana linijka nie jest brana pod uwage.

Radzę zachować ten format, bez żadnych komentarzy. Flagi są takie same jak na serwerze.

GGadu_bans.ini - bany gg

;[GGadu] Dodaj w tym pliku numery gg ktore zostana zbanowane, po jednym w linijce.
;123456789
;234567890
;Srednik na poczatku oznacza ze dana linijka nie jest brana pod uwage.

Jedna linijka to jeden zbanowany numer gg, nie ma co się więcej rozpisywać.

GGadu_servers.ini - serwery CS

;[GGadu] Dodaj w tym pliku serwery wraz z opisem jaki chcesz zobaczyc po wpisaniu komendy serwery, po jednym w linijce.
;127.0.0.1:27666 Super Serwer GG: 123456789
;Srednik na poczatku oznacza ze dana linijka nie jest brana pod uwage. Maksymalna dlugosc 127 znakow

Format oraz treść wg uznania. Ograniczenie do 127 znaków na linijkę.

GGadu_system.log - log
Informacje o łączeniu, akcjach i problemach.

GGadu_DATA.log - log
Pliki tworzą się automatycznie przy odbiorze/wysyłaniu wiadomości. DATA jest w formacie rr/mm/dd

Oczywiście możemy też przekopiować odpowiedni folder z załącznika.

Wymagane moduły:
  • sockets

Konfiguracja:

Cvary:
  • amx_gg_numer "0" - numer gg z którego maja być wysyłane wiadomości
  • amx_gg_haslo "0" - haslo do tego numeru gg
  • amx_gg_opis_on "name w/ GG [ON]nIP: ipnMapa: mapnTimeleft: tlnGraczy: act/max" - opis serwera kiedy włączony
  • amx_gg_opis_off "name w/ GG [OFF] mapchage ?" - opis kiedy wyłączony
  • amx_gg_opis_refresh "60" - co ile odświeżać opis [w sekundach]
    0 = tylko przy zmianie mapy
    wartości poniżej 15 mogą spowodować block'a od serwera gg i brak zmian
  • amx_gg_gracze_info "abcdef" - które dane wyświetlać w liście graczy
    a = nr. porzadkowy gracza, b = username, c = authid
    d = ip, e = team, f = userid
  • amx_gg_log "bc" - co logować ?
    a = wiadomości przychodzące, b = rozmowy, c = funkcje
  • amx_gg_log_typ "1" - co logować w rozmowach wychodzących ?
    a = tylko steam_id, b = tylko ip, brak = tylko nick
  • amx_gg_losowy_serw "" - używać losowego serwera gg do logowania ?
    a = jesli notoperating, b = przy nieudanym pobraniu ip
  • amx_gg_dzwiek "1" - dźwięk przy otrzymaniu wiadomości ?
    1 = tak, 0 = nie

Zamienniki w opisie:
  • name == nazwa serwera
  • ip == ip serwera
  • map == aktualna mapa
  • tl == pozostały czas XXmin YYsek
  • ml == ilość minut do końca mapy
  • sl == ilość sekund do końca
  • act == ilość graczy na serwerze
  • max == maksymalna liczba graczy
  • n == enter == przejście do następnej linii

Flagi dostępu adminów w pliku:
  • "c" - Sys-Op
  • "b" - Admin
  • "a" - Admin bez powiadomienia grupowego
  • "" - bez kontaktu

Komendy:
  • say(_team) gg: nr_gg(lub nick) wiadomosc - wysyła wiadomość na dany numer gg
    nick jest nazwą(lub jej częścią) pod jaką zapisany jest dany user w pliku GGadu.ini
  • say(_team) /kontakt{/contact} - wyświetla menu kontaktu z administracja
  • amx_gg_reload_cvars - wczytuje ponownie cvar'y z flagami (ADMIN_BAN)
  • amx_gg_reload_admins - pobiera ponownie dane adminów z pliku (ADMIN_BAN)
  • amx_gg_reload_bans - pobiera ponownie bany z pliku (ADMIN_BAN)
  • amx_gg_reload_servers - pobiera ponownie serwery z pliku (ADMIN_BAN)

Jeżeli menu kontaktu ma być dostępne dla graczy po użyciu komendy amx_menu,
nalezy do configs/custommenuitems.cfg dopisać linijkę:
amx_addclientmenuitem "Kontakt GGadu" "ggk_menu" "" "GGadu"

Komendy GG:
  • pomoc = lista dostępnych komend
  • status = stan serwera: hostname, wersja amxx, ip:port, mapa, ilość graczy, pozostały czas mapy
  • gracze = lista graczy na serwerze wraz z ich danymi takimi jak IP i Steam_id
  • serwery = lista dostępnych serwerów, dane własne z pliku
  • wersja = aktualna wersja GGadu
  • chat: gracz wiadomosc = wiadomość do kogoś na serwerze
    gracz może być nick'iem (jeżeli występują spacje w nicku to podawać go cudzysłowach) gracza(lub jego częścią), adresem ip, steam_id lub #userid np:

    chat: "[you]" Pozdrowienia z GG

    dla adminów jest też możliwość pisania do wszystkich lub do danego team'u wpisując @all / @ct / @t zamiast gracza np:

    chat: @t Sprzedam pake

  • admin: komenda_admina = wykonuje zadana komendę na serwerze (#odpowiedni ADMIN wymagany#)
    numer z ktorego piszemy musi miec dodanego admina oraz niezbędne flagi do wykonania komendy np:

    admin: amx_map de_dust

  • rcon: komenda_hlds'a = wykonuje zadana komendę rcon na serwerze (#ADMIN_RCON wymagany#)
    niezbędny admin z flagą ADMIN_RCON ("l")

    rcon: restart



Dodatkowe info dostępne jeszcze w .sma




UWAGA !!!
W przypadku gdy plugin stworzył nam folder i nie możemy się do niego dostać z powodu braku praw(źle ustawiony chmod wynikający z tego że inny user{serwer} np root utworzył folder i nie dał nam praw do niego) należy wyłączyć ggadu, pobrać plugin ggadu_dir_remover i standardowo go zainstalować. Po zmianie mapy powinien on usunąć folder wraz z zawartością. Następnie tworzymy sami(kopiujemy z załącznika) folder i pliki pluginu ggadu oraz nadajemy im CHMOD'y 777 - tak aby i serwer miał do nich dostęp. Następnie wyłączamy ggadu_dir_remover, konfigurujemy i włączamy ggadu.
Problem ten pojawia się gdy użytkownik który ma dostęp do pliku nie jest użytkownikiem który uruchamia serwer, np:
użytkownik -> user
serwer -> root (root, główny user systemu, taki admin w M$ OS)
Kiedy root tworzy pliki nadaje im standardowo takie chmod'y że user może tylko je otworzyć(a folder tylko zobaczyć - nawet nie otworzy). Biblioteka amxx'a niestety jest ograniczona i nie ma możliwości wyboru czy też zmiany CHMOD'ów(a nie opłaca się rozprowadzać zmienionej biblioteki dla jednego pluginu) dlatego jak stworzymy sami plik to będzie można go edytować i wszytko będzie działać, lecz gdy serwer stworzy plik typu log to niestety edytować już go nie będziemy mogli.



p.s.
Not4Newbie :P

Załączone pliki


  • +
  • -
  • 17


#208459 Tymczasowy admin / slot

Napisane przez ZiuTeK w 23.01.2011 00:27

Opis:
Dzięki temu pluginowi możemy przydzielić admina na określoną liczbe dni. Admina możemy przydzielić jedynie na nick.
Plugin jest przeróbką Temp Admin by Alka, przerobka moze niewielka ale zmiany dosyc powazne. Nie ma mozliwosci, zeby ktos sam mogl sobie przydzielic admina (jak w wersji Alki). Teraz jedynie admin z flaga ADMIN_IMMUNITY moze przydzielac admina.
Brak wyboru na minuty i godziny. Admina/rezerwacje slota lub konto neo można przydzielić jedynie na konkretna liczbe dni(Nie widzialem sensu wprowadzania adminow na tak krotki okres).

Komenda do przydzielenia admina to:
amx_tempadmin <#nick> <#haslo> <#na ile dni> <#flagi admina>

Aby przydzielic admina nie trzeba wolac gracza na serwer jak w starej wersji.
Admini tymczasowi nie sa dopisywani do pliku users.ini. Zostaje utworzony osobny plik temp_admin.ini w ktorym po uplywie czasu linijka z uprawnieniami admina jest podmieniana na ;Admin Expired. Nie trzeba sie martwic w sprawdzanie slota/admina czy rezerwacji nicka, po uplywie okreslonego czasu flagi zostana usuniete.

Załączone pliki


  • +
  • -
  • 9


#197917 Pcvar'y

Napisane przez Ortega w 20.12.2010 14:48

Natchnęło mnie na objaśnienia z czym się podaje pointer cvary. Pewnie większość z was używała ich już bądź używa lecz czy na prawdę każdy wie dlaczego ? Tutaj postaram się odpowiedzieć na pytanie: "Dlaczego pcvary powinny być stosowane lub dlaczego nie powinny być?"

Nazwa pcvar akronim od pointer command variable tłumacząc na ojczysty język możemy tutaj rozumieć zmienne sterowane metodą przez wskaźnik.

Jeśli nic nie mówi Ci skrót cvar zajrzyj tu: Cvar`y - AMXX.pl: Support AMX Mod X

Teraz krótka notka o tym jakie są zalety pcvar'ów nad cvarami.
1.Piszemy plugin, dajmy na to będzie zmieniana cena przedmiotu, który będzie można kupić. Chcemy aby przyszły twórca serwera nie zmieniał nic w kodzie samego pluginu lecz, aby mógł sterować tą wartością pośrednio przez komendy amxx. Nic prosztszego, bowiem pcvar'y mają bardzo podobną wręcz taką samą rejestrację w maszynie amxx, więc dużo nie trzeba zapamiętywać aczkolwiek zawsze można zajrzeć do dokumentacji. Dla przykładu wcześniejszej ceny oto taki kodzik prosty:
// najpierw deklarujemy sobie globalnie zmienna tu: wskaźnik, który będzie właśnie wskazywał na nasz cvar
new g_Pcvar_kasa_na_item1; // zapis zmiennej zgodnie z notacją węgierską (HN)

//gdzieś w forwardzie gdzie powinniśmy umieścić nasz wskaźnik i przypisać do niego rejestrację cvar'u na przykład plugin_precache
public plugin_precache( ) {
g_Pcvar_kasa_na_item1 = register_cvar( "Item 1", "1500" ); // rejestrujemy zwykły cvar i przypisujemy jego return do wskaźnika
}


No dobrze ale przecież jako programiści chcemy jakoś używać tej wartości, więc do tego służą natywy takiej jak:
get_pcvar_num , dla liczb całkowitych
get_pcvar_float , dla liczb zmiennoprzecinkowych
get_pcvar_string , dla łańcuchów

Proforma powiedzmy, że zachciało nam się nagle pobrać wartość naszego cvara, więc po prostu zróbmy to:
new Zmienna = get_pcvar_num( g_Pcvar_kasa_na_item1 ); // przypisujemy do nowej zmiennej wartość naszego cvar'a używając natywy pobrania przez wskaźnik

Prawda, że wcale nie skomplikowane :D? Bardzo podobnie jest z ustawianiem nowej wartości dla takiegoż cvar'u w trakcie działania pluginu.
set_pcvar_num , dla liczb całkowitych
set_pcvar_float , dla liczb zmiennoprzecinkowych
set_pcvar_string , dla łańcuchów

2. Wymieniam dalej zalety, więc trzeba powiedzieć, że taki sposób pobierania wartości jest bardzo szybki ( około 10 razy szybszy niż zwykły np. get_cvar_num ).

3. No i tutaj kolejna duża wydaje mi się zaleta pcvar'ów. Wyobraźmy sobie plugin. Mamy mnóstwo różnego kodu w tym właśnie cvary. Chcemy napisać inny plugin, który będzie coś wykonywał na serwerze ale, coś innego koliduje z nim, lub chcemy w trakcie innego pluginu bądź wydarzenia zaplanować / ustawić inna wartość cvar'u. Do tego właśnie służy nam wskaźnik.
Po co mamy się męczyć i analizować kod bądź też mieszać w nim skoro możemy to zrobić z zewnątrz.
Dlaczego mamy taki dostęp ? Bardzo proste deklarowaliśmy wcześniej zmienna globalnie, która na dodatek jest wskaźnikiem. Teraz możemy z niej skorzystać.
// mamy inny nowy plugin
//po pierwsze globalnie deklarujemy pointer a jakże by inaczej :)
new g_pointerOldCvar;
// no i teraz gdzieś w kodzie potrzebujemy zmienić albo pobrać wartość cvar'u z tamtego wcześniejszego pluginu, robimy to tak
g_pointerOldCvar = get_cvar_pointer( "Item 1" );

Gdy pobraliśmy wskaźnik to możemy wykonywać na nim już te operacje co wcześniej wypisałem.

4. Można nimi manipulować przede wszystkim w cvar'ach gry przykład:
new g_pSkyName;
g_pSkyName = get_cvar_pointer( "sv_skyname" );
set_pcvar_string( g_pSkyName, "NIEBO1" );


Teraz wady:
1. Jeśli nie zamierzasz używać tego do celów w podpunktach 3 i 4 lub w przypadkach wcześniejszych, więcej niż kilka razy to polecam zostać przy zwykłych cvarach.

Myślę, że się przyda i uzupełni temat, który podałem w linku.
  • +
  • -
  • 12


#109357 Natywy

Napisane przez R3X w 03.02.2010 00:34

Natywy

1. Opis

Funkcje natywne są dostępne dla każdego zainstalowanego pluginu AMXX. Udostępniają funkcje natywne tworzymy z naszego pluginu jakby dodatkową bibliotekę. Dzięki temu mamy możliwość podziału większego dzieła nie tylko na pliki, a na osobne pluginy. Pozwala to na dużą elastyczność kodu oraz pracę z krótszymi, mniej skomplikowanymi programami.

Krótko: Możemy korzystać z danych jednego pluginu w innym.


2. Przygotowanie

Aby to zadziałało potrzeba dwóch współgrających elementów:

  • pluginu-biblioteki, który obsługuje funkcje
  • pliku .inc, który pozwoli korzystać z tych funkcji w innym pluginie
No i pluginu, który będzie korzystał z dobrodziejstw biblioteki.


Na potrzeby tego artykułu stworzę testową bibliotekę <nicto> (czyt. "nic to")

INC
Weźmy się najpierw za plik .inc. Raz dołączony plik nie będzie więcej potrzebny, więc żeby nie powodował problemów ograniczymy jego wykonywanie:

#if defined _nicto_included
	#endinput
#endif

#define _nicto_included

sprawdzamy czy stała "_nicto_included" istnieje (wymyślamy coś własnego, nazwa powinna być unikatowa)
jeśli tak to kończymy plik (#endinput)
jeśli nie to ją definiujemy, potem dołączana jest reszta pliku

dalej informujemy kompilator, że korzystamy z biblioteki nicto:

#pragma library "nicto"

i dalej nagłówki funkcji(nasze natywy lub forwardy[o nich będzie następny artykuł ;P]), stałe, enumeracje lub całe funkcje (stocki)

cały plik inc może wyglądać np tak:

#if defined _nicto_included
	#endinput
#endif

#define _nicto_included

#pragma library "nicto"

enum stan{
	NIC,
	COS
}

native Float:nic();

native cokolwiek(id, stan:s);

native moze_cos(id, Float:fTime, const szMessage[]);

SMA(1)
Pierwszy kod sma to będzie nasza biblioteka. Sam plugin może działać sobie po swojemu tak jak każdy inny. Kluczowym elementem jest fragment:

public plugin_natives(){
	
}

Po pierwsze rejestrujemy bibliotekę:
register_library("nicto");

Po drugie, trzecie i czwarte:
register_native("nic", "n_nic");
register_native("cokolwiek", "n_cokolwiek");
register_native("moze_cos", "n_moze_cos");

register_native("funkcja_biblioteki", "funkcja_pluginu");
funkcja_biblioteki - to ta z inc`a, będzie wywoływana w innych pluginach
funkcja_pluginu - ona będzie odpowiedzialna za działanie tej pierwszej; jej parametry to id pluginu, w którym wywołano natyw oraz ilość argumentów, zwracany typ musi być zgodny z tym podanym dla funkcja_biblioteki w inc`u


Na tym etapie biblioteka wygląda tak:
#include <amxmodx>
#include <amxmisc>

#define PLUGIN "NicTo Lib"
#define VERSION "1.0"
#define AUTHOR "R3X"


public plugin_init() {
	register_plugin(PLUGIN, VERSION, AUTHOR)
}
public plugin_natives(){
	register_library("nicto");
	register_native("nic", "n_nic");
	register_native("cokolwiek", "n_cokolwiek");
	register_native("moze_cos", "n_moze_cos");
}
//plugin - id pluginu
//params - ilość argumentów
public Float:n_nic(plugin, params){
	
}
public n_cokolwiek(plugin, params){
	
}
public n_moze_cos(plugin, params){
	
}

Funkcja nic ma nagłówek: native Float:nic();
=żadnych parametrów, a zwracać ma floata

skoro 'nic', to możemy zrobić np. to:
public Float:n_nic(plugin, params){
	return 0.0;
}



Funkcja cokolwiek korzysta z typu danych deklarowanego w samym incu. Nic nie stoi na przeszkodzie, aby go tu dołączyć. Problemy się zaczną, gdy będziemy wywoływać własne funkcje natywne w pluginie-bibliotece. Po prostu to nie przejdzie :D



w n_cokolwiek oczekujemy 2 parametrów id, i s; musimy mieć pewność, że są:



public n_cokolwiek(plugin, params){
 	if(params < 2){
 		log_amx("Zbyt malo parametrow funkcji cokolwiek!");
 		return 0;
 	}
 	return 1;

 }



Wartość samych parametrów pobrać nam pozwolą funkcje dla danego typu danych:



get_string(param, dest[], maxlen); // tekst

get_param(param); //komórka pamięci (int, char, bool)

Float:get_param_f(param); //float



get_param_byref(param); // komórka przez referencję

Float:get_float_byref(param); //float przez referencję



get_array(param, dest[], size); //tablica komórek

get_array_f(param, Float:dest[], size); //tablica float`ów




Jako, że tablice bez ‘const’ i jawne referencje pozwalają na zmianę wartości argumentów istnieją też odpowiedniki set_*



set_string(param, dest[], maxlen);


set_param_byref(param, value);

set_float_byref(param, Float:value);



set_array(param, const source[], size);

set_array_f(param, const Float:source[], size);






W każdym przypadku param to numer parametru licząc od lewej zaczynając od 1.





Skupmy się na pobieraniu. Natyw cokolwiek przekazuje id oraz stan:s. Ich wartości w n_cokolwiek to:



new id = get_param(1);
new stan:s = stan:get_param(2);


Aby zachować układ zmiennych i uniknąć ‘tag mismatch’ dokonałem rzutowania do stan:



Załóżmy, że id to index gracza, a funkcja pokazuje mu na czacie komunikat zależny od stanu COS/NIC. Biblioteka powinna teraz wyglądać tak:



#include <amxmodx>
 #include <amxmisc>
 #include <nicto>

 #define PLUGIN "NicTo Lib"
 #define VERSION "1.0"
 #define AUTHOR "R3X"


 public plugin_init() {
 	register_plugin(PLUGIN, VERSION, AUTHOR)
 }

 public plugin_natives(){
 	register_library("nicto");
 	register_native("nic", "n_nic");
 	register_native("cokolwiek", "n_cokolwiek");
 	register_native("moze_cos", "n_moze_cos");

 }
 //plugin - id pluginu
 //params - ilość argumentów
 public Float:n_nic(plugin, params){
 	return 0.0;
 }
 public n_cokolwiek(plugin, params){
 	if(params < 2){
 		log_amx("Zbyt malo parametrow funkcji cokolwiek!");
 		return 0;
 	}

 	new id = get_param(1);
 	if(!is_user_connected(id))
 		return 0;

 	new stan:s = stan:get_param(2);
 	switch(s){
 		case NIC: client_print(id, print_chat, "NIC");
 		case COS: client_print(id, print_chat, "COS");
 	default: return 0;
 	}
 	return 1;
 }

 public n_moze_cos(plugin, params){

 	

 }



Do pełniejszego obrazu natywu potrzebujemy danych z tego pluginu. Utwórzmy tablicę globalną giRandom [33], i przy wejściu na serwer przypiszmy graczowi losową liczbę 0-100.



Niech funkcja może_cos zwróci wartość tablicy z podanego indeksu (id) i wrzuci do logów wartości fTime i szMessage[].



public n_moze_cos(plugin, params){
 	if(params < 3){
 log_amx("Zbyt malo parametrow funkcji moze_cos!");
 		// -1 nie mieści się w przedziale 0-100, więc będzie można wychwycić błąd
 return -1; 
 	}

 	new id = get_param(1);
 	if(id < 0 || id > 32) //nie musi byc gracza, wystarczy ze jest taki indeks w tablicy
 		return -1;

 	new Float:fTime = get_param_f(2);
 	new szMessage[32];
 	get_string(3, szMessage, 31);
 	log_amx("fTime=%f, szMessage = %s",fTime, szMessage);

 	return giRandom[id];

 }

SMA(2)
Teraz pora na plugin, który będzie korzystał z biblioteki. Po prostu dołączamy <nicto> i używamy podanych funkcji np tak:

#include <amxmodx>
#include <amxmisc>
#include <nicto>

#define PLUGIN "New Plug-In"
#define VERSION "1.0"
#define AUTHOR "R3X"


public plugin_init() {
	register_plugin(PLUGIN, VERSION, AUTHOR)
	
	log_amx("Nic:%f", nic());
	register_clcmd("say /cokolwiek","cmdCokolwiek");
}
public cmdCokolwiek(id){
	cokolwiek(id, NIC);
	moze_cos(id, 3.14, "Pi");
	return PLUGIN_CONTINUE;
}


Info:
ważne by plugin korzystający z biblioteki był niżej w plugins.ini niż sama biblioteka. W innym przypadku plugin korzystający z biblioteki musisz przefiltrować natywy:
set_native_filter

Załączone pliki


  • +
  • -
  • 45


#109318 Natywy

Napisane przez R3X w 02.02.2010 21:38

register_native("A", "B");

w pluginie, który rejestruje natywa musi być publiczna funkcja B w takiej postaci:
public B(ID_PLUGINU, LICZBA_PARAMETROW){

gdy w innym pluginie użyjesz funkcji A() to B() zajmuje się jej obsługą, dlatego masz dostęp do danych z tego pluginu w innym

co do inc`a, to pierwsze linie dbają, by nagłówek 2 razy użyty (2 linijki z #include<mojabilbioteka>) nie sprawiał problemów przy kompilaciji

#if defined _DiabloMod_Items_included 
#endinput 
#endif 
#define _DiabloMod_Items_included
znaczy: jeśli istnieje już stała "_DiabloMod_Items_included" nie idź dalej


#pragma library "DiabloMod_Items"
to jest związane z register_library();



dalej są nagłówki funkcji, informujące w jaki sposób ich używać; mile widziane komentarze jeśli nazwa i argumenty funkcji nie mówią za dużo
  • +
  • -
  • 1


#151730 Forwardy

Napisane przez R3X w 14.07.2010 17:05

Forwardy1. Opis
Działają odwrotnie do natywów. Funkcja natywna jest udostępniana innym pluginom. Forwardy to abstrakcyjne funkcje, które biblioteka próbuje wywołać. Wykonując forward dajemy sygnał, że nastąpiło jakieś zdarzenie i plugin może na nie zareagować. Można to lepiej zrozumieć biorąc pod uwagę forwardy samego AMXX, takie jak:
forward plugin_init();
forward client_putinserver(id);
stąd powinieneś się domyślić je rozpowszechniać.

W pliku .inc podajemy nagłówek
forward nazwa(Float:para, met, ry[]);
a w pliku .sma
public nazwa(Float:para, met, ry[]){
	//nasz kod
}
Dalej tę funkcji publiczną nazywam 'funkcją oczekującą'.

O tym jak zaprojektować czytaj dalej ->

2. Tworzenie
Po pierwsze musimy zarejestrować forward.

MultiForward
Gdy użyjemy poniższej, oczekująca funkcja będzie wywoływana w każdym pluginie, który z niej korzysta.
/**
* Rejestruje forward dostępny dla wszystkich pluginów
*
* @param name[] Nazwa publicznej funkcji
* @param stop_type Typ zatrzymania
* @param ... Parametry
* @return Uchwyt (liczba całkowita)
*/
CreateMultiForward ( const name[], stop_type, ... )


Jako name[] podajemy nazwę, Typ zatrzymania określa sposób realizacji:
#define ET_IGNORE		0	//ignoruj zwracaną wartość
#define ET_STOP			1	//zatrzymuje przy PLUGIN_HANDLED
#define ET_STOP2		2	//to samo,tylko nie zwraca największej wartości
#define ET_CONTINUE		3	//bez stopu, zwraca największą wartość
forward z typem ingore i continue będzie wywołany zawsze we wszystkich pluginach
opcje stopu (STOP i STOP2) zatrzymują rozsyłanie forwardu po otrzymaniu PLUGIN_HANDLED

Jeśli na tym skończymy to powstaje forward bez parametrów, jak:
//sma biblioteki
CreateMultiForward ( "nic_sie_nie_stalo", ET_IGNORE);

//w pliku .inc
forward nic_sie_nie_stalo();


Aby dodać jakieś argumenty trzeba rozwinąć rejestrowanie o dodatkowe wartości. Do określenia typu parametru służą stałe (nazwy są sugestywne)
#define FP_CELL			0
#define FP_FLOAT		1
#define FP_STRING		2
#define FP_ARRAY		4
Dodanie argumentu forwardu polega na dopisniu jego typu po przecinku
//sma biblioteki
CreateMultiForward ( "nic_sie_nie_stalo", ET_IGNORE, FP_CELL, FP_FLOAT);

//w pliku .inc
forward nic_sie_nie_stalo(id, Float:fTime);


MultiForwardEx
Jest to wersja kompatybilna z pluginami AMX. Nie będę się tym zajmował, szczegóły w pliku amxmodx.inc.

OneForward
Druga możliwość to forward przeznaczony wyłącznie dla jednego pluginu.
/**
* Rejestruje forward dostępny dla pojedynczego pluginu
*
* @param plugin_id Id pluginu
* @param name[] Nazwa publicznej funkcji
* @param ... Parametry
* @return uchwyt (liczba całkowita)
*/
CreateOneForward ( plugin_id, const name[], ... )

Nie ma tu opcji stopu, bo tylko jeden, konkretny plugin może wykonać forward i zwróci on równie konkretną wartość.

plugin_id to id zwrócone przez funkcję
find_plugin_byfile(const pname[]);
albo....

Ciekawym rozwiązaniem jest połączenie funkcji natywnej z forwardem w ten sposób. Wyobraźmy sobie rdzeń modu, który pozwala dodawać itemy w osobnych pluginach. Rdzeń ten udostępnia natywną funkcję
register_item( /*parametry*/)
, która zapisuje informacje i tworzy właśnie pojedynczy forward powiedzmy:
forward get_item(id)
ten osobny plugin będzie czekał na sygnał, gdy gracz zdobędzie ten przedmiot. Wygodne prawda? Zwłaszcza, że id pluginu to jeden z parametrów funkcji obsługującej natyw.

Parametry jak przy MultiForward↵

3. Wywołanie
Pora wysłać sygnał wywołania forwardu.
/**
* Wywołuje wskazany forward
*
* @param forward_handle Wartość zwrócona przez Create(One|Multi)Forward
* @param &ret Wartość zwrócona przez wywołane forwardy przekazana przez referencję
* @param ... Dokładnie tyle parametrów i takich typów jak podaliśmy przy tworzeniu
* Dane zostaną przekazane do funkcji oczekujących na forward
* @return 1 jeśli wywołano jakąś funkcję oczekującą, 0 jeśli nie
*/
ExecuteForward ( forward_handle, &ret, ... )


Przykład:
new gFW;
public plugin_init(){
	gFW = CreateMultiForward("jakies_zdarzenie", ET_CONTINUE, FP_FLOAT, FP_CELL, FP_STRING);
}
public plugin_cfg(){
	new iRet;
	ExecuteForward(gFW, iRet, 3.14, -5, "Pi");
}
Tak podane parametry są jak najbardziej w porządku. Inaczej ma się sprawa z type FP_ARRAY. Nie podajemy bezpośrednio tablicy, ale rezultat funkcji
/**
* Przygotowuje tablicę do przekazania do forwardu
*
* @param array[] Tablica wejściowa
* @param size Ilość komórek
* @param copyback Czy tablica zmieniona przez funkcje oczekującą ma wrócić
*/
PrepareArray(array[], size, copyback=0 )


Ostatni parametr jest dosyć ciekawy. Wynika z niego, że oprócz podania danych do forwardu możemy także z niego uzyskać. Ustawiając 0 mamy normalne przekazanie, podając 1 funkcje oczekujące będą pracować niejako na tej tablicy.
 
new gFW;
public plugin_init(){
	gFW = CreateMultiForward("jakies_zdarzenie", ET_CONTINUE, FP_CELL, FP_ARRAY);
}
public plugin_cfg(){
	new data[2];
	data[0] = 0;
	data[1] = 1;	

	new iRet;
	ExecuteForward(gFW, iRet, 0, PrepareArray(data, 2, 1));
	
	//data[0] == 0? możliwe, że już nie!
}
4. Przykłady
w załączniku xD
plik udostępniający i korzystający z forwardu w jednym pliku odzielone kreskami

ex1 - tylko wywołanie
ex2 - z analizą z wyniku (istotne co funkcje oczekujące zwracają)
ex3 - przekazywanie tablicy
ex4 - przekazywanie tablicy i powrót wyniku

Załączone pliki

  • Załączony plik  ex.rar   2,48 KB  325 Ilość pobrań

  • +
  • -
  • 18


#200655 Bomb Blast

Napisane przez DaddyKuba w 28.12.2010 22:33

Dołączona grafika
Prosty plugin, dodaje blasta gdy podłożymy bombę i mruga on przez całe odliczanie bomby.

Dołączona grafika
bb_color "250250250"
Ustawiamy kolor RRRGGGBBB

Generator koloru:
Tester kolorów

Dołączona grafika
1. Plik bomb_blast.amxx wrzucamy do: addons/amxmodx/plugins
2. Plik bomb_blast.sma wrzucamy do: addons/amxmodx/scripting
3. Do pliku plugins.ini (addons/amxmodx/configs) dopisujemy na końcu: bomb_blast.amxx
4. Restartujemy serwer lub zmieniamy mape.

Dołączona grafika
Dołączona grafika

Dołączona grafika
- amxmodx
- engine
- fakemeta
- hamsandwich

Dołączona grafika

Załączone pliki


  • +
  • -
  • 9


#209388 [5.9l] Naprawa mocy pistoletowej maga

Napisane przez sebul w 25.01.2011 21:45

Na sam początek polecam wgranie tej poprawki -> [5.9l] Moce pistoletowe wybranych klas nie działają - AMXX.pl: Support AMX Mod X
Jak pewnie większość z Was wie, mag w swoim opisie ma coś takiego

Strzelajac z pistoletu zamrazasz wroga i zabierasz mu 5hp co 2 sek przez 15 sek.

ale tak naprawdę te zabieranie hp co 2 sek nie działa. Pokażę jak to naprawić.
Spoiler

Przy okazji po raz drugi podziękowania dla Pavulona i R3Xa ;] za wytłumaczenie co i jak z przenoszeniem w tasku więcej niż tylko id.
  • +
  • -
  • 8


#165485 DeathRun Timer + Save Records

Napisane przez Knopers w 29.08.2010 14:20

Plugin : DeathRun Timer + Save Records v2.1
Autor : Knopers UnBugged by Owner123



Opis :
Plugin odmierza każdemu (w CT) czas od spawnu aż do zabicia siebie lub zabicia terrorysty.
Po zabiciu terrorysty wyświetla wszystkim kolorową wiadomość z czasem jakim przeszedł dany gracz mapę.
Dodatkowo Plugin zapisuje najlepszy czas mapy (rekord). Można go zobaczyć wpisując w say /best.
Rekordy zapisują się w Nvaulcie lub Bazie MySQL.
Plugin posiada również funkcję tworzenia przycisków Startu i Końca.


Opis przycisków: Jeśli postawicie start a konca nie to koniec będzie w momencie zabicia TT, jeśli postawicie koniec a początku nie to początek będzie po zrespieniu się, jeśli żadnego nie ustawicie będzie wszystko po staremu.
Przyciski posiadają model c4 czyli paki jeśli chcecie mieć własne wystarczy w pliku timer.sma zmienić linijkę
//#define _CustomButtons
na
#define _CustomButtons
Po kompilacji modele będą brane z dwóch ścieżek :
"models/drtimer/button_start.mdl"
"models/drtimer/button_end.mdl"
aby je zmienić trzeba edytować plik timer/button.inl.
Uwaga!! Aby przyciski działały, zapisywały się należy utworzyć folder o nazwie "drtimer" w addons/amxmodx/configs

Moduły : nvault or mysql, hamsandwich, engine, fakemeta

Komenda : /best
Komenda dla admina : /drtimermenu - Otwiera menu ustawiania przycisków (Flaga ADMIN_CFG)

Cvar : amx_timer_type "2" //1 - Timer wyświetlany w hud, 2- Timer wyświetlany w statusie (pod sayem)

Standardowo Plugin ustawiony jest na zapis do Nvaulta aby to zmienić należy edytować plik timer.sma :
Znaleźć:
#define RecordsSaveTo 1 // 1 - Nvault, 2 - MySQL (Standardowo linijka 10)
Zamienić na :
#define RecordsSaveTo 2 // 1 - Nvault, 2 - MySQL
Skompilować i zainstalować.

Cvary w trybie MySQL :

timer_sql_host "127.0.0.1" //Host MySQL'a
timer_sql_user "root" //Użytkownik MySQL
timer_sql_pass "password" //Hasło Użytkownika MySQL
timer_sql_database "baza123" //Nazwa Bazy danych

Changelog
v 1.0 - Pierwsza wersja
v 1.1 - Poprawiony Bug przy zapisie do Nvault
v 1.2 - Dodany tryb zapisu MySQL
v 1.3 - Dodano Dodatkowe komunikaty oraz czas gracza obserwowanego (po śmierci lub na spect.)
v 2.0 - Dodano możliwość tworzenia guzików startu i końca + naprawiono kilka bugów.
v 2.1 - Poprawione Bugi Guzików oraz Naliczana Czasu (by Owner)
WWW Stats (Tylko pod zapis do MySQL'a)
Statystyki pisane od zera by Me :P
Cała Konfiguracja statystyk znajduje się w pliku config.php (wszystko opisane).
Nie wymaga żadnej instalacji wystarczy wrzucić na serwer www i działa (oczywiście jeśli wszystko jest skonfigurowane)

Dodałem statystyki ponieważ niektórzy już mi chcą flaki wyrwać i zamęczyć mnie na śmierć więc nie czepiać się o wygląd i nieczytelność/nie optymalność kodu w plikach *.php .

Demo: http://knopers.com.pl/stat/

Download: Załączony plik  stat.rar   126,98 KB  672 Ilość pobrań
Załączony plik  stat.rar   127 KB  2749 Ilość pobrań


PS: Przyciski jak by ktoś chciał to można pobrać stąd: Załączony plik  models.rar   5,96 KB  2718 Ilość pobrań


Zakaz kopiowania na inne fora bez podania źródła oraz autora pluginu

Załączone pliki


  • +
  • -
  • 30


#205841 Szukam pluginów do zombie moda

Napisane przez kasza w 14.01.2011 16:44

Informator - Nieoficjalny polski support AMX Mod X
  • +
  • -
  • 3