- Skocz do zawartości

Znajdź zawartość

Wyświetlanie wyników dla tagów 'kodu' .



Więcej opcji wyszukiwania

  • Wyszukaj za pomocą tagów

    Wpisz tagi, oddzielając je przecinkami.
  • Wyszukaj przy użyciu nazwy użytkownika

Typ zawartości


Kategorie

  • Error'y w kompilatorze
  • Warning'i w kompilatorze
  • Fatal error'y w kompilatorze

Forum

  • Go-Code.pl - Ogólne
    • Informacje
    • O serwisie
  • Sourcemod Scripting
    • Baza wiedzy
    • Masz problem?
    • Pytania na temat kodowania
  • Pluginy Sourcemod
    • Wszystko o pluginach
    • Duże modyfikacje
    • Dodatki
  • Konfiguracja serwera
    • Baza wiedzy
    • Pytania
    • Problemy
  • Counter-Strike: Global Offensive
    • Nowości
    • Artykuły, poradniki, tutoriale
    • Pytania
    • Problemy
  • Hostingi serwerów
    • Oferty firm
    • Opinie o hostingach
    • Pytania
  • Poza tematyką forum, OFF-TOPIC
    • Życie społeczności
    • Biznes
    • Zareklamuj swoją sieć/serwer
    • RoundSoundy
  • Archiwum
    • Przestarzałe tematy
    • Kosz

Szukaj wyników w...

Znajdź wyniki, które zawierają...


Data utworzenia

  • Od tej daty

    Do tej daty


Ostatnia aktualizacja

  • Od tej daty

    Do tej daty


Filtruj po ilości...

Dołączył

  • Od tej daty

    Do tej daty


Grupa podstawowa


Imię


Lokalizacja


Zawód


O mnie


Strona WWW

Znaleziono 7 wyników

  1. Temat jest aktualizowany i na bieżąco edytowany - najnowsze posty znajdują się na samej górze, zgodnie z oznaczeniem dat i godziny. Starsze informacje mogą być już nieaktualne! 23.04 0:15 Jest dobrze "Przejrzeliśmy kod, który wyciekł do sieci i sądzimy, że jest to kopia silnika CS:GO, udostępniona dla partnerów pod koniec 2017 roku, a pierwotnie wyciek miał miejsce w 2018 roku. Po jego analizie, nie znaleźliśmy żadnego uzasadnienia, aby alarmować graczy ani unikać aktualnych wersji silnika." https://twitter.com/CSGO Jak się okazuje, serwery mogą działać normalnie. Wybaczcie, że zareagowałem tak gwałtownie, ale zależało mi na bezpieczeństwie graczy, a w morzu fake newsów i sprzecznych informacji ciężko jest dojść do prawdy. Oczywiście w razie jakichkolwiek zmian post będzie aktualizowany. 23.04 0:03 Wygląda na to, że panika, która jest rozsiewana w mediach jest trochę zbyt rozdmuchana. Znalezienie, a następnie wykorzystanie exploita to proces dużo dłuższy niż kilka godzin. Dlatego obecnie nie jest konieczne wyłączanie serwerów, jednak wszystko może się zmienić - trzeba czekać na oficjalne komunikaty od Valve. Zobaczymy, co przyniesie przyszłość. "Z pewnością istnieją prawdziwe, możliwe do wyeksploitowania błędy w silniku Source, tak jak w prawie każdych większych projektach - jednak ten wyciek nie zmienił niczego, może on pomóc ludziom za jakiś czas znaleźć luki, zarówno legalne, jak i złośliwe, jednak słowem-klucz jest tutaj "za jakiś czas" - a później potrzeba dużo pracy, aby przekuć buga na używalny exploit" ~ashkerin, współtwórca SourceMod 22.04 22:56 Niestety, nie mam dla Was dobrych informacji. Dzisiaj doszło do wycieku plików gry z CS:GO i TF2. Wszystkie dane zostały upublicznione na stronie 4chan. Co prawda do sieci nie wyciekły najnowsze wersje gier, jednak mówimy o CS:GO z okresu operacji Hydra i TF2 po aktualizacji Jungle Inferno. Początkowo o ten czyn podejrzewano twórcę kanału Valve News Network, Tylera McVickera, jednak, jak sam tłumaczy, nie jest on winowajcą. Nie to jest jednak istotne... Dostęp do plików gry dostarcza potencjalnym hackerom ogromną bazę wiedzy i pomoc w tworzeniu cheatów i innego rodzaju szkodliwego oprogramowania. Prawdopodobnie na serwerach pojawi się teraz dużo więdzej cheaterów, niż dotychczas. Jest to jednak mały problem w obliczu poważniejszego zagrożenia - dostępny jest exploit, który pozwala na odpalanie ich programu na naszym komputerze. Co gorsza, wystarczy że jesteśmy na tym samym serwerze! To oznacza, że złodzieje mogą dokonać włamu na Wasz komputer, wykraść dane osobowe, zainfekować komputer i wiele, wiele więcej. Słowem - gry oparte na silniku Source nie są obecnie bezpieczne (prawdopodobnie jednak zagrożenie nie występuje na Source2). Co oznacza to dla nas, właścicieli serwerów? Nie możemy Wam niczego nakazywać, ale jeśli zależy Wam na dobru osób, które są częścią społeczności CS:GO, powinniście do czasu wyjaśnienia okoliczności i wprowadzenia łatki wyłączyć serwery, aby ograniczyć ryzyko potencjalnego włamu na komputery graczy. Kiedy coś się zmieni, będziecie na bieżąco informowani o sytuacji. Z góry dziękuję za rozwagę. Pamiętajmy - bezpieczeństwo przede wszystkim!
  2. Witam posiadam takowy kod do ktorego musze dopisac kawalek a nie znam sie na takowych sprawach chcial bym dopisac ten wycinek do pliku w zalaczniku wielkie dzieki za pomoc "kzjumpstats" { "driver" "sqlite" "host" "localhost" "database" "kzjumpstats-sqlite" "user" "root" "pass" "" } databases.cfg
  3. Cześć jaki jest kod aby osoba która ma broń typu (karabin snajperski) chodzi szczególnie o AWP aby nie mogła w ogóle z niej celować, po prostu zablokować u niej "MOUSE1" (Right click)? ale to można ustawić sobie w sumie na inny klawisz więc jeśli ktoś wie jak zablokować scope'owanie to prosiłbym o ten skrawek kodu o ile się da :D
  4. Szukam kodu cooldown do blokowania komend na określony czas. Przykładowo by każda osoba mogła używać danej komendy co jakiś czas bądz co kilka rund
  5. 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/
  6. Czesc , przychodze do was z pytaniem dopiero zaczynam z SourcePawnem nie zaczynam dopiero z programowaniem bo mam juz stycznosc z innymi jezykami takimi jak C++ , Pytanie: Jak dodawac eventy korzystam z kanalu @MAGNET'a ktory wszystko dokladnie tlumaczy , Gdy pisze kod zaczynam od #include <sourcemod> public void OnPluginStart() { RegConsoleCmd("sm_win", DaneWin "Pokazuje komunikat na srodku ekranu Monitora) } itd .... Jak dodac te Eventy z dokumentacji SourceMod ? ? ? Glownie chodzi mi o to jak dodawac te eventy i skladac to , przepraszam za ortografie , ale moja klawiatura odmawia mi posluszenstwa po dwoch latach.
  7. Mam do was pytanie bo specem od kodowania nie jestem, ukleiłem coś takie i teraz czy jest to w ogóle optymalne
×
×
  • Dodaj nową pozycję...