Jump to content

    Locked Migracja na ReHLDS


    Recommended Posts

    • Cała zawartość 2
    • Temat został założony
    • Ostatnia odpowiedź

    Top Posters In This Topic

    Najpopularniejsze posty

    Dawno już nie pisałem żadnego poradnika a taki ciekawy temat mi się ostatnio nasunął. Nie widziałem też podobnego w sieci na ten temat (no dobra jest tego sporo, lecz pomijają pewne rzeczy), być może

    Dawno już nie pisałem żadnego poradnika a taki ciekawy temat mi się ostatnio nasunął. Nie widziałem też podobnego w sieci na ten temat (no dobra jest tego sporo, lecz pomijają pewne rzeczy), być może dlatego że cały proces, który tu opiszę jest raczej prosty =) Nie obiecuje, że ten poradnik pokrywa wszystko, lecz będę się starał podzielić całym swoim doświadczeniem związanym z tym tematem. Proszę wziąć pod uwagę, że prezentuję tutaj swoje własne podejście. Być może spotkacie/spotkaliście się z innym, być może ktoś potrafi to zrobić lepiej. W takiej sytuacji proszę o komentarz. Ponad to wiele hostingów wspiera migracje na ReHLDS oraz pomaga w tym np. 1shot1kill. Pokażę również na przykładzie tego hostingu jak to wszystko jeszcze bardziej przyśpieszyć i uprościć. Od razu mówię, że nie dostaliśmy złamanego grosza za tą krypto reklamę. Ot, po prostu postanowiłem docenić firmę, która idzie z duchem czasu i jest otwarta na opensource ;)

    Podkreślę jeszcze, że poradnik opisuje sam proces migracji starając się przy tym zachować jak najwięcej starych ustawień. Nie poruszam tu wszystkich wątków związanych z ogromem możliwości ReHLDS.

     

    I. Czym w ogóle jest ReHLDS ?

    ReHLDS jest przebudowanym silnikiem HLDS z wersji 6153, uzyskanym w wyniku procesu inżynierii wstecznej. Pozwoliło to wyeliminować liczne błędy z którymi zostawiło nas Valve oraz dokonać optymalizacji kodu. Poprawiło to znacząco bezpieczeństwo rozgrywki, płynność gry oraz zmniejszyło zapotrzebowanie na zasoby systemowe (zwłaszcza procesora, co można sprawdzić komendą "stats"). Obecnie projekt jest oznaczony jako stabilny. Mamy również do wyboru dwie wersje - jedna jest wersją zachowującą dużą kompatybilność wsteczną z HLDS oraz druga eksperymentalna, która wprowadza dużo bardziej agresywne poprawki i optymalizacje, lecz nie zachowuje kompatybilności wstecznej np. z niektórymi pluginami AMXX. Ogólnie jest zalecane używanie pierwszej wersji i tą będziemy się tutaj zajmować, druga powinna raczej służyć do zabawy i testów.

    Gdzie znajdziemy informacje o projekcie ? https://github.com/dreamstalker/rehlds

    Skąd ściągnę ReHLDS ? (niewymagane dla 1s1k) http://nexus.rehlds.org/nexus/content/repositories/rehlds-dev/rehlds/rehlds/

    Zawsze ściągamy najnowszą wersje! Na ten moment pisania tego poradnika jest to wersja 3.4.0.656

    666139b12b.png

     

    II. Przygotowanie

    Po pierwsze i najważniejsze. Zanim przystąpimy do jakichkolwiek prac koniecznie wykonujemy kopię zapasową serwera! Każdy szanujący się hosting gier powinien zapewnić taką kopię do kilku dni wstecz, lecz dla pewności najlepiej ściągnąć sobie taką kopię na swój komputer (bądź wykonać samemu, jeśli hosting tego nie wspiera lub hostujemy na własnym serwerze dedykowanym / VPS). W przypadku jakiekolwiek niepowodzenia jesteśmy w stanie wrócić się do działającej wersji. W tym miejscu również przestrzegam, że nie ponoszę żadnej odpowiedzialności za ewentualne szkody, niepowodzenia, utratę danych itd.

     

    III. Instalacja silnika

    Skoro mamy już zapisaną kopię serwera to możemy przejść do właściwego działania. Osobiście jestem zwolennikiem podejścia, że jeżeli coś przebudowujemy to totalnie, od zera. Zatem zlecamy na hostingu reinstalacje serwera do zera! Możemy również podmienić tylko potrzebne pliki, lecz mogą z tego wyjść różne przykrości :) Jeżeli jesteśmy klientem 1s1k to przy reinstalacji oraz kupnie nowego serwera domyślnie instalowany jest silnik ReHLDS. Wersja na hostingu może być nie co starsza niż aktualna, wtedy możemy ręcznie dorzucić nowe pliki z repozytorium. Jednakże, wersja w instalatorze powinna być przetestowana na maszynach hostingu. W ten sposób mamy gwarancję, że się uruchomi bez problemu. Jeśli nie mamy opcji reinstalacji bezpośrednio do ReHLDS to wykonujemy ją do HLDS (najlepiej wersji przynajmniej 6153) i podmieniamy binarki w katalogu cstrike oraz cstrike/valve. Opcje ponumerowałem na screenie:

     

    5d897c607c.png

     

    Na sam koniec uruchamiamy serwer i sprawdzamy wersje silnika w konsoli za pomocą komendy "version". Jeśli zobaczymy wynik podobny do tego poniżej to znaczy, że się wszystko powiodło :)

     

    876f25877d.png

     

    IV. Instalacja i konfiguracja modułów

    Kolejny krokiem będzie instalacja odpowiedników pluginów metamoda. Chodzi tutaj o znane wszystkim moduły jak Dproto czy VoiceTranscoder, bez których dziś serwery nie mogą funkcjonować. Kolejno ich odpowiednikami są:

    • Dproto -> ReUnion
    • VoiceTranscoder -> ReVoice
    • FakeDetector -> ReAuthCheck (również warto zainstalować, chroni przed nalotami botów i fakeclientów na serwer)
    • NetBufExtender (opcjonalnie - jest kompatybilny z ReHLDS i rozszerza zaufany bufor HUD u graczy, aby zapobiec jego przepełnieniu, co przy wolniejszych łączach powoduje u gracza wyrzucenie z gry)

    Jeśli mamy serwer na 1s1k to sprawa wygląda dosyć prosto, ponieważ mamy gotowe paczki w instalatorze. Wystarczy kliknąć kolejno "Instaluj". Należy również odczekać kilka sekund między każdą instalacją. Warto w tym miejscu zanim przystąpimy do instalacji zainstalować już AMXX'a wraz z najnowszym MetaMod'em, kwestia samego AMXX będzie poruszona dalej.

     

    ebebf230b8.png

     

    Reszta modułów:

    e2ec5a695b.png


    Pozostali muszą ściągnąć bezpośrednio z internetu i zainstalować ręcznie tak jak każdy inny plugin metamod, czyli tworzymy folder w cstrike/addons i dopisujemy ścieżkę do binarki w cstrike/addons/metamod/plugins.ini Nie znalazłem również oficjalnych repozytorium z wszystkimi pluginami, lecz bez problemu znajdziecie je w Google ;)
    Na co jeszcze warto zwrócić uwagę to konfiguracja. O ile ReVoice i ReAuthCheck nie trzeba specjalnie konfigurować, o tyle warto poświęcić chwilę na konfiguracje ReUnion, czyli naszego starego Dproto. Nie możemy tutaj po prostu wrzucić starego configu, ponieważ trochę się różni. Niektóre funkcje znikły (np. zmiana nazwy gry) oraz pojawiło się kilka nowych funkcji np. saltowanie steamid. Jak rozwiązujemy ten konflikt ?

    Możemy do tego wykorzystać dowolny edytor tekstu umożliwiający porównanie dwóch plików, ja to zaprezentuję na jednym z najpopularniejszych, czyli Notepad++. Będziemy potrzebowali również wtyczki Compare, znajdziemy ją na liście pluginów w Plugin Manager. Ważne również abyśmy używali domyślnego stylu, ponieważ na innych kolorystyka porównań może być nieczytelna. Wszystko jest pokazane na screenach:

    e0c20f7216.png 0858ce568d.png

     

     

    Aby dokonać porównania otwieramy stare dproto.cfg oraz nowe reunion.cfg. Następnie przy aktywnej zakładce dproto.cfg wybieramy:

    8cfa032ed0.png

    Otwieramy zakładkę z reunion.cfg i wybieramy:

    ded99ac03c.png

     

    Uzyskujemy taki efekt:

    0e38bc51bb.png

     

    W ten sposób będziemy mieli pewność, że niczego nie pominęliśmy oraz możemy zaobserwować wszystkie zmiany. Każdy kolor oznacza coś innego, lecz zostały dobrane intuicyjnie, więc nie powinno być problemów z zrozumieniem:

    • Zielony - Nowa linijka
    • Czerwony - Brakująca linijka
    • Niebieski - Linijka przesunięta na inną pozycję
    • Żółty - Linijka częściowo zmieniona
    • Szary - W tym miejscu znajdowałby się tekst z drugiego pliku

     

    Jeżeli uważamy, że wszystko już nanieśliśmy to możemy wykonać porównanie jeszcze raz, aby sprawdzić czy zostały jeszcze jakieś różnice. Pozwolę sobie trochę odbiec od tematu i dwie najważniejsze rzeczy jakie powinniśmy ustawić (nawet na zwykłym HLDS) to zabezpieczenie przed podszywaniem się pod cudze steamid oraz zabezpieczenie przed podszywaniem się pod HLTV. Chodzi o wartości z screena, w HLTVExcept_IP wpisujemy adres IP HLTV:

    b159fe5c71.png bf8f1488b1.png

     

    e94883bb32.png

    Mamy również dostępny wachlarz innych modułów, lecz skoncentrowałem się tu tylko na tych najważniejszych. Najczęściej wprowadzają zupełnie nowe funkcjonalności, więc nie migrujemy już danych tylko traktujemy jako zupełną nowość.

     

    V. AMXX

    Przechodzimy teraz właściwie do sedna, do najważniejszego modułu, który urozmaica naszą rozrywkę. Autorzy postanowili również przebudować ten moduł i nazwali go ReAmxModX, lecz ma problemy z kompatybilnością wsteczną i zalecane jest używanie standardowego AMXX w wersji 1.8.3 (nie 1.8.2). Podobnie jak w poprzednim podpunkcie klienci 1s1k mogą zainstalować AMXX 1.8.3 z instalatora.

    Inne hostingi również powinny posiadać taką opcję, lecz gdyby jej brakło to zostawiam link do oficjalnego repozytorium: https://www.amxmodx.org/snapshots.php Również wybieramy najnowszą wersję i instalujemy tak jak inne moduły Metamod. W tej wersji również pojawiło się kilka nowych funkcji i usprawnień. Wrzucając z powrotem nasze configi i pluginy utracimy nad tym kontrole.

    Zatem w jaki sposób to pogodzić ? Wracamy do naszego utworzonego wcześniej backup'u i wypakowujemy cały folder z AMXX. Wysyłamy go na serwer w miejsce aktualnego AMXX, lecz powinniśmy użyć takiego klienta FTP żeby pytał nas co robić z takimi samymi plikami (np. polecam do tego FileZilla).

    f165160d30.png

     

    Zaznaczamy w takiej sytuacji opcje jak na screenie. W efekcie zachowujemy wszystkie pliki związane z wersją 1.8.3, mamy wrzucone nasze stare pluginy i pliki konfiguracyjne do nich, lecz pominęliśmy niektóre szczególnie ważne configi. Configi, które możemy bez problemowo podmienić naszymi:

    • clcmds.ini
    • cmds.ini
    • custommenuitems.cfg
    • cvars.ini
    • maps.ini
    • plugins.ini
    • modules.ini
    • sql.cfg
    • users.ini

     

    Natomiast plik konfiguracyjny nad którym warto się pochylić to amxx.cfg Celowo chciałem zapobiec jego podmiance, ponieważ tu mamy najwięcej zmian. Zatem powtarzamy tutaj proces z punktu IV z porównywaniem starego pliku z nowym. Widząc różnice wpisujemy do nowego wszystkie nasze wartości dla standardowych cvarów lub dopasowujemy je do nowych możliwości patrz np. cvar z screena. Resztę cvarów związanych z naszymi pluginami bez problemowo kopiujemy.

     

    aea3281a6c.png

     

    VI. Inne uwagi

    Na tym etapie już większość powinna nam poprawnie działać, lecz zaobserwowałem też pewne niedogodności. Być może dlatego, że mimo wszystko AMXX 1.8.3 jest wydany jako wersja rozwojowa i od wielu lat oficjalnie nie jest stabilny, przez co mogą wystąpić problemy z:

    • Pluginami łączącymi się z bazami danymi MySQL za pomocą funkcji SQL_Connect (należy wtedy podmienić moduł mysql na ten z wersji 1.8.2)
    • Pluginami wykorzystującymi moduł Cstrike (należy wtedy podmienić moduł cstrike na ten z wersji 1.8.2)
    • Pluginami wykorzystującymi moduł HamSandwich (tutaj nie ma uniwersalnego rozwiązania, najczęściej wymagają poprawek w kodzie)
    • Pluginami wykorzystującymi moduł Orpheu (ten nie jest już w ogóle wspierany w ReHLDS, jest zastąpiony przez ReAPI, lecz takie pluginy muszą być przepisane na nowo)

     

    Warto również przetestować wszystkie inne pluginy czy zachowują się poprawnie. Natomiast jako dodatkowe rozszerzenie opłaca się zainstalować moduł ReGameDLL, który pozwala nam rozszerzyć rozgrywkę o takie elementy, które nie były osiągalne na HLDS (np. zwiększenie limitu pieniędzy) oraz pozwala zastąpić wiele pluginów jak np. admin freelook, deathmatch mod, nade drops itp. Repozytorium projektu - https://github.com/s1lentq/ReGameDLL_CS

    Jeśli ktoś się spotkał z jeszcze jakąś nietypową sytuacją lub wie jak jeszcze usprawnić cały proces to niech da znać i dopiszę to do poradnika :)

     

    Zakaz kopiowania poradnika na inne fora bez mojej wiedzy i podania źródła!

    • I like this! (+1) 3
    • Thanks! (+1) 1
    Link to comment
    Share on other sites

    Guest
    This topic is now closed to further replies.
     Share

    ×
    ×
    • Create New...