VertekS

Witam, dziś opiszę proces podmiany dźwięków w modelach, na potrzeby serwerów Counter Strike 1.6.

Spora część użytkowników ma problem z tym zagadnieniem więc postanowiłem w końcu opisać to dokładniej.

Jest to mój pierwszy poradnik.

 

Będzie nam potrzebne:
Halflife Model Viewer 1.3 (w paczce)
GUI Studio (w paczce)
MDL Decompiler (w paczce)
Notepad++ (Do pobrania z oficjalnej strony: link)

 

 HLMV13+decompiler.rar   609,59 KB  280 Ilość pobrań

1. Rozpakuj archiwum z załącznika.

2. Uruchom hlmv.exe (folder ../hlmv13_setup/hlmv.exe)

3. Wchodzimy w Menu > Tools > Configure Tools
    
    Pokaże nam się okienko, gdzie podajemy ścieżki do kompilatora i dekompilatora (folder ../GUI StudioMDL 1.0/)
    
   
    
    Wskazujemy pliki, klikamy OK i możemy przystąpić do dekompilacji modelu.
    
    Uwaga: Przed dekompilacją modelu, warto stworzyć osobny folder dla każdego przerabianego modelu ponieważ dekompilator tworzy sporo plików, nie chcemy bałaganu.
    
    Np. Tworzymy folder Ak47 i kopiujemy do niego model który będziemy dekompilować.
    

 

4. Wchodzimy w Menu > Tools > Decompile Model...

    Wyskoczy okienko gdzie wskazujemy nasz model, pamiętajcie że zawsze będzie to model v_, ja wybrałem orygianlny v_ak47.mdl
    
    Klikamy OK, po chwili w folderze obok v_ak47.mdl pokaże się sporo plików
    
   
    
    Nas interesuje tylko jeden plik, ten z rozszerzeniem *.qc - w tym przypadku będzie to v_ak47.qc
    

 

5. Otwieramy plik *.qc programem Notepad++ - teraz następuje właściwa edycja dźwięków przypisanych do danego modelu.

    Odnajdujemy w pliku *.qc (z reguły na końcu) fragment z sekwencjami, w moim przypadku wygląda on tak:
    
    

    // 6 animation sequence(s)

    $sequence "idle1" "idle1" fps 30

    $sequence "reload" "reload" fps 37 { event 5004 13 "weapons/ak47_clipout.wav" } { event 5004 57 "weapons/ak47_clipin.wav" }

    $sequence "draw" "draw" fps 30 { event 5004 11 "weapons/ak47_boltpull.wav" }

    $sequence "shoot1" "shoot1" fps 20 { event 5001 0 "22" }

    $sequence "shoot2" "shoot2" fps 20 { event 5001 0 "22" }

    $sequence "shoot3" "shoot3" fps 20 { event 5001 0 "22" }

    

    
    Uwaga: Treść pliku *.qc może znacznie różnić się od przykładu, szczególnie w przypadku niestandardowych modeli, jednak zasada edycji pozostaje taka sama.
    

 

    Zajmiemy się dźwiękami strzałów, ponieważ jak widać do sekwencji "shoot1" "shoot2" i "shoot3" nie ma przypisanych dźwięków "po ścieżce", zamiast tego mamy tajemnicze "22"
    
    Zmieniamy:
    
    

    $sequence "shoot1" "shoot1" fps 20 { event 5001 0 "22" }

    $sequence "shoot2" "shoot2" fps 20 { event 5001 0 "22" }

    $sequence "shoot3" "shoot3" fps 20 { event 5001 0 "22" }

    

    
    Na:
    
    

    $sequence "shoot1" "shoot1" fps 20 { event 5004 0 "weapons/new_sounds/ak47_strzal.wav" }

    $sequence "shoot2" "shoot2" fps 20 { event 5004 0 "weapons/new_sounds/ak47_strzal.wav" }

    $sequence "shoot3" "shoot3" fps 20 { event 5004 0 "weapons/new_sounds/ak47_strzal.wav" }

    

    
    Co zmieniliśmy? Poza podaniem ścieżki do *.wav zamiast "22", zmieniamy event 5001 na 5004
    
    Uwagi: -W przypadku sekwencji 'event 5004' czyli np. "draw", gdzie mamy podaną ścieżkę do dźwięku, zmieniamy tylko ścieżkę
           -Liczba pomiędzy event 5004 a ścieżką to opóźnienie odegrania dźwięku w ms, nie polecam zmieniać
           -Nowe dźwięki warto umieszczać w podfolderze np. cstrike/sound/weapons/new_sounds/..
        

 

   

6. Po zakończeniu edycji pliku *.qc zapisujemy zmiany i wracamy do Half-life Model Viewer

    Wchodzimy w Menu > Tools > Compile Model... i wskazujemy nasz edytowany plik *.qc
    
    Pokaże się okienko kompilatora:
    
   
    
    Jeżeli wszystko jest w porządku zobaczymy tekst:
    
    

    [Opening QC file - C:\Users\amxx\Desktop\v_ak47\v_ak47.qc]

    [QC loaded O.K!]

    

    
    Klikamy przycisk Compile
    
    Jeżeli wszystko jest ok to po chwili na dole zobaczymy tekst:
    
    

    [Compiler execution completed]

    

    
    Co oznacza że model skompilował się poprawnie, a w folderze którym był plik *.qc mamy swój nowy plik *.mdl (poprzedni został nadpisany)
    

 

 

7. Instalacja nowego modelu i dźwięków.

    Do podmiany modeli na serwerach polecam plugin GHW Weapon Replacement
    
    Przykładowy model z podmienionymi dźwiękami oraz instrukcją: M4A1 z dźwiękami CS:GO
    

Uwagi:

    -Pamiętajcie że nowe dźwięki muszą być w formacie *.wav oraz odpowiednio zresamplowane:

    

    Channel(s)                  : 1 channel

    Sampling rate               : 22.05 KHz

    Bit depth                   : 8 bits

    

    
    -Warto zachować porządek w folderach, nowe modele wrzucajcie np. do /cstrike/models/new_models/.. dźwięki do /cstrike/sound/weapons/new_sounds/..
    
    -Podmienione dźwięki będziemy słyszeć poprawnie ale inni gracze nasze strzały usłyszą już normalne (nie da się tego obejść w żaden sposób jeżeli chodzi o HLDS)
    

 

Jeżeli czegoś brakuje, proszę pisać. Pozdrawiam i powodzenia w edycji.

 

Za cholerę nic nie rozumiem z opisu... Ludzie, używajcie interpunkcji...

1. Zamiast thinka możesz użyć FM_CmdStart lub Ham_ObjectCaps (przynajmniej dla IN_USE). FM_CmdStart będzie się wykonywać tylko, gdy gracz faktycznie "coś" robi. Ma jednak tą samą wadę, co think że coś może się wykonać wiele razy... Ale! To nie jest wcale taka wada, jeśli wiesz jak to działa

 

Otóż prócz sprawdzenia co gracz naciska poprzez get_user_button, możesz również sprawdzić co naciskaŁ przy poprzednim wywołaniu eventu, poprzez get_user_oldbutton lub po prostu cachując przyciski wewnątrz pluginu. W taki sposób: jeśli gracz nie naciskał poprzednio IN_USE, a teraz to robi, oznacza to ni mniej, ni więcej że zaczął naciskać. Więc w tym momencie możesz wywołać jakąś akcję. 

Jest to projekt którego założeniem było ułatwienie pracy i zarządzania configami oraz dodania funkcjonalności której wcześniej nie było w amxxie.

Wrzucając framework do projektu dostajemy do dyspozycji dwa nowe forwardy

http://darkgl.amxx.p...ania-configami/

• plugin_config
• plugin_config_loaded

oraz funkcje publiczną do wywołania

• CFWInitialize( configName[] )

plugin_config - wykonuje się przed plugin_precache więc jest to pierwsza funkcja uruchamiana w pluginie
w tym forwardzie rejestrujemy wszystkie cvary. Do funkcji register_cvar został dodany jeden nowy parametr description. Czyli opis cvara.
Przykład użycia

register_cvar( "test_cvar" , "1" ,.description = "Testowy cvar" );

Drugi forward plugin_config_loaded jest uruchamiany po załadowaniu wszystkich cvarów jest to funkcja wykonywana przedplugin_precache.

W tym forwardzie pobieramy sobie wszystkie dane z cvarów które są nam potrzebne.

Funkcje CFWInitialize( configName[] ) uruchamiamy w forwadzie plugin_config
np.

CFWInitialize( "testConfig" );

pierwszym parametrem jest nazwa configu do utworzenia.
Prywatne metody w frameworku to

• __CFWregister_cvar
• __CFWloadConfig
• __CFWsaveConfig

Należy je tylko wykonywać jeśli dokładnie wie co chce się zrobić
Wszelkie pluginy pojawia się w folderze

configs/plugin/nazwaConfiga.cfg

Przykładowy plugin

/* Script generated by Pawn Studio */

#include <amxmodx>
#include <amxmisc>

#include "config"

#define PLUGIN	"testConfig"
#define AUTHOR	"DarkGL"
#define VERSION	"1.0"

new cvarResult;

#pragma unused cvarResult

public plugin_init()
{
	register_plugin(PLUGIN, VERSION, AUTHOR);
}

public plugin_precache(){
}

public plugin_cfg(){
}

public plugin_config(){
	CFWInitialize( "testConfig" );
	
	register_cvar( "test_cvar" , "1" ,.description = "Testowy cvar" );
}

public plugin_config_loaded(){
	cvarResult = get_cvar_num( "test_cvar" );
	
	log_amx( "config loaded cvarResult: %d" , cvarResult );
}

 config.inc   2,95 KB  105 Ilość pobrań

 

Cel to wpełni działające środowisko programistyczne w przeglądarce ( wraz z znanymi ułatwieniami tzn. generatory ) oraz możliwość przenoszenia kodu między różnymi komputerami itp.

 

Mam nadzieję że projekt uda się ukończyć jednak jest mnóstwo problemów z obsługą w różnych przeglądarkach oraz problemów wydajnościowych.

No zobacz sobie jak to formatujesz i co chcesz osiągnąć.

client_print(0, print_chat, "Gracz %d spadl i zabralo mu %f hp",id, Damage);

prosisz silnik o wstawienie do tej wiadomości id gracza a nie jego nick.

client_print(0, print_chat, "Gracz %s spadl i zabralo mu %f hp",name, Damage);

I po kłopocie.

http://amxx.pl/topic...towanie-tekstu/

Poczytaj sobie.

 

EDIT.

A jak chcesz podany miec Damage jako całkowita liczba to zapisz to tak

client_print(0, print_chat, "Gracz %s spadl i zabralo mu %d hp",name, floatround(Damage));

No i czego tu nie rozumiesz?
1. plugin na serwerze wysyła socket z danymi z pliku licencyjnego
2. serwer licencyjny sprawdza poprawność danych (generuje po swojej stronie klucz i sprawdza, czy jest on taki sam. Sprawdza również, czy adres IP z którego łączy się plugin jest uprawniony do korzystania z tej licencji). Dane pobiera oczywiście z bazy danych (hasło licencji, tajne, uprawnione adresy IP do licencji i inne dane, jeśli również je weryfikujesz. Pobierane na podstawie ID licencji)
3. serwer licencyjny odsyła odpowiedź o tym, czy licencja jest prawidłowa czy nie.

W przypadku, gdy zmienia IP serwera, wydajemy nową licencję (za darmo lub po dopłacie, to już polityka własna sprzedającego plugin), a starą unieważniamy (oznaczamy np w bazie flagą expired/invalid albo wyrzucamy z bazy).

Zawsze można też rozszerzyć, aby jedna licencja obejmowała kilka adresów IP. Przecież cała weryfikacja następuje po stronie serwera, więc nie ma czegoś takiego, że raz wydana licencja jest zawsze ważna, możemy ją wywalić z bazy i tym sposobem unieważnić.

W ten sposób można również tworzyć licencje demo, na np 30 dni... Albo abonamentową

1. plik licencyjny, zwykły plik TXT, dla przykładu:

312337:Jan Kowalski:ul. Zbożowa 37:30-072 Kraków:127.0.0.1
24roTquoKX1BYQ4Lbs8fO9dPTLYg/lLu7UFdPBURnfg=

Dane to po kolei (1 linia) ID licencji, imię i nazwisko osoby na którą jest wykupiona licencja, adres, kod pocztowy, miasto i IP na który wykupiona jest licencja.

WSZYSTKIE te dane zapisujesz również po stronie serwera. W pliku licencyjnym właściwie może znajdować się samo ID licencji, ale w ten sposób można po samym pliku zidentyfikować do kogo należy licencja

2 linia to zahashowana 1 linia, jednak na końcu został doklejony klucz, o treści tajnyklucz. Oczywiście Twój klucz powinien być inny Algorytm użyty do wygenerowania klucza to PBKDF2 SHA256 z 1000 iteracji. Powinniśmy tutaj bardziej skomplikowany algorytm wykorzystywać, gdyż odczytanie tajnego klucza umożliwi obejście licencji. Klucz został zapisany w base64, bo mniej znaków zajmuje, niż wartość w hex

W bazie danych po stronie serwera licencyjnego powinniśmy również przechowywać tajnyklucz.

Plugin następnie łączy się socketem z serwerem licencyjnym, przesyłając mu zawartość pliku. Serwer pobiera z bazy dane licencji (korzystając z ID), sprawdza czy reszta danych pasuje do licencji i co bardzo ważne, sprawdza czy połączenie zostało nawiązane z tego samego IP, na które wystawiona jest licencja.

Jeśli to się zgadza, przechodzimy do weryfikacji samej licencji. Serwer licencyjny generuje hash na podstawie danych z bazy i sprawdza, czy jest on taki sam, jak hash otrzymany z pluginu. Jeśli się zgadza, odsyłany do pluginu jest pozytywny wynik operacji (gdyby to było możliwe, kawałek kodu niezbędny do uruchomienia pluginu), gdy jest negatywny, odsyłamy niepowodzenie i plugin się blokuje.

Jeszcze ciekawsze by było, gdyby AMXX potrafił uruchomić kod wygenerowany w locie. Wtedy serwer licencyjny po zweryfikowaniu licencji, wysyłałby kawałek kodu, który jest niezbędny do działania pluginu. Kod taki siedziałby w pamięci RAM, więc byłby ciężki do "odzyskania". Pod warunkiem, że transmisja kodu byłaby szyfrowana, co też nietrudno uzyskać 

 

Jest to możliwe do zaimplementowania w samym amxmodx  cóż chyba trzeba wysłać ticket do arkshine

Jeśli już tak bardzo chcecie zabezpieczać, IP zapiszcie w formie liczby całkowitej (wszak adres IP ma dokładnie 32 bity), a nie w formie stringa, bo taki string da się bardzo łatwo podmienić, bo przecież widać od razu gdzie on leży w kodzie. Lepiej więc "docelowy" adres IP zapisać w formie, która nie jest łatwa do odczytania, następnie adres IP serwera sprowadzić do tej samej postaci przed porównaniem i dopiero wtedy porównać.

Porównanie również można zamaskować (żeby ktoś go nie podmienił na true, albo nie wynopował jeśli jest użyty warunek w postaci if(!warunek) return.... Choćby porównywać w jakiś sprytny sposób bit po bicie albo wykonywać szczególne operacje matematyczne. pomysłów jest wiele.

Inną ciekawą opcją jest "serwer licencyjny". Generujesz licencję (może być to prosty plik tekstowy z ID licencji, adresem IP serwera i danymi osoby posiadającej licencję), wyliczasz dla tej licencji hash z solą (ale nie jakieś proste MD5, jak już szaleć to na całego: PBKDF2 + SHA256 lub BCrypt + SHA256 z jakąś rozsądną liczbą iteracji). Sól powinna być unikalna dla każdego pliku licencyjnego i nieujawniana, w ten sposób nikt nie ma szans podrobić pliku licencyjnego mimo, że wie jak jest generowany. Twój "zamaskowany" plugin wysyłałby nawet samo ID + hash do serwera licencyjnego, a ten po swojej stronie generuje ponownie hash z danych zapisanych w bazie i sprawdza czy jest identyczny z tym przesłanym z serwera.

Jeszcze ciekawsze by było, gdyby AMXX potrafił uruchomić kod wygenerowany w locie. Wtedy serwer licencyjny po zweryfikowaniu licencji, wysyłałby kawałek kodu, który jest niezbędny do działania pluginu. Kod taki siedziałby w pamięci RAM, więc byłby ciężki do "odzyskania". Pod warunkiem, że transmisja kodu byłaby szyfrowana, co też nietrudno uzyskać

1. Licencja AMXX wymaga, aby pluginy były wypuszczane pod tą samą lub kompatybilną licencją. Plugin musi więc być otwartożródłowy. Wszelkie zaciemnianie kodu lub brak dystrybucji kodu źródłowego wraz z pluginem jest więc nielegalne.

2. Zabezpieczyć plugin możesz... ale jeśli jest on otwartoźródłowy to każdy może sobie go zmodyfikować i zabezpieczenie usunąć. Gra więc nie warta świeczki.

3. Wszystko powyższe nie oznacza, że nie możesz sprzedawać pluginu. Ależ możesz... musisz jednak sprzedać go wraz z kodem

4. Jest jeszcze jedno zastrzeżenie do tej licencji: jeśli ktoś plugin kupi, może z nim zrobić co chce, również opublikować za darmo w internecie. Może go umieścić na dowolnych serwerach, może zrobić z nim co chce, o ile będzie zachowana informacja o autorze/źródle pluginu.

to też da się oszukać
żeby zabezpieczyć się przed SQL Injection lepiej użyć replace_all i podmieniać znaki specjalne

Oprócz tego co napisałe grankee powinno być:
Zamiast:

format(qCommand, sizeof qCommand-1, "INSERT INTO nauka VALUES(%s, %i, %i);", szName, iPlayerXP[id], iPlayerLvl[id])

Tak:

format(qCommand, sizeof qCommand-1, "INSERT INTO `nauka` VALUES('%s', %i, %i);", szName, iPlayerXP[id], iPlayerLvl[id])

Oraz zamiana miejscami w funkcji SaveHandler:

Errorcode, Error[]

Przydałoby się też omówić aktualizację danych, ponieważ teraz tylko zapisuje przy piewszym wejściu.

Po testach stwierdzam, że można to jeszcze dodatkowo zabezpieczyć.
W obecnej formie będzie sypać błędami, gdy gracz będzie miał w nicku np. '
Aby się przedym zabezpieczyć trzeba zamiast

'%s'

zrobić tak:

^"%s^"

Zarówno przy sprawdzaniu bazy danych jak i przy zapisywaniu nowego gracza.