Widzę mój serwer tak popularny, że ktoś musiał sobie nawet tak samo walutę nazwać

 

przestań już spamować, bo robisz się żałosny

To nawet nie bedzie dzialalo Wielkie Jol. Zarejestrowany jest event HLTV a brak jego funkcji w kodzie.

Zaawansowany BH. Możemy ustawić godziny, w których gracze będą mogli włączyć podwójną prędkość oraz podwójny skok.

/bh - otwiera menu BH

1. Plik superbh.amxx wrzucić do \addons\amxmodx\plugins

2. W pliku \addons\amxmodx\configs\plugins.ini dodaj na końcu superbh.amxx

3. Zresetować serwer lub zmienić mapę

 

Ja tu nie widzę potrzeby używania taska.

new Float:czas

public plugin_init() {
	register_plugin(PLUGIN, VERSION, AUTHOR)
	register_logevent("Poczatek_Rundy", 2, "1=Round_Start")
	// Add your code here...
}
public Poczatek_Rundy()
{
	czas=get_gametime()
}
public czy_minelo_30_sekund()
{
	if((get_gametime()-czas)>30) 
		return true
	return false
}

Cześć!

 

Dawno was nie odwiedzałem, aczkolwiek ostatnio postanowiłem do was zajrzeć. Zauważyłem, że forum ma dość dobry potencjał, aczkolwiek to co było kiedyś, przechodzi ludzie pojęcie. Myślę, że jestem tutaj obecnie online jednym z najstarszych użytkowników tego forum. Bywałem tu od początku istnienia AMXX - od kurka. Kiedyś pięknymi latami prowadziłem to forum, ale niestety po pewnym czasie musiałem zrezygnować z pełnionych mi funkcji, więc z honorem odszedłem.

 

Do czego nawiązuje ten temat? Dobre pytanie. Przydałaby się lepsza ekipa moderacyjna. Rozumiem obecną moderację, jak i szanuję ich pracę i czas, aczkolwiek wydaje mi się, że wszystko po prostu z czasem przechodzi. Moderator ma za zadanie otrzymanie porządku, wydaje mi się, że najaktywniejszym moderatorem jest: sebul, radim. Reszta? reszta po prostu spokojnie czuwa, śpi.

 

W administracji również szału nie ma. Nie wiem jak wy rozumiecie pojęcie administrator, aczkolwiek ja rozumiem w ten sposób: "administrator to osoba który panuje nad działaniem forum (serwerem). Pielęgnuje je tak, aby użytkownikom oglądało się znaczenie lepiej. Dba o społeczność i ich potrzeby. Szuka najnowocześniejszych rozwiązań"

 

Co do junior adminów, to na wielkie miano zasługuje cheq, sharkowy ostatnio troszkę odpuścił, ale wiadomo - każdy pomada tylko jak może. Być może po prostu ma jakiś większy zakres obowiązków w życiu prywatnym, ale nie do tego zmierzam - mało istotne, liczą się chęci i zaangażowanie.

 

Widzę na forum dziesiątki tematów, które już powinny być dawno zamknięte, odrzucone - ale tak rozumiem, nie da się ogarnąć wszystkiego na raz. To moje pytanie brzmi - dlaczego nie zatrudnicie kogoś, kto będzie pomagał w działaniu forum? Złożyłem propozycje DarkGL, ale jak najzwyczajniej ma gdzieś. 

 

Wszystko się zmienia, kiedyś były inne czasy - za którymi bardzo tęsknię i płacze. Gdzie oni wszyscy są? Wiziu, abes, pavulon, kurek, rex, szyfrant... wybaczcie, na sentymenty mnie złapało 

 

Nawiązując do sedna sprawy. Jestem chętny wziąć udział w prowadzeniu na forum porządku. Nie wiem czy administracja jest za tym, aczkolwiek przydałby się naprawdę zmiany, które wprowadzą do życia AMXX.

 

Dziękuję i pozdrawiam

Przy połączeniu gracza jest ona zawsze ustawiana na fałsz

Gdzie ? Nie widzę takiego kodu.

 

Ponadto jeśli wartość ma być tylko false/true to zmienną tworzymy typu bool, czyli:

new gravity[33]; 

powinno wyglądać tak:

new bool:gravity[33];

Jest to projekt którego założeniem było ułatwienie pracy i zarządzania configami oraz dodania funkcjonalności której wcześniej nie było w amxxie.

Wrzucając framework do projektu dostajemy do dyspozycji dwa nowe forwardy

http://darkgl.amxx.p...ania-configami/

• plugin_config
• plugin_config_loaded

oraz funkcje publiczną do wywołania

• CFWInitialize( configName[] )

plugin_config - wykonuje się przed plugin_precache więc jest to pierwsza funkcja uruchamiana w pluginie
w tym forwardzie rejestrujemy wszystkie cvary. Do funkcji register_cvar został dodany jeden nowy parametr description. Czyli opis cvara.
Przykład użycia

register_cvar( "test_cvar" , "1" ,.description = "Testowy cvar" );

Drugi forward plugin_config_loaded jest uruchamiany po załadowaniu wszystkich cvarów jest to funkcja wykonywana przedplugin_precache.

W tym forwardzie pobieramy sobie wszystkie dane z cvarów które są nam potrzebne.

Funkcje CFWInitialize( configName[] ) uruchamiamy w forwadzie plugin_config
np.

CFWInitialize( "testConfig" );

pierwszym parametrem jest nazwa configu do utworzenia.
Prywatne metody w frameworku to

• __CFWregister_cvar
• __CFWloadConfig
• __CFWsaveConfig

Należy je tylko wykonywać jeśli dokładnie wie co chce się zrobić
Wszelkie pluginy pojawia się w folderze

configs/plugin/nazwaConfiga.cfg

Przykładowy plugin

/* Script generated by Pawn Studio */

#include <amxmodx>
#include <amxmisc>

#include "config"

#define PLUGIN	"testConfig"
#define AUTHOR	"DarkGL"
#define VERSION	"1.0"

new cvarResult;

#pragma unused cvarResult

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

public plugin_precache(){
}

public plugin_cfg(){
}

public plugin_config(){
	CFWInitialize( "testConfig" );
	
	register_cvar( "test_cvar" , "1" ,.description = "Testowy cvar" );
}

public plugin_config_loaded(){
	cvarResult = get_cvar_num( "test_cvar" );
	
	log_amx( "config loaded cvarResult: %d" , cvarResult );
}

 config.inc   2,95 KB  105 Ilość pobrań

Opis

 

Dzięki temu pluginowi gracz ze stosowną flagą ma możliwość pokolorowania swoich klocków, aby utrudnić zadanie zombie

 

Aby pokolorować klocek, należy być jego właścicielem. Oznacza to, że nie można pokolorować klocka nieużywanego lub innego gracza. Aby móc kolorować, konieczne jest włączenie menu kolorowania, z którego to możemy wybrać interesujący nas kolor, a następnie namierzenie na klocek i PRZY OTWARTYM MENU naciśnięcie prawego klawisza myszki. Efekt jest troszeczkę "oczojebny", dlatego nie musi się spodobać każdemu, ale intensywność kolorów można zawsze zmienić

 

Screenshot

 

Instalacja

Standardowa

 

Komendy

/colormenu - wyświetla menu kolorowania klocków

 

 

Standardowo klocki może kolorować gracz z flagą ADMIN_LEVEL_H. Jeśli chcemy to zmienić, otwieramy nasze sma i edytujemy ta linijkę:

#define FLAGA ADMIN_LEVEL_H

Jest to rozbudowany system żyć na Deathrun'a.

Plugin ten posiada:

• Życia się zapisują, dzięki czemu nie stracimy ich po zmianie mapy
• Menu w którym można sprzedać, kupić życia
• Można ustawić automatyczne odradzanie po śmierci
• Można ustawić maksymalną ilość osób w kolejce aby nas odrodziło
• Można ustawić, aby menu pokazywało nam się automatycznie po śmierci
• Można podarować komuś życia
• Możliwość ustawienia ceny za sprzedaż i kupno życia
• Możliwość ustawiania ile razy można się odrodzić w ciągu rundy
• Administrator z flagą ADMIN_CFG może dawać każdemu życia, bez straty własnych

Resztę zobaczycie sami

new const g_LangCmd[][] = { // Otwiera menu systemu żyć
"say /respawn",
"say_team /respawn"
};

new const g_LivesCmd[][] = { // Pokazuje aktualną ilość żyć
"say /lives",
"say_team /lives"
};

new const g_GiveCmd[][] = { // Otwiera menu w którym można podarować komuś życia
"say /daj",
"say_team /daj"
};

Deathrun_lives_prefix "DeathRun" // Prefix
Deathrun_lives_players "3" // Ilość żywych graczy aby można było się odrodzić
Deathrun_lives_livecost "12000" // Kupienie jednego życia
Deathrun_lives_salelive "4000" // Sprzedaż jednego życia
Deathrun_lives_maxrespawn "2" // Ilość maksymalnych odrodzeń w ciągu rundy

/* SQL */
Deathrun_lives_hostname "" // Nazwa hosta
Deathrun_lives_username "" // Nazwa użytkownika bazy danych
Deathrun_lives_password "" // Hasło do bazy danych
Deathrun_lives_database "" // Baza danych

Plugin posiada dwa natywy, chyba nie muszę tłumaczyć do czego służą:

set_user_life(id, g_Value) // Index gracza, ilość żyć
get_user_life(id) // Index gracza

Aby plugin działał poprawnie potrzebujemy przerobioną wersję kolejki na deathrun'a oraz przerobiony silnik deathrun'a. W załączniku będą znajdować się przerobione pluginy.


Standradowa.


Jeżeli posiada flagę ADMIN_CFG:

say /daj || say_team /daj i wybiera opcję numer 2.

 DeathRunLifeSystem.sma   20,94 KB  245 Ilość pobrań
  DeathRunLifeSystem.amxx

 DeathrunManager.sma   20,53 KB  234 Ilość pobrań
  DeathrunManager.amxx

 Kolejka.sma   4,08 KB  226 Ilość pobrań
  Kolejka.amxx

Elegancko Darku. Szkoda, że era 1.6 trochę wymiera, ale cieszę się że to wypuściłeś

 

Może i wymiera ale jednak nadal sprawia mi frajdę pisanie pod niego   Moge przyznać że większa przyjemność sprawia mi samo pisanie czegoś niż myśl że ktoś tego używa

Problem z tablicami dynamicznymi.

 

Zła tabulacja.

Patrząc na to w ten sposób to większość z obecnej ekipy nie miała by swojej rangi

Warto dodać tu iż podczas łapaniu eventa Ham_CS_Player_ResetMaxSpeed funkcja get_user_weapon zwróci niepoprawny wynik tzn. nasza poprzednią broń a nie aktualnie na którą zmieniamy gdyż ten event wywołuje sie wcześniej niż CurWeapon dlatego warto pobrać id broni tak:

const m_pActiveItem = 373
const m_iId = 43
new weapon = get_pdata_int(get_pdata_cbase(id,m_pActiveItem,5),m_iId,4)

a nie tak:

new weapon = get_user_weapon(id)

gdyż czasami:

get_user_weapon(id) != get_pdata_int(get_pdata_cbase(id,m_pActiveItem,5),m_iId,4)

Tutaj mamy taki przypadek: http://amxx.pl/topic...z-nozem/?hl=+prędkość+%2Bnożu#entry644318

Przydało by się tez powiedzieć że jeśli chce się zmieniać prędkość gracza na większą/mniejszą tylko w na danej broni to optymlniej jest łapać Ham_Item_Deploy + freeze time end bo wykonuje się mniej razy niż Ham_CS_Player_ResetMaxSpeed ale tylko wtedy kiedy chcemy (no prawie bo "freeze time end" wykonuje się nie trafnie) gdyż Ham_CS_Player_ResetMaxSpeed wykonuje sie podczas tych eventów:
- Ham_Item_Deploy (na każdej broni)
- freeze time start
- freeze time end
i parę innych ale już nie pamiętam Dlatego po co nam łapanie wszystkich broni i freeze time start jeśli gracz podczas freeztimu ma stać w miejscu i tylko na paru wybranych broniach ma być szybszy? Dlatego lepiej czasem złapać te eventy osobno ;D

Przeglądając różne stronki, znalazłem nawet ciekawy i być może przydatny kod do cvarów.

enum ValueType {
	ValueType_Int = 0,
	ValueType_Bool,
	ValueType_Float,
	ValueType_Flag
};

enum ConVar {
	Handle:ConVarHandle,		// Handle of the convar.
	ValueType:ConVarType,	// Type of value. (int, bool, float)
	any:LastConVarValue,
	any:PrevConVarValue,		// Previous value.
	any:ConVarValue			// The value.
};

stock AddConVar(newCon[ConVar], ValueType:type, ConVarChanged:callback, Handle:conVarHandle) {
	newCon[ConVarHandle] = conVarHandle;
	newCon[ConVarType] = type;

	if(conVarHandle != INVALID_HANDLE) {
		SetConVarDefault(newCon);
		HookConVarChange(conVarHandle, callback);
	}
}

stock AddConVarNoHook(newCon[ConVar], ValueType:type, Handle:conVarHandle) {
	newCon[ConVarHandle] = conVarHandle;
	newCon[ConVarType] = type;

	if(conVarHandle != INVALID_HANDLE) {
		SetConVarDefault(newCon);
	}
}

stock SetConVarDefault(setCon[ConVar]) {
	decl String:defCon[32];
	GetConVarDefault(setCon[ConVarHandle], defCon, 32);
	switch(setCon[ConVarType]) {
		case ValueType_Int:		setCon[ConVarValue] = setCon[PrevConVarValue] = setCon[LastConVarValue] = StringToInt(defCon);
		case ValueType_Bool:		setCon[ConVarValue] = setCon[PrevConVarValue] = setCon[LastConVarValue] = bool:StringToInt(defCon);
		case ValueType_Float:	setCon[ConVarValue] = setCon[PrevConVarValue] = setCon[LastConVarValue] = StringToFloat(defCon);
		case ValueType_Flag:		setCon[ConVarValue] = setCon[PrevConVarValue] = setCon[LastConVarValue] = ReadFlagString(defCon);
	}
}

stock UpdateConVarValue(upCon[ConVar]) {
	upCon[PrevConVarValue] = upCon[ConVarValue];
	switch(upCon[ConVarType]) {
		case ValueType_Int:		upCon[ConVarValue] = GetConVarInt(upCon[ConVarHandle]);
		case ValueType_Bool:		upCon[ConVarValue] = GetConVarBool(upCon[ConVarHandle]);
		case ValueType_Float:	upCon[ConVarValue] = GetConVarFloat(upCon[ConVarHandle]);
		case ValueType_Flag: {
			decl String:flagCon[32];
			GetConVarString(upCon[ConVarHandle], flagCon, 32);
			upCon[ConVarValue] = ReadFlagString(flagCon);
		}
	}
}

stock SetConVarValue(setCon[ConVar], {_,bool,Float}:conVarValue, bool:replicate=false, bool:notify=false) {
	setCon[PrevConVarValue] = setCon[ConVarValue];
	switch(setCon[ConVarType]) {
		case ValueType_Int:		SetConVarInt(setCon[ConVarHandle], _:conVarValue, replicate, notify);
		case ValueType_Bool:		SetConVarBool(setCon[ConVarHandle], bool:conVarValue, replicate, notify);
		case ValueType_Float:	SetConVarFloat(setCon[ConVarHandle], Float:conVarValue, replicate, notify);
		case ValueType_Flag: {
			decl String:flagCon[32];
			FindFlagString(_:conVarValue, flagCon, 32);
			SetConVarString(setCon[ConVarHandle], flagCon, replicate, notify);
		}
	}
	setCon[ConVarValue] = conVarValue;
}

stock bool:IsConVarValueChanged(isCon[ConVar]) {
	return bool:(isCon[PrevConVarValue] != isCon[ConVarValue]);
}

stock CheckToggleConVarValue(cheCon[ConVar]) {
	if(cheCon[PrevConVarValue] && !cheCon[ConVarValue]) {
		return -1;
	}
	else if(!cheCon[PrevConVarValue] && cheCon[ConVarValue]) {
		return 1;
	}
	return 0;
}

Trzeba jeszcze dodać parę rzeczy

enum _:eCvary {		// ustawiamy według własnych potrzeb
	CvarPierwszy = 0,
	CvarDrugi,
	CvarTrzeci			// itd.
};

new g_ConVars[eCvary][ConVar];

public OnConfigsExecuted() {
	for(new i=0; i<eCvary; ++i) {
		UpdateConVarValue(g_ConVars[i]);
	}
}
public OnConVarChange(Handle:conVar, const String:oldValue[], const String:newValue[]) {
	for(new i=0; i<eCvary; ++i) {
		if(conVar == g_ConVars[i][ConVarHandle]) {
			UpdateConVarValue(g_ConVars[i]);
			break;
		}
	}
}

A dodawanie cvaru robi się tak

AddConVar(g_ConVars[CvarPierwszy], ValueType_Int, OnConVarChange, CreateConVar("sm_cvarpierwszy", "150"));
AddConVar(g_ConVars[CvarDrugi], ValueType_Bool, OnConVarChange, CreateConVar("sm_cvardrugi", "1"));
AddConVar(g_ConVars[CvarTrzeci], ValueType_Float, OnConVarChange, CreateConVar("sm_cvartrzeci", "15.0"));

Generalnie co nam to daje? W jednej zmiennej globalnej mamy dostęp do uchwytu, typu i wartości cvaru, czy to dobre rozwiązanie? Nie wiem, niech każdy sam zadecyduje.

Oczywiście wykorzystać to można tylko do cvarów, które są liczbami, chociaż jakby pokombinować, to i ciągi znaków dało by się dodać.