server.cfg bez tajemnic: linijki, które naprawdę mają znaczenie
Otwórz katalog dowolnego serwera FiveM, a zawsze go znajdziesz: server.cfg. To pierwszy plik, który FXServer wczytuje przy starcie, i to on decyduje, jak nazywa się Twój serwer, ilu graczy może wejść jednocześnie i które zasoby działają. Mimo to wielu początkujących adminów traktuje go jak magiczny plik, od którego lepiej trzymać się z daleka. Szkoda, bo kto rozumie server.cfg, sam rozwiązuje połowę wszystkich problemów ze startem. W tym artykule przechodzimy przez linijki, które naprawdę mają znaczenie, oraz te, które w ogóle nie powinny się tam znaleźć.
Jak FXServer czyta Twój server.cfg
server.cfg to nie kod programu, tylko lista poleceń. FXServer czyta plik od góry do dołu i wykonuje każdą linijkę po kolei. Brzmi banalnie, ale od razu wyjaśnia, dlaczego kolejność jest ważna: skrypt, który opiera się na frameworku, musi wystartować po tym frameworku. Linijki zaczynające się od # to komentarze i są pomijane. Korzystaj z nich hojnie, żeby podzielić plik na bloki, bo po roku majsterkowania nieuporządkowany config to labirynt.
Jeśli działasz z txAdmin, jak to jest standardem na serwerach FiveM od MC-Node, podczas konfiguracji wskazujesz server.cfg, a potem edytujesz go przez menedżer plików lub SFTP. Ważne, żeby zapamiętać: zmiany convarów zaczynają działać dopiero po pełnym restarcie serwera. Samo przeładowanie zasobu nie wystarczy.
Convary, które naprawdę mają znaczenie
Convary to ustawienia Twojego serwera. Oto zdrowa baza:
# lista serwerów i prezentacja
sv_hostname "Moje miasto RP | Polski | Whitelist"
sets sv_projectName "Moje miasto RP"
sets sv_projectDesc "Polski roleplay z własnymi skryptami"
sets tags "roleplay, polski, whitelist"
sets locale "pl-PL"
# technikalia
sv_maxclients 48
set onesync onsv_hostnameto nazwa na liście serwerów;sv_projectNameisv_projectDescwypełniają kartę serwera wokół niej. Bądź konkretny: "Polski RP | Whitelist | 18+" przyciąga dokładnie tych graczy, których chcesz, "Server123" nikogo.sets tagsisets localedecydują o tym, jak łatwo Cię znaleźć. Gracze naprawdę filtrują listę serwerów po języku i tagach, więc ustawlocalenapl-PL, jeśli celujesz w polskich graczy. Jeśli Twojego serwera w ogóle nie ma na liście, przyczyną jest zwykle problem z licencją albo configiem.sv_maxclientsto maksymalna liczba graczy jednocześnie; domyślnie jest to 48. Nie ustawiaj wysokiej wartości na pokaz, tylko wybierz coś, co pasuje do Twojego pakietu i społeczności.set onesync onwłącza OneSync, nowoczesny model synchronizacji FXServer. Przy więcej niż 48 slotach OneSync jest i tak obowiązkowy, a Cfx.re stawia dodatkowe warunki. W bazie wiedzy przeczytasz, jak włączyć OneSync.
Zwróć też uwagę na różnicę między set, setr i sets. Z set wartość zostaje na serwerze, setr udostępnia ją grze Twoich graczy, a sets czyni ją publicznie widoczną na liście serwerów. Wszystko, co ustawisz przez sets, może więc przeczytać każdy; nigdy nie wpisuj tam niczego, co ma zostać prywatne.
A sv_licenseKey? Formalnie też należy do tego zestawu, ale jeśli używasz txAdmin, klucz licencyjny podajesz w kreatorze konfiguracji i od tej pory txAdmin zarządza nim za Ciebie. Nie musisz go wtedy sam wpisywać do server.cfg, i to jest zarazem najbezpieczniejsze rozwiązanie.
ensure: Twoje zasoby we właściwej kolejności
Większość przeciętnego server.cfg to linijki ensure. ensure uruchamia zasób, a jeśli ten już działa, restartuje go. Czasem zobaczysz też starsze start; działa, ale ensure to solidniejszy nawyk. Zasada kciuka dla kolejności: najpierw fundament, potem to, co na nim stoi.
# fundament: baza danych i framework
ensure oxmysql
ensure es_extended
# dopiero potem skrypty, które na nich polegają
ensure esx_garage
ensure moj_jobscriptJeśli uruchomisz skrypt pracy, zanim wystartuje framework, skrypt się wysypie albo będzie czekał w nieskończoność, a Ty dostaniesz konsolę pełną czerwonych komunikatów. Niektóre zasoby porządnie deklarują swoje zależności w fxmanifest.lua, ale nie polegaj na tym w ciemno: logiczna kolejność w server.cfg zapobiega dziewięciu na dziesięć problemów ze startem.
To nie powinno znaleźć się w Twoim server.cfg
Co najmniej równie ważne jest to, co pomijasz:
- Hasła i tajne klucze. Chodzi np. o hasło do bazy danych w connection stringu albo klucze API zewnętrznych usług. Problem w tym, że server.cfg to dokładnie ten plik, który ludzie kopiują i udostępniają, gdy gdzieś proszą o pomoc. Udostępniaj config wyłącznie z wyciętymi wszystkimi sekretami i traktuj ten plik tak, jakby kiedyś miał stać się publiczny.
rcon_password, chyba że naprawdę używasz rcon. Z txAdmin rcon jest rzadko potrzebny, a słabe hasło rcon to otwarta tylna furtka do Twojej konsoli. Lepiej całkiem pomiń tę linijkę.- Martwe linijki. Ensure zasobów, które dawno usunąłeś, zakomentowane eksperymenty sprzed miesięcy: posprzątaj je. Każda linijka, której już nie rozumiesz, to przyszłe zamieszanie.
Najczęstsze błędy
- Podwójne ensure. Uruchomienie tego samego zasobu dwa razy zdarza się szybciej, niż myślisz, zwłaszcza gdy wkleisz przykładowy config na własne linijki. Zwykle nic się nie psuje, ale konsola narzeka, a debugowanie robi się niepotrzebnie mylące.
- ensure bez zasobu. Usuwasz katalog zasobu, ale zapominasz o linijce. Efekt: komunikat "Couldn't find resource" przy każdym starcie. Niegroźny, ale zaśmieca konsolę, przez co przeoczysz prawdziwe błędy.
- Nazwy, które prawie się zgadzają. Nazwa w ensure musi dokładnie odpowiadać nazwie katalogu zasobu, łącznie z wielkością liter i myślnikami. Spacje w nazwach katalogów to i tak proszenie się o kłopoty.
- Zapomniany restart. Zmieniasz
sv_maxclients, nie widzisz żadnej zmiany i szukasz dalej, a zmiana po prostu nie została jeszcze wczytana.
Przy niemal wszystkich tych błędach obowiązuje jedno: konsola na żywo w txAdmin dosłownie mówi Ci, co idzie nie tak. Przy każdym starcie przejrzyj pierwsze komunikaty; zajmuje to trzydzieści sekund i oszczędza godziny zgadywania.
Szczerze: perfekcja nie jest konieczna
server.cfg nie musi być dziełem sztuki. Dobry config to plik z czytelnymi blokami, logiczną kolejnością ensure i bez sekretów w środku. Zacznij od małego, dodawaj po jednym zasobie na raz, a zawsze będziesz wiedzieć, skąd wziął się problem. Gdy serwer rośnie, config rośnie razem z nim, i wtedy porządna baza zwraca się podwójnie.