oeN.

Mam duże perspektywy jak i środki finansowe

- donatorzy, 

- małej pomocy finansowej, 

To się razem nie klej. Ładnie napisane, wreszcie jakieś konkrety. Sam zaoferować od siebie nie mogę nic więcej niż ogólną pomoc tutaj Ale Good luck. Polecam Ci także przejść się po profilach PU/aktywnych userów i wyłapać tych, którzy nie świecą tylko ilością postów a także umiejętnościami - nadal tutaj takich mamy

Jest to prosty tut obrazujacy, sposob w jaki mozemy zmieniac weaponorigin w modelach broni. Przydaje nam sie to jezeli chcemy np dodac celowniki do pluginu cwz: https://amxx.pl/topi...weapon-zoom-15/.

 

A wiec na poczatku musimy posiadac jakis model z przedrostkiem v_. Otwieramy go za pomoca programu Jed's Half-Lie Model Viewer a nastepnie decompilujemy nasz model. By to zrobic, musimy pierw skonfigurowac w poprawny sposob program, wskazujac lokalizacje do compilatora oraz decompilatora (Tools>Configure Tools i wskazujemy sciezki).

 

Okej, jezeli posiadamy juz zdekompilowany model, otwieramy jego plik .qc (Tools>Edit QC File, badz otwieramy go po prostu notatnikiem). Klikamy teraz w programie na zakladke "Weapon Origin" i zaznaczamy ptaszkiem "Show Crosshair". Nastepnie zmieniamy weaponorigin X/Y/Z na nasze wlasne. Po tej edycji musimy zapisac zmiany w naszym otwartym pliku qc. A wiec gdzies na gorze dodajemy $origin i wpisujemy wartosc x/y/z (np $origin 2.800000 1.000000 -1.000000). Juz wystarczy tylko nadpisac zmiany w pliku a nastepnie skompilowac plugin (Tools>Compile Model).

 

Jezeli zrobilismy wszystko w prawidlowy sposob, od teraz bedziemy mogli cieszyc sie naszym nowym celownikiem. Nizej wersja ilustrowana.

 

 

Podziel obrażenie przez 10 z resztą -> https://pl.wikipedia.org/wiki/Modulo, a potem je wyzeruj, obejdzie się bez while

Jeżeli nie napisałem kodu poprawnie, udowodnij mi błąd i pokaż, że plugin nie będzie działał w praktyce Było to moje ponowne spotkanie z amxx'em po długiej przerwie, błąd każdemu może się zdarzyć tak jak i mi w pierwszym poście. Tacy odważani delikwenci jak Ty byli już na tym forum i nie skończyli zbyt dobrze. Ale pierwszy raz mi się zdarza takie prostactwo i bezczelność ze strony kobiety. Nie traktuj tego jako groźby, a raczej jako przestrogę aby na przyszłość podchodzić do czegoś z dystansem i nie reprezentować sobą pyszałkowatego zachowania.

Co do kodu. Prawda, nie doczytałem dokładnie próśb autora aby menu otwierało się graczu wybranemu. Już poprawione.

Jest to prosty interfejs www służący do dekompilowania pluginów amxx'a i sourcemoda.
 
Dekompilator dostępny pod adresem
 
http://darkgl.pl/decompiler/

Jest to tylko interfejs www który używa ogólnie dostępnych narzędzi.
 
Więcej informacji tutaj
http://darkgl.pl/201...d-dekompilator/

http://amxx.pl/topic...rawiony-działa/

no to mozna zrobic aby pierwsza lutera byla duza lub wszystkie duze

public GetWeaponName(id, szReturn[], iLen)
{
	if(get_weaponname(get_user_weapon(id), szReturn, iLen)) {
		replace(szReturn, iLen, "weapon_", "");
		ucfirst(szReturn); // pierwsza litera z duzej np. knife -> Knife
		strtoupper(szReturn) // pelna nazwa broni z duzych liter np. knife -> KNIFE
		copy(szReturn, iLen, szReturn);
		return PLUGIN_HANDLED;
	}
	return PLUGIN_CONTINUE;
}

public GetWeaponName(id, szReturn[], iLen)
{
	new szName[24];
	if(get_weaponname(get_user_weapon(id), szName, 23)) {
		replace(szName, 23, "weapon_", "");
		copy(szReturn, iLen, szName);
		return PLUGIN_HANDLED;
	}
	return PLUGIN_CONTINUE;
}

przyklad

new szWeapon[24];
GetWeaponName(id, szWeapon, 23);
ColorChat(id, RED, "^x04 *^x03 (%s)^x01 Zadales dotychczas^x03 %d^x01 obrazen.", szWeapon, Damage[id]);

Po co te kombinacje?

Owszem, suma bitowa jest fajnym rozwiązaniem i nawet bym je zastosował (w zapytaniach SQL też można stosować operacje bitowe, więc nadal będzie możliwość znalezienia graczy, którzy mają X w broni Y.
 
Ale...
 

+----+------+--------+-------------+
| id | nick | weapon |  properties |
+----+------+--------+-------------+
|  1 | oeN. | AK47   |  0b00001111 |
|  2 | oeN. | M4A1   |  0b00001001 |
|  3 | oeN. | Scout  |  0b00000000 |
|  4 | oeN. | AWP    |  0b00001100 | 
|  5 | FRoM | AK47   |  0b00001100 |
+----+------+--------+-------------+

Jedna tabela, bez niepotrzebnych kolumn. Jak sobie kiedyś wymyślisz żeby wybrać wszystkich graczy mających X na dowolnej broni to jest to bajecznie proste, dodasz kiedyś nową broń to nie będziesz musiał nic w strukturze bazy danych ruszać. Prawda, że ładniej? Jak potrzebujesz pomocy przy tworzeniu zapytań to dawaj śmiało.

 

I nigdy nie zapominaj o kolumnie id, kiedyś np przez błąd w pluginie doda Ci się do bazy 10 rekordów z tym samym nickiem gracza i będzie mu losowo wybierało co już odblokował jak wejdzie na serwer. Ciekawe jak bez ID usuniesz tylko niepotrzebne rekordy, zostawiając jeden?

 

No i nie zapomnij o unikalnych indeksach, tutaj np para kolumn nick i weapon powinna być objęta kluczem unikalnym, żeby mieć pewność że dla żadnego gracza nie utworzą się 2 rekordy dla tej samej broni.

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.

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.

 

 

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....

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

Ja wiem jak działają operacje na sumach bitowych, jest to optymalne i w ogóle ale też się ciężko na nich operuje.

 

No raczej nie...

 

Czy sprawdzanie czy gracz posiada daną flagę uprawnień jest niewygodne w AMXX? A działa to właśnie na bitach.

 

Zamiast tego:

new g_PlayerSkin1[33], g_PlayerSkin2[33], g_PlayerSkin3[33], g_PlayerSkin4[33], g_PlayerSkin5[33];
new g_PlayerSkin6[33], g_PlayerSkin7[33], g_PlayerSkin8[33], g_PlayerSkin9[33], g_PlayerSkin10[33];
new g_PlayerSkin11[33], g_PlayerSkin12[33];

 

umieszczasz to:

new g_PlayerSkins[33];

 

Zamiast tego:

    if(item == 0)
        return ITEM_ENABLED;
        
    else if(item == 1 && !g_PlayerSkin1[id])
        return ITEM_DISABLED;
    
    else if(item == 2 && !g_PlayerSkin2[id])
        return ITEM_DISABLED;
    
    else if(item == 3 && !g_PlayerSkin3[id])
        return ITEM_DISABLED;
 
    // ... i tak dalej i tak dalej ...

 

umieszczasz to:

    if (item > 0 && item <= 32 && !g_PlayerSkins[id] & (1<<(item - 1)) {
        return ITEM_DISABLED;

    return ITEM_ENABLED;
    // NIC WIĘCEJ!

 

Dalej twierdzisz, że jest na tym operować gorzej?

 

Jak nie lubisz posługiwać się operatorami bitowymi to można sobie odpowiednie aliasy i funkcje do tego utworzyć.

 

Polecam stworzyć kilka funkcji:

 

/** 1. sprawdzenie czy gracz posiada model: */
stock user_hasSkin(id, skin) {
    return g_PlayerSkins[id] & (1 << skin) == (1 << skin) // porównanie jest dodane po to, by zawsze otrzymywać 1 lub 0, co czasem może mieć znaczenie
}
 
/** 2. przypisanie graczowi modelu: */
stock user_giveSkin(id, skin) {
    g_PlayerSkins[id] |= (1 << skin)
}
 
/** 3. odebranie graczowi modelu: */
stock user_takeSkin(id, skin) {
    g_PlayerSkins[id] &= ~(1 << skin)
}
 
/** 4. wyczyszczenie graczowi modeli: */
stock user_takeSkin(id, skin) {
    g_PlayerSkins[id] = 0;
}
 
// 2 dodatkowe funkcje, wydają się na pozór mało przydatne ale za chwilę się okaże do czego służą
/** 5. export modeli (do zapisu w nvault, bazie danych itp): */
stock user_writeSkin(id, string[], length) {
    num_to_str(g_PlayerSkins[id], string, length);
}
/** 6. import modeli (z bazy danych, nvault itp): */
stock user_readSkin(id, string[]) {
    g_PlayerSkins[id] = str_to_num(string);
}

 

W ten sposób posługujesz się bardzo wygodnymi funkcjami.

Mówią ludzie o limicie do 32 czy tam do 31 itemów. Owszem istnieje taki. Nie jestem pewien czy maksymalnie możemy przechować 32 czy 31 bitów (ostatni bit jest wykorzystywany jako znak liczby i może stanowić problemy, ale nigdy tego w praktyce w AMXX nie sprawdzałem) ale...

new g_PlayerSkins[33][2];

już mamy 62 itemy maksymalnie I tu się wyjaśnia dlaczego stworzyłem 2 dodatkowe funkcje (5 i 6) do eksportu i importu. Wystarczy teraz te 6 funkcji zmodyfikować:

 

/** 1. sprawdzenie czy gracz posiada model: */
stock user_hasSkin(id, skin) {
    return g_PlayerSkins[id][skin/31] & (1 << (skin % 31)) == (1 << (skin % 31)) // porównanie jest dodane po to, by zawsze otrzymywać 1 lub 0, co czasem może mieć znaczenie
}
 
/** 2. przypisanie graczowi modelu: */
stock user_giveSkin(id, skin) {
    g_PlayerSkins[id][skin/31] |= (1 << (skin % 31))
}
 
/** 3. odebranie graczowi modelu: */
stock user_takeSkin(id, skin) {
    g_PlayerSkins[id][skin/31] &= ~(1 << (skin % 31))
}
 
/** 4. wyczyszczenie graczowi modeli: */
stock user_takeSkin(id, skin) {
    for (new i=0; i<2; ++i)
        g_PlayerSkins[id][i] = 0;
}
 
// 2 dodatkowe funkcje, wydają się na pozór mało przydatne ale za chwilę się okaże do czego służą
/** 5. export modeli (do zapisu w nvault, bazie danych itp): */
stock user_writeSkin(id, string[], length) {
    new count = 0;
    for (new i=0; i<2; ++i) {
        count += num_to_str(g_PlayerSkins[id][i], string[count], length);
        string[count] = ' ';
    }
    string[count] = '^0';
}
/** 6. import modeli (z bazy danych, nvault itp): */
stock user_readSkin(id, string[]) {
    new count = 0;
    new left[16], right[256];
   
    for (new i=0; i<2; ++i) {
        strtok(right, left, 15, right, 255)
        g_PlayerSkins[id][i] = str_to_num(left);
    }
}

 

W ten sposób nie musisz nic więcej zmieniać w kodzie (no może prócz wielkości tablicy na string do zapisania w nvault).

 

Pamiętaj tylko, żeby istniejący nvault przekonwertować. Możesz to zrobić w prosty sposób:

1. stwórz oddzielny plugin

2. zainstaluj i użyj w nim nVault Utility

3. wymyśl sobie jakiś specjalny klucz w którym będziesz przechowywał wersję pliku (musi być on unikalny - upewnij się żeby dla żadnego gracza się taki klucz nie zapisał. Dla przykładu użyj na jego początku czegoś, co nigdy nie wystąpi w nicku gracza, adresie IP ani steam ID)

4. odczytaj klucz wcześniej wymyślony, jeśli go nie ma to przyjmij że nvault jest w starej (pierwotnej) wersji. Jeśli jest, odczytaj wartość żeby się dowiedzieć jaką wersję masz.

5. Dokonaj konwersji (jeśli konieczna), lecąc po wszystkich kluczach w nvault (za pomocą Utility) i zmieniając format.

 

Plugin po udanej konwersji wyłączyć. Na przyszłość jak coś będziesz w pliku zmieniał to masz gotową bazę i zapisaną wersję

g_PlayerSkin[33][12]

Ale wtedy musialbys liczyc skiny od 0 albo od 1 i ustawić rozmiar drugiego indeksu na 13.

I wtedy ten callback można zrobić pętlą.