14 odpowiedzi w tym temacie

[IntelCom]

Jak poprawnie zablokować daną funkcję, gdy admin jest obecny na serwerze?

[MAGNET]

przelecieć pętlą po graczach?

[oeN.]

Albo nawet lepiej.

#include <amxmodx>
#include <amxmisc>

#define PLUGIN "New Plug-In"
#define VERSION "1.0"
#define AUTHOR "author"

new bool:admin_online;

public plugin_init() {
    register_plugin(PLUGIN, VERSION, AUTHOR)
}

public client_connect(id) {
    if(get_user_flags(id) & ADMIN_BAN && !admin_online)
        admin_online = true;
}

public client_disconnect(id) {
    if(get_user_flags(id) & ADMIN_BAN && admin_online)
        admin_online = false;
}

public Funkcja() {
    if(admin_online)
        return PLUGIN_CONTINUE;
        
    //Kod
    
    return PLUGIN_CONTINUE;
}

Użytkownik oeN. edytował ten post 12.04.2015 15:57

[MAGNET]

oeN.

a co jeśli na serwerze będzie 2 adminów i jeden wyjdzie?

[oeN.]

No fakt... Czyli bez pętli się nie obejdzie.

[MAGNET]

Niekoniecznie...

 

Można przy connect'ie jakąś zmienną inkrementować, a przy disconnect'ie dekrementować  i tyle

[Rivit]

Wersja z pętlą:

stock bool:isAdminOnServer()
{
   for(new id = 0; id <= get_maxplayers(); id++)
   {
      if(!is_user_connected(id)) continue;
      if(!(get_user_flags(id) & ADMIN_BAN)) continue;

      return true;
   }

   return false;
}

Powinno zadziałać, pisane z fona, mogą być błędy

[GwynBleidD]

Po 1. pamiętajcie moi drodzy, że w client_connect NIE WIEMY, czy gracz jest adminem czy nie. Nawet w client_authorized możemy się tego nie dowiedzieć! (np gdy na serwerze jest amxbans, a admini są wczytywani z bazy danych).

 

Po 2. pamiętajcie moi drodzy, że w client_disconnect również możemy się nie dowiedzieć czy gracz opuszczający serwer był adminem (jego flagi mogły zostać wyczyszczone wcześniej).

 

Po 3. pamiętajcie moi drodzy, że admin może stać się adminem właściwie w każdej chwili... Zmieni nick, ktoś wywoła przeładowanie adminów na serwerze, admin będzie miał na jakiś czas i akurat mu się skończy...

 

Dlatego wersja z pętlą wydaje się lepsza, ale nie jest najlepsza. Najlepszą i najbardziej optymalną wersję osiągniemy gdy przypilnujemy wszystkich okoliczności, tj: złapiemy dokładnie moment w którym ktoś adminem zostaje, złapiemy dokładnie moment w którym adminem przestaje być oraz w inny sposób w client_disconnect sprawdzimy czy to właśnie admin opuścił serwer (być może jakaś tablica typu boolean w której będziemy trzymać kto był adminem?).

[oeN.]

A czy client_infochanged tutaj sprawdzi czy graczowi zmieniły się flagi?

[grankee]

 Nie, ale złapiesz tym np okoliczność zmiany nicku co może wiązać się z przypisaniem flag admina.

Ja bym zostawił pętle, jest pewniejsza i o ile nie będziesz tego używał x razy na sekundę to nie powinno być problemu. Eventów związanych z przypisaniem uprawnień możesz wszystkich nie przewidzieć przez co będziesz miał dziurawy plugin.

Użytkownik grankee edytował ten post 13.04.2015 05:30

[Puchate]

Po 2. pamiętajcie moi drodzy, że w client_disconnect również możemy się nie dowiedzieć czy gracz opuszczający serwer był adminem (jego flagi mogły zostać wyczyszczone wcześniej).

Skąd taki pomysł?

[GwynBleidD]

Po 2. pamiętajcie moi drodzy, że w client_disconnect również możemy się nie dowiedzieć czy gracz opuszczający serwer był adminem (jego flagi mogły zostać wyczyszczone wcześniej).

Skąd taki pomysł?

Spotkałem się z tym w jakiejś starej wersji amxbans, modowanej przez kogośtam... Z jakiegoś powodu w client_disconnect czyścił on flagi, a że amxbans jest zwykle na szczycie pluginów to inne pluginy w client_disconnect miały już puste flagi.

Eventów związanych z przypisaniem uprawnień możesz wszystkich nie przewidzieć przez co będziesz miał dziurawy plugin.

Można pokombinować z wykrywaniem użycia set_user_flags w jakiś sposób...

[Puchate]

Można by w sumie zrobić to tak, aby było dość wydajne

/* Plugin generated by AMXX-Studio */

#include <amxmodx>
#include <amxmisc>

#define PLUGIN "Admin online"
#define VERSION "0.1"
#define AUTHOR "Sn!ff3r"

#define FLAG ADMIN_BAN

new bool:adminOnline = false
new maxPlayers

public plugin_init() {
	register_plugin(PLUGIN, VERSION, AUTHOR)
	
	maxPlayers = get_maxplayers()
}

public admin_check(id) 
{
	if(!(get_user_flags(id) & FLAG)) // no update needed
	{
		return
	}	
	
	adminOnline = false
	for(new player = 1; player <= maxPlayers; id++)
	{	
		if(is_user_connected(player) && (get_user_flags(player) & FLAG))
		{
			adminOnline = true
			break			
		}			
	}	
}

public client_infochanged(id)
{
	if(!is_user_connected(id))
	{
		return PLUGIN_CONTINUE
	}
	
	new newname[32], oldname[32]
	
	get_user_name(id, oldname, 31)
	get_user_info(id, "name", newname, 31)
	
	if(!equali(newname, oldname))
	{
		admin_check(id) 
	}
	return PLUGIN_CONTINUE
}

public client_disconnect(id)
{
	admin_check(id) 
}

public client_authorized(id)
{
	admin_check(id) 
}

Użytkownik Puchate edytował ten post 13.04.2015 22:43

[Sooldierr]

A z tym przeładowaniem adminów to musiało by wykryć komendę na serwerze amx_reloadadmins? I wtedy pętlą po graczach w celu sprawdzenia/aktualizacji licznika adminów?

 

BTW:

for(new player = 1; player <= maxPlayers; id++)
	{	
		if(is_user_connected(player) && (get_user_flags(player) & FLAG))
		{
			adminOnline = true
			break			
		}			
	}	

pętla w nieskończoność, niepoprawna inkrementacja.

Nie id++, a player++

Użytkownik Sooldierr edytował ten post 22.04.2015 19:31

[Puchate]

 

pętla w nieskończoność, niepoprawna inkrementacja.

 

Fakt, mała pomyłka przy zmianie nazw zmiennych

A z tym przeładowaniem adminów to musiało by wykryć komendę na serwerze amx_reloadadmins? I wtedy pętlą po graczach w celu sprawdzenia/aktualizacji licznika adminów?

Jeżeli chce mieć braną pod uwagę obsługę tego to tak, trzeba dodać obsługę tej komendy co można bez problemu zrobić bez ingerencji w plik admin.sma