Jump to content
  • Chmurka
  • Boróweczka
  • Jabłuszko
  • Limonka
  • Czekoladka
  • Węgielek

Search the Community

Showing results for tags 'metamod'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Nasze Sprawy
    • Nowości
    • Dyskusje
    • Propozycje
    • Przywitaj się!
  • Sourcemod Scripting
    • Artykuły, poradniki, tutoriale
    • Pytania na temat kodowania
    • Problem z kodem pluginu
    • Prośby o przerobienie pluginu
    • Gotowe funkcje
    • Koduj z Magnetem
  • Konfiguracja pluginów
    • Artykuły, poradniki i tutoriale
    • Szukam pluginu
    • Duże modyfikacje
    • Zbiór pluginów
    • Extensions
    • Gotowe paczki serwerowe
  • Konfiguracja serwera
    • Artykuły, poradniki, tutoriale
    • Pytania
    • Problemy
    • Ochrona
    • Metamod
  • Counter-Strike: Global Offensive
    • Nowości
    • Artykuły, poradniki, tutoriale
    • Pytania
    • Problemy
    • Pliki
    • Wasza twórczość
    • Publikacje serwerów
  • Hostingi serwerów
    • Oferty firm
    • Opinie o hostingach
    • Pytania
  • Plac zabaw
    • Luźne rozmowy
    • Szukam ekipy
    • Rynek
    • Opinie o ludziach
    • RoundSoundy
  • Archiwum
    • Przestarzałe tematy
    • Kosz

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


O mnie

Found 8 results

  1. Cześć. Wgrywam sobie metamoda i sourcemoda (najnowsze) do folderu z CS:GO, włączam CS:GO z komendą -insecure, wbijam na serwer z botami, wpisuję komendę w konsolę "sm exts list" i wyskakuje to: <FAILED> file "": Prodecura inicjowania biblioteki dołączanej duynamicznie (DLL) nie powiodła się. Co robić gocodziarze?
  2. Łatwy sposób na testowanie pluginów 1. Przechodzimy do folderu gdzie mamy zainstalowany steam 2. Przechodzimy steamapps/sourcemods/ 3. Wrzucamy zawartość załącznika CSGO + SM.7z do /sourcemods/ 4. Wgrywamy tam najpierw Metamoda potem Sourcemoda (tutaj tutorial na ten temat) 5. Uruchamiamy ponownie Steam 6. Wchodzimy do biblioteki gier 7. Ustawiamy dla gry "CSGO + SM" w parametrach startowych -insecure 8. Końcowy układ folderów powinien wyglądać tak: Dzięki temu mamy "osobną" grę CS:GO gdzie możemy testować pluginy LOKALNIE UWAGA Byłoby miło całej ekipie GO-Code.pl jeśli skorzystasz z CSGO + SM by GO-Code.pl.7z zamiast podanego wyżej CSGO + SM. Ta paczka zawiera reklamę naszego forum i za każdym razem gdy będziesz testował pluginy dasz znać znajomym o naszym forum ? (ponieważ gra nazywa się "CSGO + SM by GO-Code.pl" zamiast samego "CSGO + SM") UWAGA2 Ten poradnik jest skopiowany słowo w słowo z tego postu napisanego przez @mastah7991 za jego pozwoleniem. Uznałem że jest to na tyle wygodny sposób że zasługuje on na osobny temat
  3. Na co dzień używamy programów różnorakiej maści, bezpośrednio, na przykład w aplikacji w telefonie lub pośrednio, lecąc samolotem nasz pilot korzysta z ułatwiających mu pracę narzędzi informatycznych. Niezależnie od sytuacji, zawsze co najmniej 2 osoby korzystają z danego programu. Użytkownik oraz programista. Użytkownik klika w guziki, przesuwa okienka, odtwarza dźwięki, programista czyta, refaktoryzuje, przepisuje, dorabia kod. Za łatwość w wykonywaniu obu tych czynności zawsze odpowiada programista. Z jednej strony musi zaimplementować czytelny i intuicyjny interfejs dla użytkownika a z drugiej musi napisać czytelny i intuicyjny kod dla swojego zespołu informatycznego, dla swojego przełożonego, czy chociażby dla siebie samego "z przyszłości", który bardzo często będzie łapał się za głowę i mówił "jak mogłem coś takiego napisać" ?. Aby uratować wszystkich klepaczy kodu przed złem na przełomie tych wszystkich lat zostały ustalone umowne reguły pisania Clean Code, po polsku Czytelny Kod (dosłownie Czysty Kod). Jako że nie są one jednoznacznie ustalone a różni programiści mają różne zdanie na ten temat, nie będę mógł teraz obiektywnie przedstawić wszystkich dobrych nawyków pisania kodu. Ale postaram się. Po tym wstępie, zaczynajmy. (uwaga - punkty nie są ułożone w żadnej konkretnej kolejności) I. Nigdy nie używaj "goto" Funkcja "goto" występuje w wielu językach programowania. Ma ona za zadanie przerwać aktualny ciąg instrukcji wykonywanych przez program i "pójść w inne miejsce". Niekiedy jest wykorzystywana na podobnej zasadzie co while, imitując przy tym działanie pętli. Użycie goto bardzo utrudnia odczytanie kodu, ponieważ czytający musi skakać między kawałkami tekstu by dowiedzieć się gdzie ten goto prowadzi. Użycie również sugeruje, że autor nie potrafił sobie poradzić z prawidłowym napisaniem kodu i po prostu poszedł na skróty, kierując dalszy ciąg kodu gdzieś indziej. II. Staraj się nie umieszczać klamry "}" dalej niż jeden ekran odległości od klamry "{" Jednym z nurtów pisania dobrego kodu jest KISS - Keep It Simple Stupid (po polsku BUZI - Bez Udziwnień Zapisu Idioto). Mówi nam on, żebyśmy nie udziwniali kodu i pisali go w jak najprostszy, banalny sposób. Stąd starajmy się pisać jak najkrótsze funkcje, rozbijać duże bloki kodu na mniejsze. Sprawmy, by funkcje nie były dłuższe niż długość jednego ekranu. Wtedy programista będzie mógł ogarnąć całą jedną funkcjonalność na raz, bez przewijania. Ułatwi to znacznie czytanie kodu. III. Deklaruj zmienne możliwie jak najbliżej miejsca ich użycia Jeśli inicjujesz zmienne w swojej funkcji, postaraj się, żeby znalazły się jak najbliżej miejsca gdzie są one wykorzystywane. Zmniejszy to w ten sposób czas (jakkolwiek znikomy by on był) w jakim programista będzie szukał okiem tych dwóch części kodu. Źle: stock void GetPlayerDataAndDoSomething(int client) { float angle[3]; float origin[3]; float armor; GetClientAbsAngles(client, angle); GetClientAbsOrigin(client, origin); armor = GetClientArmor(client); /* do something */ } Dobrze: stock void GetPlayerDataAndDoSomething(int client) { float angle[3]; GetClientAbsAngles(client, angle); float origin[3]; GetClientAbsOrigin(client, origin); float armor; armor = GetClientArmor(client); /* do something */ } IV. Bezwzględnie używaj wcięć Dla kogoś kto miał w szkolę swoją pierwszą lekcję programowania lub swój pierwszy kurs, powinien to już być banał. Nie ma informatyka który kiedykolwiek powiedziałby "wcięcia są niepotrzebne". Jest to najważniejszy element odpowiadający za czytelność kodu, gdyż w mig łapiemy jakie instrukcje są w jakich funkcjach, co jest zależne od czego oraz łatwiej nam się poruszać oczami po tekście. Źle: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } V. Używaj const/#define oraz nazw enum'ów zamiast "magicznych liczb" Jeśli używasz jakichś stałych wartości liczbowych lub bitowych ("magiczne liczby"), jest bardzo wysokie prawdopodobieństwo że po czasie nie dłuższym niż tydzień zapomnisz jaką ta liczba pełni rolę w Twoim kodzie. Dlatego ważnym jest, by używać zawartych w plikach .inc nazw enum'ów zawierających odpowiednie numerki, korzystać z predefiniowanych zmiennych #define lub deklarować zmienne typu const. Doskonałym przykładem takiej zmiennej w sourcepawn'ie jest MaxClients, która mówi nam ile klientów może znajdować się maksymalnie na serwerze. Źle: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= 64; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } KillPlayersFromTeam(2); Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } KillPlayersFromTeam(CS_TEAM_CT); VI. Bądź konsekwentny w stylu pisania Czy stawiasz otwartą klamrę w linii gdzie znajduje się if/while/inna funkcja czy stawiasz ją w linii następnej, czy używasz węgierskiej notacji czy nie, czy stawiasz średniki na końcu linii czy nie (w sourcepawnie akurat są opcjonalne), zawsze bądź konsekwentny w tym co robisz. Trzymaj się jednej konwencji, jednego stylu na cały projekt. Jeśli w większości kodu stawiasz klamrę "{" samotnie, a nie w linii z innymi instrukcjami, a potem gdzieniegdzie zaniedbujesz tę praktykę, może się zdarzyć tak, że gdy spojrzysz na taki zaniedbany kod, w ogóle nie spostrzeżesz tej klamry tam gdzie się znajduje bo będziesz jej szukał w złej linii. Źle: stock void kill_player_on_team( int iTEAM) { for(int i=1;i<=MaxClients;i++){ if (GetClientTeam ( i )==iTEAM) ForcePlayerSuicide( i ); } } Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } VII. Bardzo rozsądnie używaj komentarzy W tym aspekcie trzeba znaleźć odpowiedni balans. Zbyt duża ilość komentarzy lub ogromne bloki tekstu zniekształcą obraz kodu. Bo w końcu mamy czytać kod a nie akapit tekstu. Brak komentarzy lub dwuwyrazowe wstawki mogą przekazać za mało informacji lub zmylić czytającego wprowadzając go w błędny tok myślenia. Za przykład może posłużyć rozległa funkcja, która nawet nazwana perfekcyjnie, może potrzebować dodatkowego zdania komentarza, na przykład jaką konkretnie wartość będzie zwracała, albo ogólnikowo w jaki sposób robi to co robi. Nie masz tłumaczyć co jak konkretnie działa, ale po przeczytaniu skromnego komentarza łatwiej ma Ci być odczytać kod, będziesz wiedział czego mniej więcej możesz się spodziewać. VIII. Podobnie działające funkcje nazywaj podobnie Najczęstszymi funkcjami/metodami są set'tery oraz get'tery. Jak z nazwy wynika, set'ter ustawia wartość jakiejś zmiennej/atrybutu, get'ter ją pobiera. Dlatego jeśli tworzysz funkcje na przykład: ustawiającą nick graczowi, zmieniającą nazwę serwera oraz ustawiającą klasę danemu graczowi, nazwij je kolejno: SetPlayerName, SetServerName, SetPlayerClass. Podobnie jest w funkcjach rejestrowanych przez EventHook w sourcepawn'ie. Jeśli rejestrujemy ich kilka, dobrze by było gdyby każda zaczynała się od wyrazu "Event". Źle: public void OnPluginStart() { HookEvent("round_start", StartRoundEvent); HookEvent("round_end", RoundEnd); } Dobrze: public void OnPluginStart() { HookEvent("round_start", Event_RoundStart); HookEvent("round_end", Event_RoundEnd); } IX. Używaj camelCase oraz PascalCase w nazewnictwie zmiennych oraz funkcji Nazewnictwo camelCase cechuje się tym, że każdy wyraz oprócz pierwszego zaczyna się wielką literą, na przykład: zmiennaRobiacaFikolki, setUserModel. W nazewnictwie PascalCase, każdy wyraz zaczyna się wielką literą, na przykład: SetUserName, PoznanMiastoDoznan. Te dwa sposoby przydają się w odróżnianiu funkcji od zmiennych. Do zmiennych używamy camelCase a do funkcji PascalCase. Pomaga nam to w szybszym zorientowaniu się co jest czym. Oczywiście w różnych językach mogą być różne koncepcje i standardy nazewnictwa, natomiast ta porada jest kierowana głównie do laików, którym na pewno łatwiej będzie się posługiwać taką metodyką. X. Nie zawsze używaj klamer "{ }" Jest wyjątek kiedy klamry w if/while/for/funkcji nie są wymagane, jest to sytuacja w której w podanych klamrach miałaby się znajdować tylko jedna instrukcja. Wtedy klamry można odpuścić i kompilator będzie wiedział, że jeśli nie ma klamer, to trzeba odczytać tylko jedną instrukcję. Zwykle jeśli tak się postąpi, czytelność kodu zwiększa się, szczególnie jeżeli w jednym miejscu może wystąpić bardzo dużo klamer, które zaciemniają obraz sytuacji. Z drugiej jednak strony, czasami pozostawienie chociaż jednej klamry zamiast skasowania wszystkich zbędnych może jeszcze bardziej polepszyć czytelność kodu. Źle: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) { if (GetClientTeam(i) == team) { ForcePlayerSuicide(i); } } } Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } XI. Jedna funkcja powinna spełniać jedną funkcjonalność Jeśli funkcja robi kilka rzeczy na raz, trudniej nam ją refaktoryzować, ponieważ zamiast kilku mniejszych funkcji, które ogarnęlibyśmy szybciej, musimy zastanowić się nad działaniem całej długiej funkcji, mentalnie odseparować funkcjonalność którą chcemy przepisać i zacząć ją zmieniać, cały czas uważając na kod dookoła który przy okazji możemy zepsuć. Poza tym, mniejsze funkcje łatwiej odczytywać, dzięki czemu uzyskamy ładniejszy kod. Co więcej, jeśli odseparujemy funkcje, potencjalnie możemy zwiększyć możliwość ponownego ich użycia w innym miejscu w kodzie. Źle: stock void KillSomePlayers() { int killList[65]; for (int i = 0; i < sizeof(killList); i++) if (GetPlayerWeaponSlot(i, 1) == -1) killList[i] = 1; for (int i = 0; i < sizeof(killList); i++) if (killList[i] == 1 && IsClientConnected(i) && IsClientInGame(i) && !IsFakeClient(i) && !IsClientSourceTV(i)) ForcePlayerSuicide(i); } KillSomePlayers(); Dobrze: stock void KillSomePlayersFromList() { int killList[65]; GetPlayerKillCondition(killList); for (int i = 0; i < sizeof(killList); i++) if (killList[i] == 1 && IsValidClient(i)) ForcePlayerSuicide(i); } stock void GetPlayerKillCondition(int[] killList) { for (int i = 0; i < sizeof(killList); i++) if (GetPlayerWeaponSlot(i, 1) == -1) killList[i] = 1; } stock bool IsValidClient(int client) { return (1 <= client <= MaxClients && IsClientConnected(client) && IsClientInGame(client) && !IsFakeClient(client) && !IsClientSourceTV(client)); } KillSomePlayersFromList(); XII. Nigdy nie używaj/nadpisuj bezpośrednio zmiennych globalnych w funkcjach Funkcja ma za zadanie przyjąć jakąś wartość oraz ewentualnie zwrócić ją w zmienionej postaci lub zwrócić inne wartości. Jeśli zaczniemy w nich używać zmiennych globalnych bezpośrednio, może się zdarzyć tak, że niechcący nadpiszemy zmienną globalną niechcianą wartością lub wywołamy funkcję w nieodpowiedni sposób nie panując kompletnie nad tym, co dana funkcja ma w sobie. Lepszym rozwiązaniem jest przesłanie zmiennej globalnej jako parametr. W ten sposób nie ma możliwości byś popełnił błąd, gdyż pisząc program i używając gdzieś takiej funkcji, świadomie wkładasz w nią daną zmienną i wiesz dokładnie jakiego efektu możesz oczekiwać. Dodatkowo jeśli prowadzisz swój kod w ten sposób, zyskujesz możliwość ponownego użycia takiej funkcji w innym miejscu w kodzie z innym parametrem. Jest jeszcze jedna zasada związana z funkcjami. Dla podanych danych wejściowych, funkcja ma zwracać ZAWSZE te same dane wyjściowe. Oznacza to, że niezależnie ile razy wykonamy daną funkcję z określonymi parametrami, wynik zawsze będzie ten sam. Używanie zmiennych globalnych w funkcji, na przykład odczytywanie ich i bazowanie działania funkcji na jej wartości, łamie tę zasadę. Ponieważ dla tych samych wartości wejściowych, jeśli zmieni się w międzyczasie używana zmienna globalna, mogą pojawić się inne dane wyjściowe. Źle: int killList[7] = {2, 3, 5, 7, 11, 13, 17}; stock void KillPlayersFromList() { for (int i = 0; i < sizeof(killList); i++) ForcePlayerSuicide(killList[i]); } KillPlayersFromList(); Dobrze: int killList[7] = {2, 3, 5, 7, 11, 13, 17}; stock void KillPlayersFromList(int[] list) { for (int i = 0; i < sizeof(list); i++) ForcePlayerSuicide(list[i]); } KillPlayersFromList(killList); XIII. Hermetyzuj dane w programowaniu obiektowym W obiektówce, klasy (w sourcemod'zie mamy pseudo-obiektowe methodmap'y) mogą posiadać swoje "zmienne", zwane atrybutami. Złą praktyką jest bezpośrednie korzystanie z takich zmiennych. Dobrą praktyką jest pisanie małych metod, set'terów oraz get'terów, by odczytywać oraz ustawiać wartości dla tych zmiennych. Minimalizuje nam to możliwość popełnienia błędu i skorzystania ze zmiennej z której nie powinniśmy odczytać. Nie napisałeś takich metod dla tych atrybutów przy tworzeniu methodmap'y? Widocznie Twoim początkowym zamysłem był prosty przekaz - nie masz korzystać na własną rękę z tych atrybutów. XIV. Usuwaj nieużywany kod lub zakomentowany kod Przyjdzie taki moment, gdzie spojrzysz na kod zamieszczony w komentarzu lub kod którego program nie używa i zaczniesz się zastanawiać po co, dlaczego, jak to się stało że to tam się znalazło. Zaoszczędzisz sobie czasu, jeśli w momencie komentowania lub rezygnowania z korzystania z danej funkcji lub pisania obok nowej, lepszej funkcji zadasz sobie pytanie "Czy kiedykolwiek będę jeszcze tego używał?" i głęboko się nad tym zastanowisz. Z doświadczenia wiem, że jeśli sam zakomentuję kod i w tym samym dniu go już nie odkomentuję - już nigdy z niego nie skorzystam. Jeśli naprawdę uważasz, że taki kod może Ci się jeszcze przydać, zakomentuj go odpowiednio i wytłumacz jego działanie dla siebie "w przyszłości". Natomiast jeśli jest to spory kawał kodu i jesteś z niego dumny - zapisz go sobie gdzieś (oczywiście w osobnym pliku i oczywiście z obszernym komentarzem). Może się jeszcze kiedyś przyda? Źle: stock void KillPlayersFromTeamOld(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) SlapPlayer(i, 9999999, false) } stock void KillPlayersFromTeamNew(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } XV. Nie powtarzaj swojego kodu Jednym z nurtów dobrego pisania kodu jest DRY - Don't Repeat Yourself, po polsku "nie powtarzaj się". Postaraj się nigdzie nie powtarzać swojego kodu. W innym wypadku jeśli będziesz chciał zmienić logikę jego działania, to czeka Cię zmiana w kodzie nie w jednym miejscu a w kilku. Źle: stock void KillPlayersFromTT() { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == CS_TEAM_T) ForcePlayerSuicide(i); } stock void KillPlayersFromCT() { for (int i = 1; i < MaxClients; i++) if (GetClientTeam(i) == CS_TEAM_CT) ForcePlayerSuicide(i); } Dobrze: stock void KillPlayersFromTeam(int team) { for (int i = 1; i <= MaxClients; i++) if (GetClientTeam(i) == team) ForcePlayerSuicide(i); } (UWAGA - nie umieściłem tutaj jednej z ważniejszych kwestii - nazewnictwo zmiennych. Z moją aktualną wiedzą nie czuję się na siłach by o tym napisać, co więcej temat jest tak rozległy, że potrzebowałby osobnego tematu na wytłumaczenie. Może pojawi się w przyszłości) (PS. Wszystkie przykłady kodu są tutaj pisane w pseudo-kodzie. Nie jest pewne czy skompilują lub czy są poprawne w składni. Mają tylko ukazywać problem oraz rozwiązanie) Bibliografia https://forums.alliedmods.net/showthread.php?t=85274 https://forums.alliedmods.net/showthread.php?t=6481 https://en.wikipedia.org/wiki/KISS_principle https://en.wikipedia.org/wiki/Don't_repeat_yourself https://pl.wikipedia.org/wiki/CamelCase https://pl.wikipedia.org/wiki/PascalCase https://github.com/jupeter/clean-code-php/ https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
  4. Najnowszy stabilny build metamoda ma numer 970. Od ostatniej wersji wrzuconej na nasze forum weszło parę niewielkich zmian. Pamiętajcie zawsze aktualizować software do najnowszych wersji! Download Linux mmsource-1.10.7-git970-linux.tar.gz Download Windows mmsource-1.10.7-git970-windows (1).zip Najnowszą wersję zawsze znajdziesz na https://www.sourcemm.net/downloads.php?branch=stable
  5. Opis Komunikat w konsoli serwera: IP rate limit sustained * distributed packets at * pps (* buckets). IP rate limit under distributed packet load (* buckets, * global count), rejecting * Jest uznawany za atak DOS na serwer. Najbardziej skutecznym i znanym sposobem na poradzenie sobie z takimi atakami jest blokada na IP od których dostajemy natłok pakietów. Doskonale radzi sobie z tym iptables, ale jest on dostępny tylko dla osób posiadających własną maszynę lub możliwość jej skonfigurowania. Dla zwykłych zjadaczy chleba korzystających z hostingów trzeba użyć pluginu metamoda pod nazwą qcache_mm Download qcache_mm.so qcache_mm.vdf Instalacja Do server.cfg dodaj linijkę sm_cvar qc_requestmap_enabled "0" qcache_mm.so dodaj do folderu addons/ qcache_mm.vdf dodaj do folderu addons/metamod/ Zrestartuj serwer ----- Co niezwiązane z powyższym pluginem, można też ustawić cvary sm_cvar net_maxroutable 768 sm_cvar net_minroutable 768 sm_cvar sv_max_queries_sec_global 10 sm_cvar sv_max_queries_sec 5 sm_cvar sv_max_queries_window 10 ----- Źródło https://forums.alliedmods.net/showpost.php?p=2540056&amp;postcount=32 https://forums.alliedmods.net/showthread.php?t=135543 https://forums.alliedmods.net/showpost.php?p=2565025&amp;postcount=2
  6. Opis Exploit wysyła masywne ilości żądań do serwera o odtworzenie niesłyszalnego dźwięku (common\null.wav). Serwer nie może przetworzyć takiej ilości informacji więc laguje graczy. Przy większych natężeniach serwer się wyłącza. Prawdopodobny kod exploitu https://hastebin.com/gufovomiju.cpp Download nullwavefix.sp Oraz (prawdopodobnie) nowsza wersja anti_exploit.sp Źródło https://github.com/IT-KiLLER/Exploit-FIX-2018-04-17 https://forums.alliedmods.net/showthread.php?t=280545&amp;page=7 PS. Exploit jest prawdopodobnie przestarzały, wklejam temat z innego forum bo przyda się content XD
  7.  Linki Poradnik Dodawanie tokena Jak wygenerować token ? Dodawanie admina (Flag) Jak uzyskać steamid ? Jakie są flagi i do czego ? UWAGA Autorem tego posta jest @zorix i został tutaj wklejony za jego zgodą
  8. Jak wiadomo metamod jest kluczowym narzędziem w utrzymaniu serwera CS:GO. Przedstawiam więc najnowszą wersję metamoda numer 1.10.7. Najnowszy stabilny build jest z dnia 2 sierpnia 2018, numer 966. Pełny changelog wersji 1.10 z wiki.alliedmods.net Download Linux mmsource-1.10.7-git966-linux.tar.gz Download Windows mmsource-1.10.7-git966-windows.zip Najnowszą wersję zawsze znajdziesz na https://www.sourcemm.net/downloads.php?branch=stable

Nasza historia

Na początku byliśmy małą grupą internetowych znajomych, którzy stwierdzili, że potrzebne jest solidne forum, na którym znajdą się ludzie z dużą wiedzą programistyczną ukierunkowaną na CS:GO. Pomysł powstał na początku 2018 roku, a parę miesięcy później, 19 kwietnia, powstała ta strona internetowa. Jako alternatywna odpowiedź na inne tego typu miejsca, poważnie podeszliśmy do tematu, najpierw tłumacząc angielską dokumentację SourceMod'a na język polski, a potem pisząc rozległe poradniki i wypełniając forum najpotrzebniejszymi rzeczami dla właścicieli serwerów i programistów. Cała nasza Ekipa jest dumna z pracy jaką w to włożyliśmy i cieszymy się że zbierają się wokół nas zarówno ludzie znający tematy sourcepawn'a i konfiguracji, jak i również nowe twarze w tym "biznesie", którym z chęcią niesiemy wiedzę oraz pomoc w rozwiązywaniu problemów.

Największe modyfikacje serwerowe

×
×
  • Create New...