10 odpowiedzi w tym temacie

[Lacostii]

Witam,

mam taki problem, bo chcę stworzyć jak najlepiej działający plugin oszczędzający zasoby maszyny.

Jak wiadomo lepiej wpierw dawać w warunkowych krokach te, które nie wykonują zapytań do silnika HLDS, dlatego utworzyłem takie zapytanie,

(ma_perk[id] = true/false jest określane w innych funkacjach, a ta tablica jest globalną)

if(ma_perk[id] && is_user_connected(id))
{

W takim utworzeniu warunków wszystko działa, ale otrzymuję error logi:

[AMXX] Run time error 4: index out of bounds 

Domyślam się, że id, które otrzymuje ma_perk[33] wykracza poza zdefiniowane czyli jest mniejsze od zera albo większe od 32, tym zawsze zajmowało się is_user_connected(id), ale z racji że ono pyta HLDS nie chce umieszaczać go na pierwszym miejscu. Więc czy dodanie warunku jeszcze jednego sprawdzającego czy id jest w normie załatwiło by sprawę i sprawiło, że plugin by działał oszczędnej dla maszyny? Wyglądałoby to tak:

if(0<id<33 && ma_perk[id] && is_user_connected(id))
{

Proszę o odpowiedź tylko osoby co mają pojęcie o tym.

[DarkGL]

a kiedy ustawiasz ma_perk i kiedy wywoływane są forwardy w których ustawiasz wartość ma_perk[ identyfikator ] ( domyślam się że to cod )

[GwynBleidD]

Może inaczej, gdzie podany przez Ciebie warunek siedzi? W jakiej funkcji/handlerze/evencie?

[Lacostii]

Przykładowy plugin,w którym zastosowałem taką kolejność warunków, a otrzymuję error logi.

Spoiler

#include <amxmodx>
#include <hamsandwich>
#include <codmod>

#define DMG_BULLET (1<<1)

new const perk_name[] = "Platynowe Naboje";
new const perk_desc[] = "Zadajesz 10(+0.1 INT) obrazen wiecej";

new bool:ma_perk[33];

public plugin_init(){
	register_plugin(perk_name, "1.0", "Delmus");
	
	cod_register_perk(perk_name, perk_desc);
	RegisterHam(Ham_TakeDamage, "player", "TakeDamage");
}

public cod_perk_enabled(id)
	ma_perk[id] = true;
	
public cod_perk_disabled(id)
	ma_perk[id] = false;

public TakeDamage(this, idinflictor, idattacker, Float:damage, damagebits)
{
	if(ma_perk[idattacker] && damagebits & DMG_BULLET && is_user_connected(idattacker))
		cod_inflict_damage(idattacker, this, 10.0, 0.1, idinflictor, damagebits);

	return HAM_IGNORED;
}

Również problem jest przy evencie:

register_event("Damage", "Damage", "b", "2!=0");	

I moje pytania brzmią czy ten dodatkowy warunek z przodu załatwi problem oraz czy jest w ogóle sens takiego kombinowania? Bo jak zauważyliście tworzę pluginy na COD'a gdzie będzie razem kilkadziesiąt perków i klas, dlatego takie detale się dla mnie liczą, a za cel postawiłem sobie jak najlepsze działanie takich dodatków.

[Jak się nazwać]

Możesz też sam utworzyć system sprawdzania czy gracz jest połączony, żywy itp za pomocą forwardów csa i registerham

[sebacs2]

Mówiąc inaczej, warunek czy gracz jest podłączony (is_user_connected) daj na sam początek funkcji TakeDamage

[Lacostii]

Możesz też sam utworzyć system sprawdzania czy gracz jest połączony, żywy itp za pomocą forwardów csa i registerham

Nie wiem czy dobrze zrozumiałem, masz na myśli osobny plugin co będzie już z góry odrzucał wszystkie sygnały dla wybranych eventów zanim one trafią do reszty pluginów, gdy gracz nie będzie podłączony/żywy? Jest to rozwiązanie, ale wtedy rodzi się u mnie kolejne pytanie:

 

Gdy mam X pluginów wywołujących funkcje od "Ham_TakeDamage" w tym samym momencie i każda funkcja zaczyna się od warunku is_user_connected(id) to czy to zapytanie zostanie wykonane X razy, czy może silnik zdaje sobie sprawę, że otrzyma X tych samych zapytań i załatwia to w jednej odpowiedzi?

 

 

Mówiąc inaczej, warunek czy gracz jest podłączony (is_user_connected) daj na sam początek funkcji TakeDamage

Nie mów mi proszę szablonowych zwrotów, w tym temacie chcę właśnie spróbować uniknąć tego zapytania na początku.

 

Coś nie możecie mi chyba przewidzieć co się stanie gdy dam taki kod, dlatego przetestuję go i dam odpowiedź:

if(0<id<33 && ma_perk[id] && is_user_connected(id))

Jednak oczekiwałbym odpowiedzi jeśli by nie było już error logów czy tak ułożone warunki byłyby lepsze niż standardowe:

(zaznaczam, że perków jest kilkadziesiąt, więc szansa, że "ma_perk[id] = true" nie jest duża.)

if(is_user_connected(id) && ma_perk[id])

?

 

Dziękuję za zainteresowanie tematem .

Użytkownik Lacostii edytował ten post 29.10.2013 23:18

[Lacostii]

Minął prawie cały dzień na zaludnionym serwerze i nie ma error logów. Mogę się cieszyć z wynalezienia lepszego ułożenia warunków pod kątem oszczędności zasobów serwera czy jednak i tak stary sposób jest lepszy, ktoś jest to w stanie ocenić?

[GwynBleidD]

if(0<id<33 && ma_perk[id] && is_user_connected(id))

 

Pomysł dobry, ale powinno to wyglądać tak:

if(0<id && id<33 && ma_perk[id] && is_user_connected(id))

 

w praktyce opłaca się sprawdzać tylko 2 warunek, mniej niż zero być nie może, a samo zero jeszcze się w tablicy mieści.

[GT Team]

Czemu zamiast tego:

if(0 < id <33)

lepiej jest, żeby było tak:

if(0 < id && id < 33 )

To chyba to samo? I kod jest dłuższy?

[GwynBleidD]

Sorki, nawyk z innych języków programowania, w których taki zapis był niepoprawny. Zwracam honor.