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 serwisowePostaciom 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 serwisoweZbudowane 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
otwartePrace 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
otwarteGracz 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źć
zrobioneTeż 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
zrobionePukanie 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
zrobionePomylono 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
zrobioneWszystkie 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
zrobionePodmieniał 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ć
zrobioneZrzuty 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.