[PORADNIK] Diagnozowanie problemów z pluginami

[NumberOne]

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:

 

 

 

"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.log a logi błędów error_.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 debug"

 

 

 

 

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

 

[Gość Guest]

Przydatne, ale dla zaawansowanych + 

 

 

[infinite.]

Przydatne +