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

is_user_alive czy connected
#1
Napisano 30.11.2012 13:45
Czy ktoś mógłbym wytłumaczyć mi pewne rzeczy związane z is_user_alive i is_user_connected? Pytania mam takie:
1. Jaka jest różnica w używaniu tego.
2. Czy można oby dwa warunki, wpłynie to jakoś na niestabilność serwera?
3. Jeśli, np. mamy przydzielić czapki komuś i dam warunek is_user_alive, czasem jest też tak, że komuś się zawiesi CS albo będzie w jakichś rogach się pojawiał gracz nieaktywny. Znany nam błąd, to właśnie czy sam is_user_alive wystarczy? Po prostu tego nie mogę zrozumieć czy pojąć.
#2
Napisano 30.11.2012 14:24
is_user_alive - czy gracz jest żywy
2. zależy co do czego używasz, ale nie powinno
3. lepiej użyć obu warunków
IP: 31.186.83.208:27043

#3
Napisano 30.11.2012 15:01
Użytkownik radim edytował ten post 30.11.2012 15:02
Chcąc napisać do mnie prywatną wiadomość, wpierw zapoznaj się ze stroną "O mnie" w moim profilu użytkownika [ radim ] !
#4
Napisano 30.11.2012 16:16
is_user_connected - czy gracz jest połączony
is_user_alive - czy gracz jest żywy
Czy ja prosiłem o wytłumaczenie mi po co to jest? Po prostu pytam, bo jeśli jest przykładowo gracz tzn. jego tak naprawdę nie ma na serwerze, ale jego model pojawia się w rogach mapy i różnych jego punktach. To jest bug czasem taki. Co w takiej sytuacji? Bo ja tego pojąć zbytnio nie mogę. Czy nie wywali mi błędu, bo użyje connected zamiast alive.
Druga też jest sytuacja, gdy przeniesiemy żywą osobę z CT do TT lub na specta i potem do teamu. Potem hud się jakby odwraca i właśnie może wystąpić ten problem, że gracz jest na serwerze, ale ma tego buga, bo go po rogach spawnuje. Nawet jak się go zabije, to i tak model jest, tylko właśnie nie da się zabić i jakby hologram.
Użytkownik Krytykiewicz edytował ten post 30.11.2012 16:20
#5
Napisano 30.11.2012 16:34
DarkGL to mój autorytet.
skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować skomplikować
#6
Gość_21977_*
Napisano 30.11.2012 16:36

is_user_alive

Musisz pomyśleć, jaki warunek jest potrzebny dla danej operacji.
Nieraz potrzeba sprawdzić, czy gracz jest żywy (nie dodasz np. broni martwemu graczowi)
a nieraz wystarczy warunek, czy gracz jest połączony z serwerem (nie wyślesz do gracza
wiadomości na sayu, jeśli nie ma go na serwerze, ale z drugiej strony, nie musi on żyć).
#7
Napisano 30.11.2012 16:52
Poza tym pytaniem mam jeszcze jedno "z innej parafii". Jaka jest różnica między for(new i = 0) a for(new i = 1)? Chyba był kiedyś taki temat i nie chcę skłamać, ale sebul zakładał. Niestety nie mogę tego znaleźć.
Użytkownik Krytykiewicz edytował ten post 30.11.2012 16:53
#8
Napisano 30.11.2012 17:02

If you can dream it, you can do it.
#9
Napisano 30.11.2012 17:10
0 - losowy gracz na serwerze
1 - konkretny gracz?
Użytkownik Krytykiewicz edytował ten post 30.11.2012 17:11
#10
Gość_21977_*
Napisano 30.11.2012 17:12
drugi to warunek logiczny i tak długo, jak warunek jest spełniony, kolejne wywołania pętli będą
wywoływane, trzeci argument to instrukcja wywoływana każdorazowo po przebiegu pętli for.
Przeanalizujmy przykład dla kodu
for(new i=0; i<2; ++i){Na samym początku zostanie utworzona zmienna lokalna i i przyjmie ona wartość 0, jest to operacja jednorazowa.
client_print(0, print_console, i);
}
Następnie wykonany zostanie test logiczny (czy i<2), czyli drugi parametr funkcji. Ponieważ nasze i jest obecnie równe 0, a 0<2,
to zostanie wykonane pierwsze wywołanie pętli, czyli kod spomiędzy klamer dla i=0, tym samym w konwoli pojawi się zero.
Po wykonaniu tej zawartości, zostanie wywołana operacja zapisana w trzecim parametrze funkcji, czyli preinkrementacja.
Teraz, dla i=1, przeprowadzony zostanie ponownie test logiczny, 1<2, więc zostanie ponownie wywołane ciało pętli,
tym razem dla i=1. Po wypisaniu jedynki, znów nastąpi inkrementacja i i przyjmie wartość 2. Jednakże teraz, test logiczny,
tj. 2<2, nie zostanie spełniony, więc ciało funkcji ani instrukcje z trzeciego parametru nie zostaną wykonane.
Tym samym w konsoli pojawią się (w ciągu całego działania pętli) następujące wpisy:
0 1Po pierwszym niespełnionym warunku, dalsze instrukcje nie będą wykonywane i działanie pętli zostanie zakończone.
Warto tutaj zauważyć, że pętla może nie przyjąć ani jednego obiegu, jeśli pierwszy warunek nie zostanie spełniony,
a w przypadku nieprzemyślenia, pętla może wykonywać się nieskończenie długo, przez co najczęściej zawiesi się serwer.
Należy unikać takich sytuacji, odpowiednio przemyślawszy użycie pętli i należy mieć 100% pewność, że pętla zakończy swoje działanie.
Pierwszy argument równy
new i=0różni się od
new i=1jedynie wartością początkową zmiennej i.
#11
Napisano 30.11.2012 18:16
Bardzo dużo racji, że trzeba się nad tym zastanowić jaki się efekt chce uzyskać.
A jeśli chcę, aby dostał czapkę? Is_user_alive powinienem (tak sądzę). Dobra, ale zdarzy się sytuacja, w której to gracz nie jest podłączony i właśnie będzie ten bug, że "graczem" dokładnie jego model będzie pojawiać się w rogach mapy. No to chyba zostanie mu nadana ta czapka, skoro nie ma warunku, czy jest on podłączony. No chyba, że przyjmiemy wersję !is_user_bot(id). Właśnie o takie coś mi chodzi. Dzięki Ci wielkie benio101.
Czekam jeszcze na odpowiedź dotyczącą tego.
Użytkownik Krytykiewicz edytował ten post 30.11.2012 18:18
#12
Gość_21977_*
Napisano 30.11.2012 18:21
Nie za bardzo wiem, komu i kiedy chcesz przyznawać czapkę, ale jeśli chcesz ją przyznawać każdemu, to dawaj ją w momencie spawnu gracza, przy sprawdzeniu warunku is_user_alive

Użytkownik benio101 edytował ten post 30.11.2012 18:21
lit.
#13
Napisano 30.11.2012 20:10
for(new i = 1; i<=32; i++)
{
bool:uzyl[i] = false
if(speed[i])
{
speed[i]= false
set_user_maxspeed(i, 260.0)
}
xxx[i] = 0
}
to zmienna lokalna prawidłowa będzie i = 1? Co by się stało z takim kodem, jeśli dałbym 0 a jak 1. Jeśli zmienna lokalna przyjmie wartość 0, to rozumiem, że zawartość w pętli zostanie wykonana 1 raz, a jak dam 1 to będzie 1<=32 2<=32 czyli ciągnąc się pętla będzie i sprawdzać każdego, czy ja dobrze to wszystko zrozumiałem do tej pory?
Właśnie, co do tego kodu. Może zamiast tego powyższego optymalnie lub lepiej będzie po prostu:
for(new i = 1; i<=32; i++)
{
bool:uzyl[i] = false
speed[i]= false
set_user_maxspeed(i, 260.0)
xxx[i] = 0
}
Co do czapek. Przyznawane są za pomocą kanapki na spawnie. Każdy gracz dostaje w zależności od teamu. Użyłem is_user_alive, bo da tylko żywym. Natomiast jeśli gracz będzie na spekcie, ja go (nie zawsze tak jest) przerzucę do teamu, to on dostanie "buga", że będzie się pojawiał nagle nieruchomo w różnych częściach mapy, zazwyczaj w rogu. Więc zostanie mu przydzielona czapka, bo on będzie żył. Po zabiciu jego, nadal model jego "ciała będzie, ale nie można już zabić. Pewnie niejeden raz widzieliście takiego właśnie buga. No i związku z tym zapytałem. Co się stanie, jeśli graczowi zawiesi się CS i będzie musiał zakończyć proces CS'a? Właściwie, to raczej jego "model" znika, ale tak czasem nie jest. Zostaje i tutaj rodzi się pytanie. Jest ten moment spawnu i jego "model" nadal mówiąc kolokwialnie lata po kątach na mapie to tutaj is_user_alive wykryje go jako nieżyjącego czy żyjącego? Jeśli żyjącego, to użycie is_user_alive nie będzie skuteczne i nada mu czapkę mimo, że gracza nie ma i pojawia się tylko jego. Czy ktoś ma pojęcie o tym? Właśnie chodzi mi o to, czy gracz zostanie wykryty jako żyjący. Bo jeśli tak, to trzeba by było użyć connected.
#14
Gość_21977_*
Napisano 30.11.2012 20:23
Możesz dokonać koninkcji warunki życia oraz
if(get_user_team(id)%3)co zapobiegnie dania czapki graczom ze specta.
O błędzie, o którym piszesz, nie mam pojęcia, jednak zawsze wydawało mi się, że jest to jedynie model-widmo, pozbawiony istoty bytu, lecz pewien nie jestem.
#15
Napisano 30.11.2012 20:34
Co do tego błędu. Tak, to jest czasem model-widmo, który właśnie pojawia się w rogach mapy. Czasem ten "model widmo" to gracz żyjący, bo dostał buga, a czasem jego model-widmo się przemieszcza. Właśnie o to chodzi. Więc pytam czy ten model-widmo może spowodować niestabilności na serwerze, jeśli dajemy te czapki graczom żyjącym.
@@ Dodatkowo, masz porady jak wykonywać optymalny kod? Jeśli możesz to zobacz te dwa, które podałem wyżej i jeśli można prosić o diagnozę ich. Wiem wiem, zamęczę Cię i innych, jednak to jest bardzo ważne dla mnie. Nurtują mnie takie pytania i tyle.
@@@ Mam też pytanie osobiste. Czy poza forum też mógłbyś pomóc? Chodzi o sprawdzenie kilku pluginów pod względem zastosowania i optymalności kodu.
Użytkownik Krytykiewicz edytował ten post 30.11.2012 20:40
#16
Gość_21977_*
Napisano 30.11.2012 21:22
Kod wyżej będzie poprawny, kod niżej nie będzie optymalny, gdyż każdorazowo, nawet, gdy nie ma takiej potrzeby, dokonuje zapytanie do Metamoda:P oraz silnika gry, co należy wykonywać możliwie rzadko.
Kod wyżej wydaje się być dobry, o ile 32 to maksymalna liczba graczy na serwerze, w przeciwnym wypadku należy dokonać po uruchomieniu serwera pobrania maksymalnej liczby graczy za pomocą funkcji get_maxplayers

Odnośnie "modeli duchów" już się wypowiedziałem, niestety, nie jestem pewien, jednak przypuszczam, że nie są to byty, choć można to łatwo sprawdzić.
Użytkownik benio101 edytował ten post 30.11.2012 23:51
lit.
#17
Napisano 01.12.2012 12:47
Tu się z tobą nie zgodzę akurat, ja uważam że wydrukuje tylko jedynkę, dlaczego? Ponieważ jest ++i a nie i++ czyli przed wykonaniem pętli doliczy 1 do i. Mogę się mylić ale z moich obserwacji tak wynika. TznTym samym w konsoli pojawią się (w ciągu całego działania pętli) następujące wpisy:
0
1
for(new i=1;i<33;i++)to to samo co
for(new i=0;i<33;++i)
Tzn nie to samo ale zadziała identycznie. Jak się mylę nie bić

#18
Napisano 01.12.2012 13:59
To nie to samo. Sam kiedyś mniej więcej podobnie gdzieś napisałem, bo pomieszały mi się pluginy z takimi pętlami, jeden obsługiwał graczy po zwykłej pętli, a drugi najpierw pobierał id graczy do tablicy (get_playersTu się z tobą nie zgodzę akurat, ja uważam że wydrukuje tylko jedynkę, dlaczego? Ponieważ jest ++i a nie i++ czyli przed wykonaniem pętli doliczy 1 do i. Mogę się mylić ale z moich obserwacji tak wynika. TznTym samym w konsoli pojawią się (w ciągu całego działania pętli) następujące wpisy:
0
1for(new i=1;i<33;i++)to to samo cofor(new i=0;i<33;++i)
Tzn nie to samo ale zadziała identycznie. Jak się mylę nie bić

Tak na koniec, to w przypadku takiej pętli jak w tym temacie, ++i działa (prawie) tak samo jak i++, różnica polega tylko na tym, że w przypadku i++ potrzeba trochę więcej pamięci, czyli lepiej jest używać ++i, przynajmniej ja tak już od dłuższego czasu piszę pętle.
Posiadam TBM (inaczej PTB), które działa dużo lepiej niż zwykłe PTB, nawet na modach z lvlami. Zainteresowany? Proszę bardzo
Użytkownicy przeglądający ten temat: 1
0 użytkowników, 1 gości, 0 anonimowych