GwynBleidD

nvault_prune

 

Wykonujesz funkcję od czasu 0 do aktualnego czasu albo jakiegoś z przyszłości i plik jest pusty.

Ten kod będzie przy każdym thinku aktualizował rendering gracza, jeśli ten kuca, a wystarczy zaktualizować gdy zaczyna kucać i gdy przestaje kucać. Sprawdzaj oldbutton i reaguj tylko wtedy, gdy nastąpiła zmiana. Wystarczy dodać na początku thinka (po sprawdzeniu czy gracz ma dany perk) to:

if(!((get_user_oldbutton(id) ^ get_user_button(id)) & IN_DUCK))
    return;

Jak to działa? operator ^ to operator XOR, zwróci on jedynkę na danym bicie tylko wtedy, gdy bit w obu porównywanych wartościach jest różny, czyli:

0b00010100
0b00010010
XOR =
0b00000110

W ten sposób zaświecają nam się bity klawiszy, które zostały w danym thinku zmienione. Nas interesuje tylko duck, więc dodatkowo przepuszczamy to przez & i viola

 

Oczywiście przerzuć kod do cmd start, jak sugerują inni.

Im nowszy metamod, tym lepszy. Różnica w wydajności jest znikoma, chociaż niektórzy twierdzą że metamod-p zdecydowanie lepiej działa na procesorach AMD, osobiście nie odczułem nigdy różnicy.

Metamoda v.1.19 nie użyjesz na najnowszych binarkach, musisz zejść z binarkami poniżej wersji 6000, a to oznacza również zmianę AMXX na 1.8.1, więc jeśli nie jest Ci to koniecznie potrzebne - nie rób tego.

Mówiłem, że zapytanie jest OK!

To, jakie kolumny zwróci Ci z bazy danych kompletnie nie zależy od tego co jest po WHERE w zapytaniu, zależy to od tego co jest pomiędzy SELECT, a WHERE. W tym przypadku jest *, która oznacza wszystkie kolumny.

W trie trzymasz niewidzialność dla każdego pluginu/perka/klasy czy czego tam chcesz. W arrayu będzie z tym problem, dlaczego?

Załóżmy, że masz 1 klasę, 2 perki i jeszcze jakiś item, wszystkie dają niewidzialność, klasa daje w zależności od levelu, perki i item zawsze tyle samo.

Niech będzie, że perk 1 daje 20%, perk 2 daje 30% i item daje też 30%.

Gracz ma klasę, perka 1 i item, akurat ma taki level, że level daje mu 20%, w Arrayu jest więc zapisane: 20% 20% 30%, gracz zmienia perk na ten drugi, co robisz?

Już masz zrobione!

Problem nie leży w zapytaniu, tylko z pobraniem wyników tego zapytania. Poczytaj o SQL_ReadResult i SQL_FieldNameToNum.

A jakby w jakiejś tablicy trzymać wszystkie wartośći, które mu dodałem?

Musisz w jakiś sposób śledzić jaki plugin ustawił jaką wartość - stąd pomysł z trie, bo wtedy możesz sobie każdą zmianę "podpisać" Właściwie to rejestrowania tutaj nawet nie potrzebujesz, po prostu zmienić.

Będę mieć id gracza lub nazwe (Trie lub Array), do tego dochodzą jeszcze wartośći, które muszą być trzymane pod jednym kluczem (wyciągam wszystkie i wybieram największą

Array trzymający Array?

new Trie:invisibility[33];

new client_connect(id) {
    invisibility[id] = TrieCreate()
}

to Ci coś mówi?

Prawdopodobnie będziesz potrzebował tandemu - Array + Trie, inaczej ciężko będzie znaleźć najmniejszą wartość. W Arrayu trzymasz klucze z Trie, dzięki czemu możesz po Trie iterować.

Problem jest, ale nie aż tak poważny... Wcale nie musisz trzymać tego w 1 pluginie

 

1. Rejestrujesz natyw o nazwie dla przykładu przelicz_niewidzialnosc

2. Dla każdego pluginu, który choć raz użył tego natywu rejestrujesz forward

3. W forwardzie każdy plugin, który korzysta z niewidzialności przy każdym jego wykonaniu dla danego gracza, określa jaką powinien mieć niewidzialność - jeśli ma np perk, ustalamy mu 20%, jeśli nie ma nic, ustalamy mu 100% (czyli widoczny). Wynik po prostu zostaje zwrócony w forwardzie

4. Po wykonaniu wszystkich forwardów plugin główny wybiera najmniejszą wartość lub dokonuje jakichś "szacunków" żeby wyliczyć wartość na innej podstawie (np średnią)

 

Jeśli chcesz zmienić niewidzialność graczowi, dbasz o to by Twój plugin w forwardzie zwrócił odpowiednią wartość, a następnie wykonujesz przelicz_niewidzialnosc.

 

Podejście numer dwa - lista niewidzialności.

 

1. Rejestrujesz 2 natywy: zarejestruj_niewidzialnosc i ustaw_niewidzialnosc

2. zarejestruj_niewidzialnosc tworzy nowy wpis w trie w którym jako klucz podajesz swoją dowolną, unikalną nazwę (czyli np dla perku XX będzie to po prostu perk_XX), a jako wartość 100% (czy tam 255, czy 1, czy cokolwiek innego, zależy od tego jak niewidzialność jest ustawiana) oznaczającą brak niewidzialności

3. gdy plugin chce zmienić graczowi niewidzialność, wykonuje ustaw_niewidzialnosc z odpowiednią wartością, plugin główny zapisuje ją na odpowiednniej pozycji w trie i wybiera z trie najmniejszą wartość, ustawiając ją graczowi. Jeśli trie jest puste, ustawia brak niewidzialności.

 

przykład użycia:

zarejestruj_niewidzialnosc('perk_superasny')

ustaw_niewidzialnosc(id, 'perk_superasny', 30)

 

Podejście numer trzy - własny system (np punktowy)

 

Ustalasz jakiś system punktowy, od którego będzie zależeć ile niewidzialności ma gracz, każdy plugin będzie mógł dodać punkty lub je zabrać.

 

Podejście numer cztery - sprawdzanie wartości niewidzialności

 

Każdy plugin będzie posługiwał się wartościami od 0.0 do 1.0, jeśli będzie chciał ustawić graczowi niewidzialność:

1. pobierze jego aktualny poziom niewidzialności

2. przemnoży go przez swoją wartość

3. ustawi otrzymaną liczbę jako wartość niewidzialności

 

Jeśli będzie chciał zabrać, po prostu zamiast mnożenia użyje dzielenia.

 

W ten sposób jeśli 1 plugin ustawi graczowi niewidzialność na 0.5 i drugi również na 0.5, dostanie on w efekcie wartość 0.25.

Po linii 165 dopisz:
 

ColorChat(0, RED, "^3ADMIN:^1 Wykopał gracza %s, ^4powód: ^1%s", name[1], powod)

I dodaj #include <colorchat> lub #include <chatcolor> (zalecane to 2, powyżej wersji 1.8.3 AMXX nie musisz instalować nic dodatkowo).

Bo po 1. robisz to ŹLE!

 

Jaki sens jest w zapisywaniu daty bana jako string w bazie danych? Powodzenia później w próbie wybrania wszystkich banów z konkretnego dnia, dla przykładu.

 

Jaki jest sens rezygnowania z powodu bana i próby zapisania daty zamiast niego?

 

Po 2. sam sobie nadpisujesz poprzednio pobraną datę, powodem bana. Linia 17 w Twojej wklejce, wystarczy ją usunąć.

 

Zrób to po ludzku i dodaj nową kolumnę w bazie danych, w której będziesz zapisywał czas bana.

Taka to raczej nie zadziała A to już jest Twoja broszka, bo nie wiem jak w samym pluginie przechowujesz kto ma jakie skiny.

Przedstawmy to bitowo:

new VULCAN      = 0b00000001
new REDLINE     = 0b00000010
new ASSIMOV     = 0b00000100
new FIRESERPENT = 0b00001000

W ten sposób każdy skin ma swój bit. Żeby przydzielić graczowi skin robisz tak:

skiny[id][weapon] |= REDLINE

Aby odebrać:

skiny[id][weapon] &= ~REDLINE

Aby sprawdzić czy ma dany skin:

if (skiny[id][weapon] & REDLINE)

Aby sprawdzić czy ma kilka skinów na raz:

if ((skiny[id][weapon] & (REDLINE|ASSIMOV|FIRESERPENT)) == (REDLINE|ASSIMOV|FIRESERPENT))

Aby sprawdzić czy ma którykolwiek z tych 3 skinów:

if (skiny[id][weapon] & (REDLINE|ASSIMOV|FIRESERPENT))

To, co jest w zmiennej skiny[id][weapon] zapisujesz do bazy (lub odczytujesz z bazy liczbę bezpośrednio do tej zmiennej). Proste?

I nie potrzebujesz kilku zapytań:

INSERT INTO `CSGOMOD` (`name`, `weapon`, `skin`) VALUES ('gracz', 'ak47', 3), ('gracz', 'm4a1', 2) ON DUPLICATE....

INSERT INTO CSGOMOD (`nick`, `weapon`, `skin`) VALUES ('%s', '%s', %d) ON DUPLICATE KEY UPDATE `nick`=VALUES(`nick`), `weapon`=VALUES(`weapon`), `skin`=VALUES(`skin`);

W ten sposób dodajesz lub aktualizujesz jednego gracza, a tutaj:

INSERT INTO CSGOMOD (`nick`, `weapon`, `skin`) VALUES ('%s', '%s', %d), ('%s', '%s', %d), ('%s', '%s', %d) ON DUPLICATE KEY UPDATE `nick`=VALUES(`nick`), `weapon`=VALUES(`weapon`), `skin`=VALUES(`skin`);

trzech na raz

 

Jako skin używasz po prostu liczby.

 

 

SELECT * FROM `CSGOMOD` WHERE `nick` = '%s' AND `weapon` = 'AK47'

Tutaj nie musisz w warunku podawać weapon, pobierzesz wtedy wszystkie bronie dla danego gracza.

 

UPDATE CSGOMOD SET skin='%d' WHERE nick='%s' AND weapon='AK47'

Tego nie potrzebujesz, aktualizacją zajmie się:

INSERT INTO CSGOMOD (`nick`, `weapon`) VALUES ('%s', 'AK47') ON DUPLICATE KEY UPDATE `nick`='%s', `weapon`='AK47';

jeśli masz prawidłowo unikalne klucze ułożone. Oczywiście musisz dodać do tego zapytania skin. Zalety? Możesz zaktualizować wiele rekordów jednym zapytaniem (wszystkich na serwerze) i nie musisz w kodzie rozróżniać tworzenia od aktualizacji danych.

Tak, istnieje.