Skocz do zawartości

Witamy w Nieoficjalnym polskim support'cie AMX Mod X

Witamy w Nieoficjalnym polskim support'cie AMX Mod X, jak w większości społeczności internetowych musisz się zarejestrować aby móc odpowiadać lub zakładać nowe tematy, ale nie bój się to jest prosty proces w którym wymagamy minimalnych informacji.
  • Rozpoczynaj nowe tematy i odpowiedaj na inne
  • Zapisz się do tematów i for, aby otrzymywać automatyczne uaktualnienia
  • Dodawaj wydarzenia do kalendarza społecznościowego
  • Stwórz swój własny profil i zdobywaj nowych znajomych
  • Zdobywaj nowe doświadczenia

Dołączona grafika Dołączona grafika

Guest Message by DevFuse
 

Zdjęcie

Deploy crashuje serwer - niewidoczna broń


  • Nie możesz napisać tematu
  • Zaloguj się, aby dodać odpowiedź
20 odpowiedzi w tym temacie

#1 Rivit

    Godlike

  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 05.08.2014 19:29

Witam. Mam taki kod:

public Item_Deploy_Post(ent)
{
            new id = get_pdata_cbase(ent, m_pPlayer, 4);
            
            if(!is_user_alive(id)) return
    
            new wid = cs_get_weapon_id(ent)
            
            if(~(bronie) & 1<<wid)
            {
                  ExecuteHamB(Ham_RemovePlayerItem, id, ent);
                  
                  ent = get_pdata_cbase(id, m_pLastItem, 5);
                  
                  set_pdata_cbase(id, m_pActiveItem, ent, 5)
                  ExecuteHamB(Ham_Item_Deploy, ent)
            }
}

Ten kod zawiesza serwer. Nie ma żadnego logu ani nic. Crash i tyle. Dodam że dzieje się tak wtedy gry wyrzucam bronie. Np. mam m4, dgl, he, cc4, knife.

 

Wyrzucam w tej kolejności (klikam g, nie mieszam nic w slotach, tylko klawisz g) : m4, dgl i teraz jest problem. Po wyrzuceniu dgl nie mam broni. a jak sproboje zaatakowac to crash. W momencie gdy nie mam broni, moge zmienic na he, c4, knife i wtedy działa. Działa też wtedy gdy na początku rundy tak jakby "dotkne kazdej broni" (aktywuje wszystkie).

Myślę że to może być przez fałszywy glock/usp jaki się pojawia (klikam klawisz 2 (slot 2) i mam z listy do wyboru: glock, dgl. Gdy wybiorę glock to on znika (prawidłowo) i broń się ustawia na dgl.

Co na to poradzić?


  • +
  • -
  • 0

#2 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 06.08.2014 08:55

Jeśli nie ma nic w logach, ani żadnego FATAL ERROR w konsoli serwera (lub w qconsole.log) to prawdopodobnie trafiasz w pętlę nieskończoną...

 

for(new i; i < 6; i++)

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


  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#3 Puchate

    Wszechobecny

  • Użytkownik

Reputacja: 204
Profesjonalista

  • Postów:433
  • Lokalizacja:Polska
Offline

Napisano 06.08.2014 14:49

Prawdopodobnie wprowadzasz serwer w pętlę, gdyż z wywołujesz funkcję samą z siebie  

 

 

public Item_Deploy_Post(ent)
 

 

 

ExecuteHamB(Ham_Item_Deploy, ent)


Użytkownik Puchate edytował ten post 06.08.2014 14:50

  • +
  • -
  • 2

#4 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 06.08.2014 17:32


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

 

 

Czy deklarowana zmienna nie ma domyślnie wartości 0 ?

 

 

 

 

 

Prawdopodobnie wprowadzasz serwer w pętlę, gdyż z wywołujesz funkcję samą z siebie  

 

 

public Item_Deploy_Post(ent)
 

 

 

ExecuteHamB(Ham_Item_Deploy, ent)

 

 

Skoro gracz ma nóż to czemu nie przełączy ?


  • +
  • -
  • 0

#5 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 06.08.2014 18:42

Czy deklarowana zmienna nie ma domyślnie wartości 0 ?

Zmienne globalne tak, lokalne niekoniecznie. Polecam zerować na przyszłość.

Skoro gracz ma nóż to czemu nie przełączy ?

Może przełącza, ale nóż również graczowi odbiera i już nie ma na co przełączyć? Przyjrzyj się warunkom...

Proponuję łapać pre zamiast post i modyfikować wyciąganą broń graczowi, zamiast wykonywać event jeszcze raz, z innymi parametrami.
  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#6 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 06.08.2014 19:48

Nie. W momencie gdy pojawia sie pusta bron to po 2s nastepuje crash. Jezeli wczesniej przelacze na noz to dziala normalnie potem. Moze to przez wyciaganie poprzedniej broni? Moze trzeba od razu leciec po slotach.
  • +
  • -
  • 0

#7 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 07.08.2014 08:54

Mimo wszystko, zastosuj się do tego co pisaliśmy Ci wyżej... Poza tym nie widzę tutaj sprawdzenia, czy ent istnieje... Może się zdarzyć sytuacja, że:
ent = get_pdata_cbase(id, m_pLastItem, 5);
Zwróci invalid ent, mimo tego dalej kod będzie próbował graczowi broń zmienić, oczywiście na invalid...

if(pev_valid(ent) != 2)
Możesz wyjaśnić dlaczego sprawdzasz tutaj tylko wartość 2? Podobnie w pętli for... Jaki sens jest "mielić" tą pętlą, gdy pev_valid zwraca 0? Nie wiem co w przypadku broni oznacza ta dwójka w tym miejscu, ale chyba tu się właśnie zapętlasz... zabierzesz graczowi wszystkie bronie, których użyć nie może, a reszta broni należących do gracza zwraca jedynkę, albo gracz nie ma więcej broni... I co się stanie?

A to, że po 2 sekundach następuje crash - po prostu się stos przepełnia po ok 2 sekundach, nie nastąpi to od razu, a w zależności od wersji binarek serwer może przestać przez te 2 sekundy odpowiadać (zrobi się lag) albo będzie działał normalnie...

Unikaj wywoływania funkcji w niej samej (chyba, że popełniasz celowo rekurencję i wiesz w co się pakujesz...), a tym bardziej nie rób tego w ten sposób, tj poprzez ExecuteHamB...

Moja propozycja: jeśli aktualnie wyciągana broń graczowi nie może zostać przez niego użyta, usuwasz mu ją, usuwasz od razu wszystkie jego bronie, których użyć nie może (czyli lecisz pętlą po wszystkich) i zapisujesz sobie w tej samej pętli do osobnej zmiennej broń, którą użyć może. Gdy nie znajdziesz takiej broni, rób sobie co chcesz, gdy znajdziesz, modyfikujesz parametry Item_Deploy tak, aby wyciągnął tą właśnie broń. Robisz więc to w PRE, a nie w POST.
  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#8 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 07.08.2014 14:55

Dzięki Ci wielkie. Co do pev_valid nie wiem. Myslalem ze kazda bron musi przechowywac dane ale zmienie to.

O ile dobrze rozumiem twoj ''plan'' to mam zwracac SetHamParam w deploy pre?
Z reszta poradze sb.
  • +
  • -
  • 0

#9 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 07.08.2014 19:14

Tak, dokładnie taki plan....

I owszem, każda broń przechowuje jakieśtam parametry, ale niekoniecznie prywatne. Ta dwójka tutaj ma specyficzne dość zastosowania.
  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#10 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 08.08.2014 15:03

SetHamParamInt czy Entity?

Mam leciec po broniach za pomoca get_user_weapons? Czy to takze wyłapie fałszywe bronie?
  • +
  • -
  • 0

#11 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 459
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 08.08.2014 16:49

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

Oj to naprawdę jest chamskie. Czasem godzinę błędu szukałem a tu takie cuś...

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

Sprawda czy byt ma prywatne dane. Czasem (zazwyczaj) podczas usuwania bytu sam się nie usunie (znaczy nie od razu) ale prywatne dane od razu zostają kasowane.

Funkcja cała dobra. Działa nawet mi ale jest pewien szkopuł. NIGDY W ŻYCIU NIE WOLNO USUWAĆ AKTYWNEJ BRONI tzn. trzeba funkcję set_pdata_cbase z offsetem active item dać ponad usuwaniem broni. Taki szkopuł. Poza tym działać działa. Co do Set_Ham_Param_Entity to jest całkiem spoko sposób ale tylko w teorii bo w praktyce okazuje się że event Deploy na danej bronii tylko uaktywania na niej think i parę innych rzeczy a model jest podmieniany w funkcji pobocznej pomiędzy pre i post Deploy'a. Dlatego jeśli użyjesz funkcji Set_Ham_Param_Entity w pre Deploy to modelu nie broni nie będzie a jeśli użyjesz w post Deploy to będzie model ale tej co usunąłeś :( Poza tym to celowo jest tutaj użyte ExecuteHamB gdyż wykonuje się pętelka po niewłaściwych broniach by je łapać i usuwać. wogóle to ja się dziwię dlaczego jest tu użyty Deploy a nie Ham_AddPlayerItem. Jeśli chcesz Deploy'a to można tak:
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
}
Użycie ExecuteHam skutkowało by zabraniem tylko jednej broni w przypadku posiadania dwóch wadliwych w tym jednej aktywnej. Dlatego pętla jest wskazana i oczywiście można pobierać id broni z poprzedniego użycia thinka naszej bronii co skutkuje takim samym wynikiem jak lastitem ale nie buguje się w przypadku pierwszej zdobytej bronii
  • +
  • -
  • 1
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#12 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 08.08.2014 18:42

A powiedz mi BlackPerfum kilka rzeczy

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.
  • +
  • -
  • 2

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#13 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 08.08.2014 18:43

Czyli jak juz chce deploy to post?

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

Dlaczego w twym kodzie nie ma pętli po slotach?
  • +
  • -
  • 0

#14 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 459
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 08.08.2014 19:38

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ą...
  • +
  • -
  • 1
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#15 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 08.08.2014 19:45

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

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


//edit
sposób Gwyna jest wg mnie dobry. Łapać post, sprawdzać czy posiada dozwoloną broń. Jezeli nie to przeleciec po wszystkich broniach gracza i zabrac te ktore sa nieprawidlowe. Fakt ze bedzie 'mieliło' (spodobało mi się to słowo) pętlą po broniach gdy gracz będzie miał nieprawidłowe. Chociaż można łapać dodawanie broni graczowi i blokować jeżeli jest niedozwolone. To może być dobre.
  • +
  • -
  • 0

#16 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 459
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 08.08.2014 20:39

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

Nie, to idealnie
 

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
}
Jedynie z c4 bedzie trochę inaczej bo trzeba zmienić submodel oraz usunąć ikonkę

Użytkownik BlackPerfum edytował ten post 08.08.2014 20:39

  • +
  • -
  • 1
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#17 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 08.08.2014 21:54

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

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...
  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark


#18 Rivit

    Godlike

  • Autor tematu
  • Support Team

Reputacja: 1 319
Godlike

  • Postów:4 380
Offline

Napisano 09.08.2014 12:03

Myślę że Gwyn ma rację z tym ExecuteHam zamiast B.

Jednak zrobił mi się mętlik w głowie.
AddPlayerItem pre czy Deploy post czy Deploy pre.
Cholercia.

Które będzie najlepsze?
  • +
  • -
  • 0

#19 BlackPerfum

    Pseudo interakcja??

  • Power User

Reputacja: 459
Wszechobecny

  • Postów:575
  • Lokalizacja:...
Offline

Napisano 09.08.2014 18:03

1. Czym jest według Ciebie pisanie racjonalne?

Nie idiotyczne (ładnie mówiąc) tzn. pisanie kodu który w conajmniej 90% się rozumie.

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

W sposobie podanym przeze mnie (ten z użyciem ExecuteHamB + Ham_Item_Deploy) handler musi zostać wykonany 2x!!! Dlaczego? By poinformować inne pluginy o tym iż została wprowadzona zmiana w sliniku. Jesli użyjesz ExecuteHam tylko twój plugin będzie przechowywał prawidłowe informacje, a w innych pluginach będą tylko błedne. Mam na myśli to iż jeśli w dwóch pluginach łapiemy te zdarzenie to i w jednym zmieniamy jego główne własności to trzeba jakoś poinformować o tym także inne pluginy a nie sam silnik. Inaczej będą bardzo duże kłopoty z kompatybylnością


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

Też uważam iż pisanie wielu pluginów jest dobre ale nie ma rzeczy bez wad... Tzn. pokazałem przykładowa wadę pisania wielu pluginów (nie stwierdzam iż takie pisanie to wada tylko iż posiada wade (ale także zalety ale zbaczamy z tematu....))

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

Zgadzam się ale wtedy kod "losowania niewidzialności" i kod "odbierania broni" był by bardzo irracjonalny... Zdarzenie Ham_Item_Deploy wykonuje się podczas pokazania przedmiotu a nie podczas jego zmiany. Zmiane należy dodatkowo wykryć (np. poprzez porównanie zawartości offsetów active item i active client item). Wtedy nie było by żadnych problemów.

Spodobały mi się przykłady z życia wzięte, dlatego też ci jeden podam. Używamy funkcji ExecuteHam do pokazywania. Mamy na serwerze jakiś item co dodaje nam broń P90 i klase która ma moc niewidzialności ale tylko na broni P90. Łudem szczęścia na tej klase zdobyliśmy ten item. Następnie po jakimś czasie znudził się on nam to go wyrzucamy i jakimś dziwnym sposobem nadal mamy niewidzialność?? O co chodzi? Już mówie, a może lepiej to przedstawić:

• wyrzucamy item podczas zmiany broni na P90
• wykonuje się zdarzenie Ham_Item_Deploy w pluginie z klasą, co daje nam niewidzialność
• wykonuje się zdarzenie Ham_Item_Deploy w pluginie z itemem, odbiera nam broń P90 i pokazuje ją graczu

I teraz powinno jeszcze być poinformowanie innych pluginów o zmienie broni ale ktoś użył ExecuteHam i nic się nie stanie a my bedziemy biegać niewidzialni


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

Zgadzam się w 100% iz ten sposób jest nie wydajny (ale otrzymujemy prawidłowy efekt końcowy). Dlatego pisałem iż:

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

Jeśli pomomo tego ktoś będzie chciał użyć zdarzenia Ham_Item_Deploy do usuwania "nielegalnych" broni to jedynymi sposobami by wszostko prawidłowo zdziałało jest albo użycie rekurencji i zatrzymania dalszego wywoływania starej informacji albo funkcji Set_Ham_Param_Entity i podmiana modelu broni. Gdyż w innych przypadkach inne pluginy będę przetrzymywac błędne informacje.


Które będzie najlepsze?

Powtórzę się kolejny raz:

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

Z naciskiem na:

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

Chodzi mi o to by samemu broń odbierać w momęcie gdy staje się "nielegalna" a nie gdy pokazujemy ją
  • +
  • -
  • 1
Chcesz napisać do mnie na PW to:
Spoiler

Mój tok myślenia jest błędny? Wskaż mi błąd zmienie to!

Aktualnie bije limit 32 graczy (łącze serwery) ale nadal są lagi przy zbyt dużym przesyłu informacji Dołączona grafika
Gra się płynnie do 40~50 graczy potem łącze pada i zamiast biegać ludzie się teleportują Dołączona grafika

#20 GwynBleidD

    Godlike

  • Przyjaciel

Reputacja: 1 869
Godlike

  • Postów:3 066
  • Steam:steam
  • Lokalizacja:Przemyśl
Offline

Napisano 10.08.2014 08:53

jedynymi sposobami by wszostko prawidłowo zdziałało jest albo użycie rekurencji i zatrzymania dalszego wywoływania starej informacji albo funkcji Set_Ham_Param_Entity i podmiana modelu broni.

Ale właśnie Ci wytłumaczyłem, że to nie są jedyne sposoby... Możemy nie używać rekurencji do tego zadania, ale iteracji i po wyrzuceniu wszystkich broni w pętli i ustawieniu odpowiedniej graczowi, użyć ExecuteHamB, jednak przy użyciu B trzeba pamiętać, aby handler był opatrzony w warunek sprawdzający, czy broń aktualnie wyciągana jest OK i nie wykonywał nic więcej, a jeśli nie jest ok to upewnić się, że zostanie wyciąnięta ta, która jest OK. W ten sposób każdy plugin zostanie poinformowany (co prawda 2 razy, ale można zatrzymać całkowicie wywołanie 1 handlera, ale i tak lepsze to niż 10 razy przy rekurencji) i handler wykona tylko tyle kodu, ile jest naprawdę wymagane.

I jak dla mnie rekurencja w tym wydaniu NIE jest sposobem, bo jak już wyżej pisałem, wszystkie pluginy na serwerze będą mogły brać w niej udział... Jak dla mnie jest to tak nieoptymalne, jak sprawdzanie i wyrzucanie graczowi broni w thinku...
  • +
  • -
  • 1

NIE pomagam na PW. Nie trudź się, na zlecenia nie odpiszę... Od pomagania jest forum.
NIE zaglądam w tematy wysłane na PW. Jeśli są na forum to prędzej czy później je przeczytam. Jeśli mam co w nich odpisać, to odpiszę.
 
1988650.png?theme=dark





Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych