16 odpowiedzi w tym temacie

[Robiin]

Na wstępie chciałbym prosić każdego czytelnika o dołożenie swojej wiedzy do tematu i podzielenie się doświadczeniem, żeby wspólnie udoskonalić generator.

 

Ode mnie takie info:

 

Usunąć makrodefinicję IsPlayer

Spoiler

Aktualny syntax definicji:

#define IsPlayer(%1) (1<=%1<=maxPlayers)

Is_user_connected:

static cell AMX_NATIVE_CALL is_user_connected(AMX *amx, cell *params) /* 1 param */
{
	int index = params[1];
	
	if (index < 1 || index > gpGlobals->maxClients)
		return 0;
	
	CPlayer* pPlayer = GET_PLAYER_POINTER_I(index);
	
	return (pPlayer->ingame ? 1 : 0);
} 

 

Zależnie od tego, czy chcemy iść z tym wszystkim pod kod easy-to-read czy wydajny:

Zamiana bool'a g_Vip na bity

Spoiler

new bool:g_Vip[33]

na

new g_Vip;

#define SetBit(%2,%1) (%1 |= (1 << (%2 & MAX_PLAYERS - 1)))
#define RemoveBit(%2,%1) (%1 &= ~(1 <<(%2 & MAX_PLAYERS - 1)))
#define GetBit(%2,%1) (%1 & (1 << (%2 & MAX_PLAYERS - 1)))
#define GetBool(%2,%1) (%1 & (1 << (%2 & MAX_PLAYERS - 1)) == (1 << (%2 & MAX_PLAYERS - 1))) 

gdzie

#define MAX_PLAYERS 32 

będzie łatwą do zmiany wartością. Przy okazji, z tego co wiem to 

maxPlayers=get_maxplayers(); 

nie działa dobrze (ale nie pamiętam od kogo to wiem i dlaczego, więc nie argumentuję się tym, po prostu mówię, że moim zdaniem nie wygląda to dobrze). Dodatkowo makrodefinicja MAX_PLAYERS pozwoli na określenie wielkości tablicy względem ilości graczy, dzięki czemu zaoszczędzimy na pamięci.

 

Zmiana syntaxu sprawdzania sumy bitowej flag gracza

Spoiler

if(get_user_flags(id) & 524288 == 524288){ 

na

if(get_user_flags(id) & ADMIN_LEVEL_H){ 

I tak, wiem, że sprawdzanie w ten sposób ma swój cel, jednakże ta zmiana nie wpłynie na działanie pluginu, a unikniemy tematów pt. "jak zmienić flagę vipa".

 

Zmiana momentu i częstotliwości przypisywania dostępu do vipa

Spoiler

W związku z tematami pt. "free vip nie działa", wychodzę temu na przeciw i rozwiewam wątpliwości osób, które mają z tym problem; plugin wam nie działa, bo vip z generatora ma przypisanie dostępu jednorazowo przy wejściu na serwer, co się kłóci z dodawaniem flagi np. od 1/2/3.. rundy.

Tym samym proponuję zmianę tego:

public client_authorized(id){
	if(get_user_flags(id) & 524288 == 524288){
		client_authorized_vip(id);
	}
}
public client_authorized_vip(id){
	g_Vip[id]=true;
} 

na to

public client_authorized(index)
	if(get_user_flags(index) & ADMIN_LEVEL_H)
		SetBit(index, g_Vip); 

jednocześnie unikając rozdzielania tego na dwie funkcje (które szczerze nie wiem dlaczego w ogóle się tam znalazły?).

 

Nie rozwiązuje to problemu darmowego vipa i kłócenia się ze sposobem przypisania dostępu, dlatego proponuję też sprawdzanie pętlą co rundę flag gracza. Piszę to osobno, aby zwrócić uwagę na możliwość dodania tego opcjonalnie. Nie każdy będzie chciał sprawdzanie flagi co rundę, dlatego myślę, że taka wersja będzie pasowała każdemu.

Gotowy kod z bitami;

public plugin_init()
	register_event("HLTV", "Nowa_Runda", "a", "1=0", "2=0");

public Nowa_Runda()
	for(new i = 1; i <= 32; i++)
		if(is_user_connected(i)	&& get_user_flags(i) & ADMIN_LEVEL_H && !GetBool(i, g_Vip)
			SetBit(i, g_Vip); 

 

Jednorazowe pobranie nicku gracza, żeby uniknąć powtarzania się tego przy liście vipów, say'u etc.

Spoiler

new userName[MAX_PLAYERS][33];


public client_authorized(index)
{
	if(is_user_hltv(index))
		return;

	get_user_name(index, userName[index], charsmax(userName[]));
} 

 

Zmiana syntaxu w sayHandle na łatwy do odczytania przy prefixie

Spoiler

Zmiana z tego

public handleSayText(msgId,msgDest,msgEnt){
	new id = get_msg_arg_int(1);
	
	if(is_user_connected(id) && g_Vip[id]){
		new szTmp[256],szTmp2[256];
		get_msg_arg_string(2,szTmp, charsmax(szTmp))
		
		new szPrefix[64] = "^x04[VIP]";
		
		if(!equal(szTmp,"#Cstrike_Chat_All")){
			add(szTmp2,charsmax(szTmp2),szPrefix);
			add(szTmp2,charsmax(szTmp2)," ");
			add(szTmp2,charsmax(szTmp2),szTmp);
		}
		else{
			add(szTmp2,charsmax(szTmp2),szPrefix);
			add(szTmp2,charsmax(szTmp2),"^x03 %s1^x01 :  %s2");
		}
		set_msg_arg_string(2,szTmp2);
	}
	return PLUGIN_CONTINUE;
} 

na to

public sayHandle(msgId, msgDest, msgEnt)
{
	new index = get_msg_arg_int(1);

	if(!is_user_connected(index) || !GetBool(index, g_Vip))
		return PLUGIN_CONTINUE;

	new chatString[2][192];

	get_msg_arg_string(2, chatString[0], charsmax(chatString[]));

	new chatPrefix[64] = "^x04VIP";

	if(equal(chatString[0], "#Cstrike_Chat_All"))
	{
		get_msg_arg_string(4, chatString[0], charsmax(chatString[]));
		set_msg_arg_string(4, "");

		formatex(chatString[1], charsmax(chatString[]), "%s^x03 %s^x01 :  %s", chatPrefix, userName[index], chatString[0]);
	}
	else
		formatex(chatString[1], charsmax(chatString[]), "%s^x01 %s", chatPrefix, chatString[0]);

	set_msg_arg_string(2, chatString[1]);

	return PLUGIN_CONTINUE;
}

 

Przy okazji tego wszystkiego można by zmienić syntax kodu overall; usunąć zbędne spacje, ogarnąć powtarzający się kod, nazwy zmiennych z np. "g_Vip" na "hasVip" (tak, wiem, że są różne syntaxy pisania kodu i różne firmy wymagają różnych sposobów jego pisania, ale tutaj możemy śmiało powiedzieć, że sami będziemy na tym korzystać. Moim zdaniem łatwiej się czyta "hasVip" niż "g_Vip", ale to już preferencje personalne, ja tylko daję propozycję ), usunąć zbędne przechodzenie do osobnych funkcji, usunąć brackety przy jednoliniowych funkcjach (tak, tutaj też wiem, że to ma swój cel i różni programiści [...]).

[Rivit]

W sumie pomysł dobry tyle że z tym nickiem trzeba jeszcze łapać infochanged bo nick można zmienić podczas gry.

[Robiin]

W sumie pomysł dobry tyle że z tym nickiem trzeba jeszcze łapać infochanged bo nick można zmienić podczas gry.

public plugin_init()
	register_forward(FM_ClientUserInfoChanged, "clientInfoChanged");

public clientInfoChanged(index)
	get_user_name(index, userName[index], charsmax(userName[]));

Tak tylko, żeby były od razu przykłady. O tym rzeczywiście zapomniałem

[Rivit]

Dodam jeszcze ze g_Vip bym zostawił. Nie zmieniał na bitowe smieszki.

 

Skoro byśmy mieli MAX_PLAYERS (co chyba w tym nowym amx modzie jest juz w którymś z nagłowkow) to nie widze sensu uzywac get_maxplayers() 

 

 

Btw, jakbyś dokopał się dlaczego get_maxplayers ma być złe to chętnie się dowiem

[Robiin]

Nie możesz użyć zmiennej, do której przypiszesz wartość zwracaną przez get_maxplayers do określenia wielkości tablicy przy jej deklaracji. Makrodefinicja już na to pozwala.

Tyle wiem sam, a o co konkretniej chodziło to nadal się nie dowiedziałem. Tak na chłopski rozum to może ma to coś do czynienia z ukrytym slotem? Dodatkowo trzeba bawić się w odejmowanie HLTV etc. Zwyczajnie w świecie wygodniej jest dla nas (jako skrypterów, nie osobie prowadzącej serwer) użycie makrodefinicji MAX_PLAYERS.

 

Wersja z bitami to tylko typowe pójście w stronę wydajności.

Użytkownik aSiorr edytował ten post 15.12.2018 16:49

[Rivit]

Nie możesz użyć zmiennej, do której przypiszesz wartość zwracaną przez get_maxplayers do określenia wielkości tablicy przy jej deklaracji.

 

No ja to wiem. Dlatego napisałem, żeby używać makra

 

 

Wersja z bitami to tylko typowe pójście w stronę wydajności.

 

Czy ja wiem czy taka wydajność. IMO gra nie warta świeczki.

 

 

 

Co do samego generatora to może wystarczy poprawić tylko czytelność. Popularność tego moda podupadła dosyć, nie wiem czy jest sens w ogóle to rozwijać. Ale nie mnie decydować

[_McHappy]

To nie jest kwestia tego, czego lepiej użyć. Wspomniany natyw i stała odgrywają zupełnie różne role.
get_maxplayers() zwraca liczbę graczy, którzy mogą być jednocześnie połączeni z serwerem (ilość slotów wybierana przez właściciela serwera / ograniczenia hostingu ze względu na wykupioną ofertę).
Makrodefinicja MAX_PLAYERS stanowi o maksymalnym limicie liczby graczy, jaką serwer jest w stanie obsłużyć (jest to stała, niezmienna wartość wynosząca 32 sloty).

[Robiin]

Dlatego mówiłem, że robimy to pod siebie. Ja, jako skrypter, nie właściciel serwera, wolę mieć to w makrodefinicji, bo łatwiej jest ją zmienić i zrekompilować plugin, a zyskujemy na pamięci. Tego samego nie zrobimy z get_maxplayers. Nie chodzi o maksymalną ilość graczy narzuconą przez silnik (32), tylko o aktualnie maksymalną wartość (ilość slotów serwera), która nie zmienia się raczej nigdy (chyba, że ktoś lubi sobie zmieniać sloty co 2 dni, to wtedy już co innego).

[_McHappy]

Właśnie w tym sęk, że MAX_PLAYERS jest narzucone z góry - nie da się tego zmienić, bo stała ta jest już
zawarta w źródłach amxxa. Ponowna deklaracja np. MAX_PLAYERS 14 będzie skutkowała błędem kompilacji.
Raczej mówimy tu o własnej stałej, która musi nazywać się inaczej oraz jest - tak jak wspomniałeś - tworzona na użytek pojedynczego pluginu.

Wracając do tematu - oczy mi krwawią jak widzę te surowe offsety pdata, albo tą powtarzalność kodu w uchwytach menu'sów (rozdawanie broni poprzez menu itp.).

Użytkownik _McHappy edytował ten post 16.12.2018 00:27

[Robiin]

Zbieżność nazw była przypadkowa, nie odnosiłem się do tej stałej z wersji 1.8.3. Tak po prostu zawsze nazywam tę makrodefinicję. Btw. o ile się orientuję to #define może być zmieniony podczas pracy programu, ale kompilator wyrzuci warning, że "warning 201: redefinition of constant/macro (symbol "MAX_PLAYERS")".

 

To prawda, menu też są jedną wielką katastrofą.

[G[o]Q]

Zamiana bool'a g_Vip na bity

 

To jest spoko ale zamiast macrodefinicji imho lepiej zrobić poprostu 4 funkcje które zrobią te same operacje bitowe na globalnej zmiennej i będą mogły sobie pobrać ilość slotów przy użyciu get_maxplayers -> zmiana w macro i kompilowanie jest słabe jak chcemy mieć jednego vipa na x serverów. Natomiast czy jest sens to robić? Nie - nie osiągnie się tym większego performacne a tylko skomplikuje się kod dla ludzi którzy nie koniecznie umieją programować

 

jednocześnie unikając rozdzielania tego na dwie funkcje (które szczerze nie wiem dlaczego w ogóle się tam znalazły?).

 

Akurat funkcji powinno być jak najwięcej bo to poprawia czytelność kodu oraz łatwiej się tak zamyka logikę zamiast pisać wszystko w jednej funkcji robimy n mniejszych atomowych które potem używamy

 

usunąć zbędne przechodzenie do osobnych funkcji, usunąć brackety przy jednoliniowych funkcjach

Niby post sensowny a na końcu taka głupota - brackety powinny być zawsze, w szczególności przy jednolinijkowcach

[Robiin]

Ludzie, którzy nie znają się na programowaniu i tak nie zaglądają do kodu. Ja osobiście dążę do maksymalnej możliwej wydajności zachowując przy tym umiarkowaną prostotę kodu, chociażby przez (zazwyczaj odgórne, poglądowe, ale jednak) obliczanie średniej długości tekstu przy określaniu wielkości tablicy, utrzymywanie się przy stałej MAX_PLAYERS (i tutaj znowu, zbieżność przypadkowa) i określaniu wielkości tablic posiłkując się wartością makrodefinicji. Możesz mnie nazywać pedantem, ale nie wmówisz mi, że MaciekXkozak2005PL będzie zaglądał w kod, żeby się upewnić, że jest on napisany w taki a nie inny sposób - dla osób średnio zaawansowanych nic się nie zmienia, bo nie muszą znać zasady działania kodu jeśli funkcja nazywa się Get/Set Bit i BoolBit, raczej wszystko jest intuicyjne (tym bardziej, że można je nazwać SetVip, GetVip etc.) .

 

Sam piszę praktycznie zawsze rozbijając kod na pojedyncze funkcje, zawierając w nich kod zgodny z ich nazwami. W przytoczonym cytacie chodziło o przechodzenie między funkcjami w ten sposób:

public client_authorized(id){
	if(get_user_flags(id) & 524288 == 524288){
		client_authorized_vip(id);
	}
}
public client_authorized_vip(id){
	g_Vip[id]=true;
}
public client_disconnect(id){
	if(g_Vip[id]){
		client_disconnect_vip(id);
	}
}
public client_disconnect_vip(id){
	g_Vip[id]=false;

Czy jest to naprawdę potrzebne, skoro nic innego w tych funkcjach nie jest używane?

 

 

Odwołując się od trzeciego cytatu; tutaj zaznaczyłem i wydawało mi się, że jest to dosyć jasne co próbuję przekazać? "usunąć brackety przy jednoliniowych funkcjach (tak, tutaj też wiem, że to ma swój cel i różni programiści [...])."

[G[o]Q]

Czy jest to naprawdę potrzebne, skoro nic innego w tych funkcjach nie jest używane?

Tak to sprawia że funkcje mają jedną odpowiedzialność są atomowe i reużywalne na różne sposoby

 

Ja osobiście dążę do maksymalnej możliwej wydajności zachowując przy tym umiarkowaną prostotę kodu,

Tylko te zmiany nie mają żadnego zauważalnego wpływu na wydajność a operacje bitowe są mniej czytelne niż zwykłe funkcje no i rozwiązanie ze zwykłą funkcją jest poprostu bardziej generyczne bo możesz tam uzyć get_max_players

 

To że to nie jest generator dla ludzi znających się na rzeczy nie znaczy że nie może być czytelny, nie oszukujmy się trudno jest zrobić vipa tak żeby był nieoptymalny i miał jakiś większy wpływ na to jak działa serwer

[_McHappy]

W skryptach typu generatory kodu, dla bardziej objętościowych projektów / plików podejście opisywane przez GoQu jest jak najbardziej na miejscu (delegowanie czynności elementarnych z punktu widzenia działania programu do pojedynczych funkcji, prostota skalowania generowanego kodu). Nie analizowałem budowy tego generatora, ale w przypadku budowania kodu pluginów amxx, wspomniane 'rozbijanie' na pojedyncze funkcje może być 'sztuką dla sztuki', jako że samo określenie 'plugin' przeświadcza o jego konkretnej, ukierunkowanej naturze funkcjonowania - dlatego też własnoręcznie zdefiniowany forward 'client_putinserver_vip()' w pluginie vip'a wygląda co najmniej nienaturalnie - być może będzie to kwestia zmiany nazewnictwa, ale warto zastanowić się, czy generowanie dodatkowych skoków ma sens w świetle opisywanego przykładu.

[K@MILOVVSKY]

A ja proponuję poprawić kompatybilność kompilatora z kodem. Przykład: client_disconnect na client_disconnected. Unikniemy wtedy takich tematów.

Dodatkowo można jakoś zmienić wygląd motd, przy zaznaczeniu opcji "Automatycznego generowania MOTD". Zmienić czcionkę, sposób zapisu HTML (bo ten jest trochę 'niemodny'), poprawić literówki (przykład "ba" na "na").

No i zaktualizować kod prefixów na taki, jaki podał _McHappy w jednym z tematów. 

Użytkownik K@MILOVVSKY edytował ten post 29.12.2018 10:50

[_McHappy]

Bardzo dobrym posunięciem (choć nieco kosztownym) byłaby implementacja opcji wyboru wersji amxx oraz użycia dodatkowych modułów taki jak reApi itp.
Rozwiązałoby to problem wymieniony wyżej przez kolegę.

[Rivit]

Usunąć makrodefinicję IsPlayer

 

Zmiana syntaxu sprawdzania sumy bitowej flag gracza

 

To chyba najprostsze do zrobienia rzeczy, a ludzi piszących o zmiane flagi jest dość sporo, bo sam czasem na PW dostaje jak zmienic flage bo  w kodzie nie ma ADMIN_LEVEL_*

 

 

Małymi kroczkami może trzeba zmieniać