Stonetavern

Księga.

Co postanowiono, co czeka i co mieliśmy źle. Większość projektów serwerowych publikuje pierwsze z tych trzech. Ta strona istnieje dlatego, że trzecie jest jedynym, które cokolwiek ci mówi.

Jak stoją sprawy

Część tego niewygodnie się zapisuje. Wciąż lepiej, niż gdybyś natknął się na to sam.

  • Utrata przedmiotów na Elwynn

    czeka na okno serwisowe

    Postaciom ginęły przedmioty, które leżały w ich torbach. Przyczyna jest zrozumiana, a poprawka jest już w konfiguracji, ale działający serwer nigdy jej nie odczytał. Zadziała dopiero po restarcie, a ten nie został jeszcze zaplanowany. O Barrens nic nam nie wiadomo i ważymy słowa: brak potwierdzonego przypadku w danych, które sprawdziliśmy, to nie to samo co wykluczone.

  • Podwójne doświadczenie dla już otwartych przedziałów

    czeka na okno serwisowe

    Zbudowane i zmierzone na wersji testowej, i celowo niewłączone. W tej chwili nie ma czego nadrabiać, bo świat otworzył dopiero jeden przedział. Jest przewidziane na moment, w którym otworzy się kolejna faza.

  • Nikt nie jest budzony, gdy świat pada w nocy

    otwarte

    Prace nad monitoringiem trwają, a dopóki nie będzie gotowy, awarię poza naszymi godzinami czuwania gracze zauważą wcześniej niż my. Jeśli świat leży i jest cicho, napisanie nam na Discordzie to naprawdę najszybsza droga.

  • Planer wyposażenia pokazuje przedmioty, których tu nie ma

    otwarte

    Gracz to zgłosił i gracz ma rację. Planer powstał na podstawie zrzutu drugiego świata, wykonanego zanim Barrens istniał, i nie wie, na jakim etapie treści działa ten świat. Chętnie zaproponuje więc postaci na 19 poziomie wyposażenie rajdowe z łatki, do której ten świat nigdy nie dotarł. Jest na liście, a poprawka musi być powiązana z harmonogramem faz, inaczej znów się zdezaktualizuje, gdy tylko świat ruszy dalej.

  • Zadania wędkarskie, których gracz nie mógł znaleźć

    zrobione

    Też słusznie zauważone i też nie jest to błąd. Te zadania należą do późniejszego etapu treści niż ten, na którym stoi świat. Pojawią się, gdy świat do niego dojdzie.

Pięć rzeczy, które mieliśmy źle, wyłapanych przed wdrożeniem.

Każdą pracę tutaj czyta ponownie drugi, niezależny recenzent, zanim w ogóle zbliży się do świata. Te pięć wyłapano właśnie tak. Są wymienione, bo łączy je jedna cecha, którą warto zrozumieć.

  • Zbudowaliśmy kontrolę stanu, która nie widziałaby awarii, dla której powstała

    zrobione

    Pukanie do usługi z zewnątrz nie mówi nic, jeśli ta usługa restartuje się sama w kilka sekund. Kontrola świeciłaby na zielono przez całą awarię, dla której ją napisano.

  • Zaplanowaliśmy zgodę, która niczego by nie dopuściła

    zrobione

    Pomylono dwie różne rzeczy: kto może się zalogować i które połączenia są przepuszczane. Naprawa pierwszej zostawiłaby drugą dokładnie tak samo zamkniętą jak wcześniej.

  • Odnowiliśmy konto alarmowe i nigdzie tego nie zapisaliśmy

    zrobione

    Wszystkie alarmy by zamilkły, podczas gdy sama konfiguracja meldowałaby sukces.

  • Napisaliśmy poradnik, który po cichu wyłączyłby to, co włącza

    zrobione

    Podmieniał plik konfiguracyjny w sposób, którego działająca usługa nigdy nie odczytuje ponownie. Na zewnątrz nowa wartość, w środku stare zachowanie, i nigdzie żadnego komunikatu o błędzie.

  • Twierdziliśmy, że Barrens nie jest dotknięty, nie mogąc tego pokazać

    zrobione

    Zrzuty czatu, które czytaliśmy, kończą się przed otwarciem świata, więc rozmów po starcie po prostu w materiale nie było. Uczciwa wersja brzmi: brak potwierdzonego przypadku w danych, które sprawdziliśmy. I tak to teraz mówimy.

Każda z tej piątki zgłosiłaby sukces. Żadnego błędu, żadnego ostrzeżenia, nic na czerwono. To ten rodzaj awarii, przed którym trzeba się bronić na serwerze, któremu ludzie powierzają swój czas, i dlatego nic tu nie trafia na produkcję dlatego, że wyglądało dobrze.