BlackPerfum

zrobić skrót

Jak zmienić parametry kompilacji w kompilatorze lokalnym?

kompilatorze lokalnym

Już zagoniono mnie do roboty... Dopiero co wróciłem a każą mi pracować. Niedorzeczne, zaprośili byście na piwo a nie

Co do perków to wyglądają jak    jeśli chce ktoś się dopytać o szczegóły błedów to proszę pisać od tak książki nie chce mi się pisać...

Hahaha kto to wymyślił "naćpane naboje" Chciał bym takim dostać hahahaha

Nie chce mi się sprawdzać czy działa a pewnie gdzieś gape walnełem. Powiedzmy że to psedo kod heh:

postanowiłem poszukać stocka

Rozwiazaniem było by użycie funkcji funkcji clamp/cs_get_user_team/get_pdata_int z offsetem team'u

Kiedy usunę tę linijkę to muszę zincludować tę drugą bibliotekę, bo inaczej sypie błędami

pobierz najnowsze pliczki .inc amxmodx'a lub skompiluj na amxx.pl Tyle trudu

Musiałbym wszędzie zmieniać funkcję ColorChat, bo ta którą podałeś ma inny układ.

client_print_color

#include <colorchat>

	if(ColorChange)
	{
		Team_Info(index, MSG_Type, TeamName[team]);
	}

new TeamName[][] = 
{
	"",
	"TERRORIST",
	"CT",
	"SPECTATOR"
}

clamp

cs_get_user_team

get_pdata_int

1. Czym jest według Ciebie pisanie racjonalne?

2. Można oczywiście ExecuteHamB użyć, proponowałem ExecuteHam, bo nie ma sensu żeby handler się wykonywał jeszcze raz, ale może... skoro na początku sprawdzamy, czy wyciągana broń jest "legalna" to nie ma z tym problemów żadnych przecież, bo dużo się nie wykona... A pewność, że zostanie wyciągnięta właściwa broń, która może być wyciągnięta jest taka sama, jak przy rekurencji, tylko warunek trzeba 2 razy umieścić (w rekurencji wykona się on dokładnie tyle samo razy, albo z niewielką różnicą, mimo że umieszczony jest raz).

ExecuteHamB

ExecuteHam

3. Czemu według Ciebie rozdzielanie kodu pomiędzy pluginy to wada? Według mnie duża zaleta, ale pod warunkiem, że się wie co się robi... Po 1. możemy wyłączyć konkretną rzecz wyłączając po prostu 1 plugin, po 2. jeśli coś nie działa to wiemy gdzie szukać, po 3. łatwiej jest utrzymać porządek i wiadomo co jest do czego... zalet jest jeszcze więcej...

A co do rekurencji: wyobraź sobie przypadek, że tworzymy przedmiot, który pozwala on nam na podnoszenie broni innych klas (dzięki czemu możemy mieć broni aż 10), ale działa do końca rundy, po rundzie znika. Zbierzemy sobie więc 10 broni... Mamy również na serwerze szansę na wylosowanie niewidzialności przy zmianie broni... albo cokolwiek innego przy zmianie broni...

Przychodzi nowa runda, zmieniamy broń na broń z innej klasy, przedmiot nam już wygasł więc plugin nam tą broń wyrzuca i zmienia broń na następną... Pech chciał, że akurat są w takiej kolejności, że broń "legalna" jest na końcu... Policz sobie teraz ile razy wykona się niepotrzebnie losowanie niewidzialności czy cokolwiek sobie tam wymyślisz przy zmianie broni, gdy używasz rekurencji? Tak trąbisz o tej kompatybilności z innymi pluginami, a właśnie w tym miejscu jej nie zachowujesz, bo wykonujesz 10x niepotrzebnie ExecuteHamB, przez co inne pluginy niepotrzebnie podejmują akcje, jeśli są pod zmianę broni podpięte...

ExecuteHam

ExecuteHam

Popatrz na to zarówno przez pryzmat wydajności jak i przez każdy inny... Dlatego rekurencji zrealizowanej w TAKI SPOSÓB nie powinno się nawet do myśli dopuścić. Potrzebna Ci rekurencja i faktycznie umiesz się nią posługiwać (a naprawdę mało kto ją do końca rozumie, miałem na studiach przez cały semestr przedmiot poświęcony tylko rekurencji i widziałem jak dużo osób tego kompletnie nie rozumie... a na kierunek dostały się osoby z wynikami matur rozszerzonych 80% i wyżej) to jej użyj, ale wewnątrz pluginu, a nie poprzez Ham czy inne sposoby angażujące inne pluginy i mechanizmy serwera...

Ogułem to od razu mówię że pomimo wstawiania się za rekurencją nie jestem za nią gdyż nie jestem za użyciem Deploy'a bo to jest do pewnego stopnia (bardzo bardzo małego) nie racjonalne. Lepiej łapać dodawanie broni. A najlepiej to nie dodawac nie właściwych broni ;D

Które będzie najlepsze?

Lepiej łapać dodawanie broni. A najlepiej to nie dodawac nie właściwych broni ;D

A najlepiej to nie dodawac nie właściwych broni ;D

W kodzie ktory podales uzywasz RemovePlayerItem+pev_weapons+ItemKill. Czy to nie za dużo?

Mógłbyś podrzucić kod z Ham_AddPlayerItem? Chciałbym przetestować jak to działa.

public plugin_init()
{
	RegisterHam(Ham_AddPlayerItem, "player", "AddItem")
}

public AddItem(id,ent)
{
	new wid = cs_get_weapon_id(ent)
	if(is_user_alive(id) && ~(bronie_klasy[klasa_gracza[id]] | bonusowe_bronie_gracza[id] | bronie_dozwolone) & 1<<wid)
	{
		ExecuteHamB(Ham_Item_Kill, ent)
		return HAM_SUPERCEDE
	}
	return HAM_IGNORED
}

1. czy dostrzegasz w tym rozwiązaniu rekurencję?

2. czy jest ona niezbędna?

3. Czy potrafisz przewidzieć WSZYSTKIE warunki wyjścia z niej i dopilnować, aby zawsze nastąpiło wyjście z niej?

Rozumiem argument, że broń nie zmieni się poprawnie, jeśli w PRE podmienimy parametr, dlatego owszem należy wywołać zmianę broni jeszcze raz, ale po co tu rekurencja...

Przelećmy pętlą po wszystkich broniach gracza w Poście (bo Pre nie ma sensu używać, jeśli nie podmieniamy zmienianej broni) i po wyrzuceniu niepotrzebnych zmieńmy na jedną z tych, które gracz użyć może, jednak już używając execute bez B...

Tworzenie rekurencji poprzez Ham jest niezalecane i to mocno... w jakimkolwiek przypadku... Nie dość, że sam pawn rekurencji nie optymalizuje, więc wychodzi ona dużo bardziej kosztownie, niż pętle, to jeszcze przy okazji mielimy wszystkim, co silnik robi podczas zmiany broni + wszystko co po drodze robi Ham i niech nam jeszcze do tego samego eventu inny plugin się podepnie... Istna katorga i nie dziwię się, że serwer by padł tylko od tego, nawet gdy rekurencja zakończy się prawidłowo.

Czyli jak juz chce deploy to post?

Czy Ham_AddPlayerItem wywołuje się wtedy gdy gracz otrzymuje item?

ExecuteHam

ExecuteHamB

Dlaczego w twym kodzie nie ma pętli po slotach?

SetHamParamEntity

const m_pActiveItem = 373
const m_pPlayer = 41
const m_pClientActiveItem = 374
const m_iszViewModel = 68

public Deploy(ent)
{
	new id = get_pdata_cbase(ent, m_pPlayer, 4)
	new wid = cs_get_weapon_id(ent)

	if(is_user_alive(id) && ~(bronie_klasy[klasa_gracza[id]] | bonusowe_bronie_gracza[id] | bronie_dozwolone) & 1<<wid)
	{
		new weapon = get_pdata_cbase(id,m_pClientActiveItem,5)
		set_pdata_cbase(id,m_pActiveItem,weapon,5)
		ExecuteHamB(Ham_RemovePlayerItem, id, ent)
		set_pev(id, pev_weapons, pev(id, pev_weapons) & ~(1<<wid))
		ExecuteHamB(Ham_Item_Kill, ent)
		SetHamParamEntity(1,weapon)
		set_pev(id,pev_viewmodel,get_pdata_int(weapon,m_iszViewModel,4))
		return HAM_OVERRIDE
	}
	return HAM_IGNORED
}

Zmień new i na new i=0, chociaż wątpię, by to było problemem...

Możesz wyjaśnić dlaczego sprawdzasz tutaj tylko wartość 2?

set_pdata_cbase

ExecuteHamB

const m_pActiveItem = 373
const m_pPlayer = 41
const m_pClientActiveItem = 374

public Deploy(ent)
{
	new id = get_pdata_cbase(ent, m_pPlayer, 4)
	new wid = cs_get_weapon_id(ent)

	if(is_user_alive(id) && ~(bronie_klasy[klasa_gracza[id]] | bonusowe_bronie_gracza[id] | bronie_dozwolone) & 1<<wid)
	{
		new weapon = get_pdata_cbase(id,m_pClientActiveItem,5)
		set_pdata_cbase(id,m_pActiveItem,weapon,5)
		ExecuteHamB(Ham_RemovePlayerItem, id, ent)
		set_pev(id, pev_weapons, pev(id, pev_weapons) & ~(1<<wid))
		ExecuteHamB(Ham_Item_Kill, ent)
		ExecuteHamB(Ham_Item_Deploy,weapon)
		return HAM_SUPERCEDE
	}
	return HAM_IGNORED
}

ExecuteHam

on napisał jak naprawić to co  nie dziala w generatorze (po cholere w ogóle ten generator?) a ty go obwiniasz o to że generator generuje wg ciebie slaby kod jakby to Drago go pisał

co jest w parametrze item?

jak by chcial zrobic menu graczy czy cos to ta praktyka jest odpowiednia (nie wiem co mial na mysli autor kodu ale piszesz tak jakby to zawsze byl blad)

(nie wiem co mial na mysli autor kodu ale piszesz tak jakby to zawsze byl blad)

Nie rób z siebie gwiazdy

nie obrazaj

Nie do tematu.. opisałem jak naprawić menu, nie jak "lepiej" dodać broń - nie ja pisałem vip'a generatora.

No i Benio miał rację. Nie sprawdzasz co dodajesz i wskazujesz ludziom błędy. Tak niech kopiują twoją opcję i narzekają , że nadal nie działa

  Vip.amxx

Chodziło tylko o menu , a ty robisz z igły widły aby robić niby tutki na naprawę całego generatora eh

Mogły by osoby mające dostęp do kodu generatora to sprawnie naprawić lub chociaż umieścić to na git'cie amxx'a / w dziale dla supporta, zajeli byśmy się nim i to odpowiednio

Co robimy pierwsze? No pewnie , że otwieramy naszego vip'a.sma w programie typu : amxx-studio

find_ent_by_owner

give_item(id, "weapon_m3")
new weapon_id=find_ent_by_owner(-1, "weapon_m3", id)
if(weapon_id)	cs_set_weapon_ammo(weapon_id, 8)

find_ent_by_owner

give_item

menu_additem

public menu_callback(id, menu, item){
	return ITEM_DISABLED;
}

public menu_callback(id, menu, item)	return ITEM_ENABLED

public menu_handler(id, menu, item){
	menu_destroy(menu);
	return PLUGIN_HANDLED;
}

public menu_handler(id, menu, item)
{
	if(item != MENU_EXIT)
	{
		new func[20]
		formatex(func,charsmax(func),"menu_%i_handler",item+1)
		callfunc_begin_i(get_func_id(func))
		callfunc_push_int(id)
		callfunc_end()
	}
	menu_destroy(menu)
}