Patch 2 lipca 2024

Witajcie Paxianie!

Nasze serwery będą w trakcie konserwacji w dniu 2 lipca 2024 r. o godzinie 13:00, aby wdrożyć łatkę wprowadzającą kilka zmian, a także kilka poprawek błędów. Oto kilka punktów, które mogą zainteresować niektórych z Was:

• Dodano opcję odwracania myszy
• Zwiększono częstotliwość pojawiania się gliny, lnu i nieczystego żelaza oraz liczbę miejsc pojawiania się
• Naprawiono błąd, przez który niedźwiedzie brunatne nie upuszczały łupów
• Naprawiono błąd powodujący teleportację gracza na środek bieżącej mapy, a nie do jego domowej świątyni, jeśli znajdowała się ona w innej prowincji

Pamiętaj również, że pracujemy nad osobną poprawką, która rozwiąże problem związany z niepoprawnym działaniem uprawnień do skrzyń i klanu. Zostanie wdrożony, gdy tylko będzie gotowy.

Na marginesie, nasze zespoły badają problem polegający na tym, że gracz nie może uzyskać dostępu do kontenerów, rzemieślników i nagrobków, ani podnieść przedmiotów, jeśli w pobliżu stoi inny gracz. Obecnie nie mamy żadnego przewidywanego czasu dotyczącego rozwiązania tego problemu.

Dziękujemy wszystkim, którzy już udostępnili swoje zrzuty ekranu na kanałach udostępniania multimediów. Prosimy o dalsze udostępnianie!

Pax vobiscum,
Zespół Mainframe

Szczegóły w artykule Pax Dei patch notes - 2.07.2024

Patch Notes - 26.06.2024

Witajcie Paxianie,

Dzisiaj jest nasza pierwsza aktualizacja klienta od początku wczesnego dostępu. Ma na celu naprawienie niektórych z najbardziej irytujących błędów, z którymi się spotykasz.

Poprawki błędów:

• Naprawiono błąd powodujący brak odpowiedzi wielu funkcji związanych z klanem.
• Naprawiono problem z własnością kontenerów, który sprawiał, że były one niedostępne dla wszystkich.
• Naprawiono błąd, w wyniku którego gracze korzystający z programu uruchamiającego zacinali się podczas próby zalogowania.
• Naprawiono różne problemy z awariami.
• Poprawiono niezawodność poprawki odradzania się NPC.

Badamy poniższe problemy i zapewniamy aktualizację tak szybko, jak to możliwe.

• Węzły wydobywcze stają się nieinteraktywne – nadal mamy problem z ich odtworzeniem w 100% przypadków.
• Problemy z umieszczaniem niektórych rekwizytów – głównie ławek, rzemieślników i skrzyń – pracujemy nad rozwiązaniem.
• Teleportacja do domu nie działa, gdy znajdujesz się w innym regionie niż Twoja ojczyzna – pracujemy nad rozwiązaniem.

Pax vobiscum,
Zespół Mainframe

Opowieści z pokoju wojennego: klęska DNS

Po kilku dniach bez większych problemów większość zespołu poczuła ulgę i cieszyła się nowym początkiem tygodnia. Ale problemy techniczne dotyczą również poniedziałków i mały błąd może spowodować ogromne problemy. To nasza trzecia historia z War Room i nazywamy ją Klęską DNS – tak, tytuł trochę ją psuje, ale jak niektórzy powiedzieliby: „To zawsze jest DNS”.

O 16:45 UTC niektórzy gracze zaczęli napotykać problemy z logowaniem. Zostali oni nagle rozłączeni i nie mogli się ponownie zalogować do gry. Ponieważ dotknięci gracze byli rozproszeni po różnych regionach, shardach i strefach, nasze systemy monitorujące wykryły jedynie niewielki spadek aktywności użytkowników i nie uruchomiły alarmu. Obserwując naszą aktywną społeczność Discord, jeden z pracowników firmy Mainframe zauważył niepokojący trend i szybko zdecydował się podnieść alarm i aktywować War Room.

O godzinie 17:00 UTC byliśmy w trybie diagnostycznym. Problem dotyczył logowania i zaczynał obejmować znaczną (i stale rosnącą) część naszej bazy graczy. Chociaż nadal mieliśmy dużą liczbę aktywnych graczy, krzywa była płaska lub zaczynała spadać – dokładnie wtedy, gdy powinna rosnąć. Nasze wstępne badanie obejmujące monitorowanie, wskaźniki, wykresy i alerty wskazało na kilka potencjalnych przyczyn. Jedna z naszych centralnych usług odpowiedzialnych za logowanie odnotowywała zwiększone obciążenie procesora, a w logach głównego systemu uwierzytelniania pojawiały się błędy. Dodatkowo zauważyliśmy problemy z systemem zarządzającym uprawnieniami (ustalającym, kto posiada grę i jaki typ licencji posiada) i postanowiliśmy się temu przyjrzeć, skupiając się na najbardziej prawdopodobnych winowajcach.

O godzinie 17:20 UTC postanowiliśmy ponownie uruchomić system uwierzytelniania, co wydawało się być przyczyną problemów. Z perspektywy czasu był to błąd. Ponieważ gracze już borykali się z problemami z logowaniem i ciągle próbowali ponownie. Ponowne uruchomienie systemu zaostrzyło problem. Skończyło się na tym, że musieliśmy tymczasowo zamknąć wszystkie żądania uwierzytelnienia, aby umożliwić ustabilizowanie się systemu, a ponieważ gra musiała regularnie odświeżać swoje tokeny uwierzytelniające, oznaczało to, że z biegiem czasu wszyscy gracze nie mogli kontynuować gry.

Po ponownym uruchomieniu naszego systemu uwierzytelniania postanowiliśmy ponownie zezwolić na wszystkie żądania kierowane do systemu. Ponieważ teraz wszyscy nasi gracze próbowali zalogować się jednocześnie, wcześniej zauważony problem z systemem uprawnień stał się rażąco oczywisty. System został przeciążony i całkowicie przeszedł w tryb offline, co oznaczało, że nawet ci użytkownicy, którym udało się połączyć, wyglądali, jakby nie posiadali już gry. W tym momencie wiedzieliśmy, że musimy walczyć na dwóch frontach jednocześnie. Problem z systemem uprawnień nie mógł czekać na rozwiązanie pierwotnej przyczyny rozłączeń. Na szczęście byliśmy o krok od rozwiązania tego problemu.

Zapytacie, co wywołało to bombardowanie? Niestety, była to rana, którą sam sobie zadałem. Podczas naszej diagnozy odkryliśmy, że niektóre nazwy hostów DNS nie były rozpoznawane poprawnie. Jeden z inżynierów biorących udział w rozmowie zidentyfikował problem — brakujący rekord DNS, a konkretnie krytyczny rekord delegacji NS. Inny inżynier natychmiast zorientował się, co się stało.
Wcześniej tego dnia zadanie porządkowe polegało na usunięciu niepotrzebnej infrastruktury i ten kluczowy zapis został omyłkowo usunięty. Ostatnie polecenia czyszczenia zostały wydane około 16:40 i tak się składa, że ​​domyślny TTL (time-to-live) dla wielu rekordów DNS wynosi dokładnie 5 minut. Kilka ręcznych kroków później rekord został odtworzony i musieliśmy cierpliwie czekać na aktualizację pamięci podręcznych DNS na całym świecie.

Jednakże podstawową przyczyną jest jedynie moment wyzwalający, a ponieważ dyżurujący personel w naszym pokoju wojennym oceniał sytuację i kilku starszych inżynierów zaplecza gotowych do działania, nadal musieliśmy uporać się z problemem związanym z usługą uprawnień. Postanowiliśmy walczyć na dwóch frontach jednocześnie:

• Ścieżka eskalacji i wsparcia. Skontaktowaliśmy się z tą sprawą i przesłaliśmy tę kwestię do wyższego szczebla łańcucha wsparcia dostawcy odpowiedzialnego za przechowywanie uprawnień. Potwierdzili, że są przytłoczeni i obiecali, że rozwiązanie zostanie wkrótce wdrożone. Zegar zaczął tykać o godzinie 17:40 UTC.
• Ścieżka poprawki. Zmodyfikowaliśmy nasz kod uprawnień, aby uwzględnić metodę awaryjną faworyzującą naszych graczy. Gdybyśmy mieli problemy z rozwiązaniem uprawnień, ale gracz posiadał wcześniej określony typ licencji, założylibyśmy, że nadal tak jest i pozwolilibyśmy mu przejść. Mieliśmy już ścieżkę kodu podobną do tej, ale radziła sobie ona z ograniczeniem szybkości. Dodanie przypadku, aby uzyskać podobny wynik w przypadku, gdy usługa uprawnień nie odpowiadała, było łatwym zadaniem, a poprawka została sprawdzona, skompilowana, zbudowana i wdrożona w ciągu 10 minut.

Mieliśmy teraz trzy konie wyścigowe rywalizujące w tym samym wyścigu: nasza poprawka pozwalała graczom na dostęp w czasie, gdy usługa cierpiała, stabilizacja samej usługi uprawnień przy mniejszej liczbie przychodzących żądań i wdrażaniu poprawek oraz aktualizacja pamięci podręcznych DNS na całym świecie w celu rozpoznania odtworzonego rekordu.
Do 18:35 UTC sytuacja znacznie się poprawiła. Nasi gracze logowali się pomyślnie, system uprawnień nadrabiał zaległości, propagacja DNS dobiegała końca, a zespół War Room odwrócił tragiczną sytuację.

Problem z DNS został rozwiązany i byliśmy gotowi na kolejne wyzwanie, które pojawiło się na horyzoncie.