1. czy dostrzegasz w tym rozwiązaniu rekurencję?
Bardzo często mylę terminy dlatego nie uczę się ich (wogóle) ale tak dostrzegam (o ile masz na myśli wykonanie funkcji w samej sobie)
2. czy jest ona niezbędna?
Nie. Jestem za tym by jej nawet nie było
3. Czy potrafisz przewidzieć WSZYSTKIE warunki wyjścia z niej i dopilnować, aby zawsze nastąpiło wyjście z niej?
Potrafię przewidzieć WSZYSTKIE
RACJONALNE przypadki oraz mogę nawet powiedzieć więcej iż jeśli ktoś tego kodu uzyje
racjonalnie to problemów nie będzie miał
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...
A co jeśli zmienimy broń na taka która też ma zostać usunięta? Szybszy sposób wyjścia z sytuacji. Szansa na wywołanie się usuwania broni 2x z rzędu (biorąc pod uwagę iż to
cod mod oraz że pisze się racjonalnie) jest wręcz zerowa ale przydało by się i tak na wszelki wypadek sprawdzić czy na pewno (tak wiem znowu mówię o skrajnościach...)
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...
Takim sposobem za każdym razem gdy gracz zmieni broń na nie właściwą bedziemy robić pętlę po wszystkich jego broniach, praktycznie to jest wręcz błachostaka dla serwera ale jakoś ja wolę by wszystko o siebie dbało za siebie dlatego kod który podałem "zadbał by o to sam" (tak wiem jestem pedantem...) Co do nie używania ExecuteHam bez B to nie do końca się zgodze gdyż inny plugin już nie złapie poprawnej broni
zawsze ktoś powtarzał "kompatybliność ponad wszystko"
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.
I tu spotykamy mega wade pisania w wielu pluginach a nie w jednym... My nie wywołamy drugi raz Deploy'a a inny plugin złapie nie poprawną bron i bedzie bęc. Dlatego tak to zrobiłem nie inaczej.
Czyli jak juz chce deploy to post?
To zależy czy użyjesz "rekurencji" czy nie. Jeśli tak to nie ma znaczenia czy to będzie post czy pre. Jeśli nie to większe pole do działania da ci post.
Czy Ham_AddPlayerItem wywołuje się wtedy gdy gracz otrzymuje item?
Tak. Dlatego to jest najlepsze rozwiązanie. Złapiesz tym każdy item który został dodany (tylko nie taki który dodałeś za pomocą tego ewentu ale
ExecuteHam a nie
ExecuteHamB/offsetami czyli zawsze złapiesz).
Dlaczego w twym kodzie nie ma pętli po slotach?
Kod "sam o to zadba" by nie było takich błędów. Dlatego jej nie użyłem. (zaleta użycia "rekurencji" ;D)
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
Dodam iż można użyć
SetHamParamEntity ale! trzeba zadbać o model broni tzn. zrobić coś takiego:
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
}
Tylko nwm jak bedzie z animacją...