Jak debugować błędy?

 

Błędy nakładki (frontend)

O testowaniu i debugowaniu błędów GUI traktuje osobny artykuł: Jak tworzyć i testować GUI?

 

Gothic.exe podczas błędu

Generalnie platforma stara się utrzymać proces Gothic.exe przy życiu, co oznacza, że podczas błędu NodeJS albo komendy (o szczegółach niżej), gra powinna się tylko zawiesić, a nie wyłączyć. Działa to tak, dlatego że Gothic.exe do renderowania każdej klatki potrzebuje aktywnego serwera NodeJS z trybem gry. Kiedy pojawia się błąd, serwer się zatrzymuje, a gra przestaje renderować dalej. W momencie gdy ponownie uruchomisz serwer, gra nawiąże z nim połączenie i wznowi swoje działanie. Dzięki temu będziesz mógł spróbować naprawić błąd szybciej, nie tracąc stanu rozgrywki.

Błędy NodeJS

Tutaj sytuacja jest bardzo komfortowa, w przypadku każdego błędu dostaniesz informacje o nim oraz dokładny stack trace. Np. przy próbie wywołania player.Npc.GetFocusNpc()!.GetObjectName() gdy nie masz obecnie focusa skierowanego na NPCta, otrzymasz błąd: TypeError: Cannot read properties of null (reading 'GetObjectName') at GameMode.OnPlayerCommand (gamemode.ts:187:30). Przy produkcji wielu modyfikacji do Gothica jedynym błędem jest wyłączenie się gry, tutaj dostajesz dokładną informację na czym polega problem.

 

Błędy komend

Gdy używasz w TypeScriptcie np. metody player.Npc.GetFocusNpc(), do Gothic.exe zostaje wysłana komenda opisująca co nasza DLL-ka integrująca TS z Gothickiem ma zrobić. Jeżeli ta logika się nie powiedzie, bo np. wykonujesz operację GetFocusNPC()na NPC, którego nie ma, błąd będzie nieco inny. Stwórzmy sobie nieistniejącego NPCta dla przykładu: new oCNpc("invalid-uuid").GetFocusNpc(). Każdy NPC na platformie ma unikalny identyfikator, który otrzymuje podczas tworzenia, tutaj napisaliśmy losową wartość. Błąd będzie wyglądać tak: 


Z punktu widzenia TypeScriptu jest to poprawna operacja, natomiast zdecydowanie błędna dla Gothica, gdyż taki NPC nie istnieje. Serwer NodeJS zostanie wtedy zatrzymany tak samo jak w przypadku błędów TypeScripta.

 

Crashe Gothica

Czy to wszystko sprawia, że nigdy nie ma crashy? Niestety nie, weźmy sobie na przykład poprawny kod, który np. zmienia logikę rutyny na NPCie. Wywołania metod będą prawidłowe, NPC również dobry, niestety przy kolejnej klatce, jeżeli coś namieszaliśmy, pojawi się stary i poczciwy Access Violation. Nie jest to niestety w pełni do uniknięcia, błąd ten bowiem nie jest związany z wykonaniem żadnej operacji, a konsekwencją np. wprowadzenia złych danych i crashem gry w momencie ich użycia (przy np. kolejnej klatce albo zmianie czasu). Co zrobić w takiej sytuacji? Czasami sporo można wyczytać z samego błędu, warto regularnie i gruntownie testować swoje zmiany, wtedy gdy gra zacznie losowo crashować będziesz mieć punkt zaczepienia. Używając GIT-a możesz cofnąć swoje zmiany do wersji np. sprzed tygodnia, i sukcesywnie sprawdzać kiedy gra zaczyna crashować. Nie ma w tym procesie niestety nic przyjemnego poza końcowym momentem, kiedy zrozumiesz o co chodzi i poczujesz ogromną radość z rozwiązania problemu.

 

Error tracker

W przypadku budowania większych projektów warto dodać error tracker do projektu. Działają one na zasadzie: gdy pojawi się błąd, wyślij potrzebne informacje na serwer trackera i powiadom właściciela. Dzięki temu gdy grając w Twój tryb NodeJS rzuci błędem, dostaniesz powiadomienie email. Tych narzędzi jest naprawdę dużo, natomiast w GT używamy Sentry. Możesz zerknąć na ich integrację z NodeJS tutaj: https://sentry.io/for/node/