[AMXX] Diagnozowanie problemów z pluginami
R3X
23.08.2011
Diagnozowanie problemów z pluginami
Zdecydowana większość problemów z pluginami zostawia po sobie wyraźne ślady. Ich odnalezienie i interpretacja to połowa sukcesu w walce z niedziałającym dodatkiem.
1. Stan pluginu
Podstawową informacją o pluginie jest to czy się w ogóle załadował. Najłatwiej to sprawdzić wpisując w konsoli:
Efektem będzie listing podobny do tego:

Wszystkie pluginy mają status running, więc wszystkie zostały poprawnie załadowane. No i pozytywnie
Innym, równie dobrym statusem jest debug, to jest takie running, ale przygotowane na błędy
Mniej przyjemniej jest kiedy ilość przeczytanych pluginów nie zgadza się z ilością załadowanych. Częsty problemem jest status bad load

Oznacza to tyle, że w katalogu plugins/ nie ma wskazanego w plugins.ini pliku.
(W skrajnych przypadkach plik może istnieć, ale nie uprawniać serwera do odczytu. Ustawienie chmodu 644 załawiłoby sprawę.)
Inny kiepskim przypadkiem jest status error. Pojawia się wtedy, gdy przetwarzanie pluginu zostanie przerwane, np. za pomocą funkcji set_fail_state

jeśli komunikat jest niejasny, niezrozumiały jedynym wyjściem jest zajrzenie do źródła pluginu i sprawdzenie przyczyny
Rzut okiem i mam winowajcę
Jest jeszcze stan paused i stopped, są one związane z komendą amx_pausecfg w plikach konfiguracyjnych oraz funkcją (un)pause() w pluginach. W takim przypadku należy sprawdzić wszystkie wczytanie configi, zwykle są to: amxx.cfg z configs, server.cfg z cstrike/ i configs/maps/NAZWAMAPY_LUB_PREFIX.cfg oraz upewnić się, że żaden plugin nie zatrzymuje naszego niedziałającego dodatku.
2. Logi
Gdy mamy pewność, że plugin został załadowany przyszedł czas na szperanie w plikach. Logi, czyli zapisy czynności, są zapisywane w folderze addons/amxmodx/logs/.
Logi zwyczajne są nazywane w formacie L<RRRRMMDD>.log a logi błędów error_<RRRRMMDD>.log. Informacje o problemach mogą się pojawić i w jednych i w drugich. Zgłoszone błędy całkowicie wyjaśniają powód problemów tylko kiedy plugin ma status debug. Aby wymusić ten stan należy w plugins.ini dopisać debug po nazwie pluginu, np.
3. Komendy nie reagują
Problem występuje zwykle, kiedy 2 pluginy dostarczają takie same komendy. W tej sytuacji zwycięzca bierze wszystko: pierwszy plugin na liście plugins.ini przetworzy komendę i zablokuje ją, przez co żaden inny plugin nie zostanie nawet o niej poinformowany. Rozwiązaniem jest zmiana kolejności ładownia albo zmiana nazw komendy. Istnieją pluginy, które blokują więcej komend niż przetwarzają, np. blokują wszyskie komendy say z / na początku. Takie pluginy powinny znajdować się na samym końcu listy.
Zdecydowana większość problemów z pluginami zostawia po sobie wyraźne ślady. Ich odnalezienie i interpretacja to połowa sukcesu w walce z niedziałającym dodatkiem.
1. Stan pluginu
Podstawową informacją o pluginie jest to czy się w ogóle załadował. Najłatwiej to sprawdzić wpisując w konsoli:
amx_showrcon amxx list
Efektem będzie listing podobny do tego:

Wszystkie pluginy mają status running, więc wszystkie zostały poprawnie załadowane. No i pozytywnie
Innym, równie dobrym statusem jest debug, to jest takie running, ale przygotowane na błędy
Mniej przyjemniej jest kiedy ilość przeczytanych pluginów nie zgadza się z ilością załadowanych. Częsty problemem jest status bad load

Oznacza to tyle, że w katalogu plugins/ nie ma wskazanego w plugins.ini pliku.
(W skrajnych przypadkach plik może istnieć, ale nie uprawniać serwera do odczytu. Ustawienie chmodu 644 załawiłoby sprawę.)
Inny kiepskim przypadkiem jest status error. Pojawia się wtedy, gdy przetwarzanie pluginu zostanie przerwane, np. za pomocą funkcji set_fail_state

jeśli komunikat jest niejasny, niezrozumiały jedynym wyjściem jest zajrzenie do źródła pluginu i sprawdzenie przyczyny
Rzut okiem i mam winowajcę
public plugin_init() {
register_plugin(PLUGIN, VERSION, AUTHOR)
if(5 > 2)
set_fail_state("nie chce mi sie");
}W tym przypadku to tylko głupi żart programisty, zwykle problemy są o wiele poważniejsze.Jest jeszcze stan paused i stopped, są one związane z komendą amx_pausecfg w plikach konfiguracyjnych oraz funkcją (un)pause() w pluginach. W takim przypadku należy sprawdzić wszystkie wczytanie configi, zwykle są to: amxx.cfg z configs, server.cfg z cstrike/ i configs/maps/NAZWAMAPY_LUB_PREFIX.cfg oraz upewnić się, że żaden plugin nie zatrzymuje naszego niedziałającego dodatku.
2. Logi
Gdy mamy pewność, że plugin został załadowany przyszedł czas na szperanie w plikach. Logi, czyli zapisy czynności, są zapisywane w folderze addons/amxmodx/logs/.
Logi zwyczajne są nazywane w formacie L<RRRRMMDD>.log a logi błędów error_<RRRRMMDD>.log. Informacje o problemach mogą się pojawić i w jednych i w drugich. Zgłoszone błędy całkowicie wyjaśniają powód problemów tylko kiedy plugin ma status debug. Aby wymusić ten stan należy w plugins.ini dopisać debug po nazwie pluginu, np.
test.amxx debugW stanie running komunikaty są okrojone i nie lokalizują konkretnie źródła błędu, natomiast w debugu mamy informacje o ścieżce wywołania, czyli co i w której linijce po kolei się wykonywało zanim wystąpił problem. Ścieżka sięga ostatniej funkcji wywołanej przez moduł.
3. Komendy nie reagują
Problem występuje zwykle, kiedy 2 pluginy dostarczają takie same komendy. W tej sytuacji zwycięzca bierze wszystko: pierwszy plugin na liście plugins.ini przetworzy komendę i zablokuje ją, przez co żaden inny plugin nie zostanie nawet o niej poinformowany. Rozwiązaniem jest zmiana kolejności ładownia albo zmiana nazw komendy. Istnieją pluginy, które blokują więcej komend niż przetwarzają, np. blokują wszyskie komendy say z / na początku. Takie pluginy powinny znajdować się na samym końcu listy.
A może sma?
23.08.2011
Warto dodać, że jest cvar:
Użytkownik A może sma? edytował ten post 23.08.2011 23:31
// Plugin Debug mode // 0 - No debugging (garbage line numbers) // wyłączone debugowanie // 1 - Plugins with "debug" option in plugins.ini are put into debug mode // debugowanie pluginów które mają dopisane debug w plugins.ini // 2 - All plugins are put in debug mode // debugowanie wszystkich pluginów // Note - debug mode will affect JIT performance // Debugowanie zmniejsza w jakimś tam stopniu (zależnie od pluginu) wydajność serwera // // Default value: 1 // Domyślna wartość: 1 amx_debug 1odpowiadający za debugowanie pluginów. Jeżeli ktoś go przypadkowo zmienił może mieć problem z uzyskaniem error logów
Użytkownik A może sma? edytował ten post 23.08.2011 23:31
Scotty
28.08.2011
warto też dodać że gdy jest badload to może też znaczyć że nie ma jakiegoś modułu, pare razy się z tym spotkałem
A może sma?
28.08.2011
Oraz wtedy, gdy plugin korzysta z natywu, który nie jest zarejestrowany w żadnym innym pluginie (nie istnieje)
Skull3D
12.09.2011
R3X mógłbyś napisać jeszcze co zrobić jak wgramy plugin a serwer nie chce się właczyć bo pokazuje się teraz o wiele więcej takich tematów niż poprzednio.
mierzwi
13.09.2011
blokadę włączenia serwera może wymusić serwer przez komendy lub po prostu brak wgranych plików wymaganych do włączenia (mówię tutaj np. o modelach, spritach)R3X mógłbyś napisać jeszcze co zrobić jak wgramy plugin a serwer nie chce się właczyć bo pokazuje się teraz o wiele więcej takich tematów niż poprzednio.
Użytkownik LKZ (funfel) edytował ten post 13.09.2011 17:33
Konrad26
29.01.2021
Witam ta Komenda mi nie działa
amx_showrcon amxx list
W konsoli pokazuje takie coś
amx_showrcon amxx list
rcon_password is a privileged variable
Could not execute privileged command rcon amxx list
vanillah
30.01.2021
Witam ta Komenda mi nie działa
amx_showrcon amxx list
W konsoli pokazuje takie coś
amx_showrcon amxx list
rcon_password is a privileged variable
Could not execute privileged command rcon amxx list
co do tej komendy to wystarczy w konsoli serwera wpisac
amx_plugins i ci pokaze czy plugin sie zaladowal




