Zetsu541

Jak to na mape? Ustaw w server.cfg sv_gravity 500 i sproboj. A jak nie to mozna co spawn ustawic grawitacje.

https://forums.allie...highlight=block

Łap: http://www12.zippysh...79635/file.html

 

gunxpmod.sma

Następnie skompiluj plik w http://amxx.pl/kompilator/

Komenda na ponowne wyświetlenie menu:

http://amxx.pl/topic...d-komenda-anti/

Wszystkie dopisz.

śmigać powinno

@edit:

 

Miałeś w pluginie inne błędy, naprawiłem.

 

 bb_class.sma   3,75 KB  33 Ilość pobrań
  bb_class.amxx

zapomniałeś zarejestrować klasę w plugin_init a dokładnie

// Vip Zombie Attributes
new const zclass5_name[] = { "Vip Zombie" }
new const zclass5_info[] = { "Hp+Speed+Jump"}
new const zclass5_model[] = { "bb_zombievip }
new const zclass5_clawmodel[] = { "v_zombievip" }
const zclass5_health = 5000
const zclass5_speed = 260
const Float:zclass5_gravity = 0.5
const zclass5_adminflags = "ADMIN_LEVEL_H

tutaj

 

// Register all classes
bb_register_zombie_class(zclass1_name, zclass1_info, zclass1_model, zclass1_clawmodel, zclass1_health, zclass1_speed, zclass1_gravity)
bb_register_zombie_class(zclass2_name, zclass2_info, zclass2_model, zclass2_clawmodel, zclass2_health, zclass2_speed, zclass2_gravity)
bb_register_zombie_class(zclass3_name, zclass3_info, zclass3_model, zclass3_clawmodel, zclass3_health, zclass3_speed, zclass3_gravity)
g_zclass_tanker = bb_register_zombie_class(zclass4_name, zclass4_info, zclass4_model, zclass4_clawmodel, zclass4_health, zclass4_speed, zclass4_gravity)
}

Brakuje tego pliku w odpowiednim folderze, masz albo go w jakimś subfolderze, lub nie wypakowaleś go w dobre miejsce, jeżeli zaś wszystko jest na pewno dobrze to sprawdź w konsoli czy czasem nie krzyczy o konkretny plik, sam pamiętam raz z tego forum ściągając jakiś plugin plik txt był napisany dobrze (w sensie nazwy) a w .sma pluginu była literka pomylona i nie działało mi  

Plugin : BB ammo_packs
Autor : G[o]Q



Plugin dodaje nam ammo packi do gry,dostajemy je za zabojstwo oraz za DMG.
Dodatkowo mozemy tworzyc wlasne "itemy" do kupienia ktore dolaczamy jako osobne pluginy(wiecej info oraz przyklady w downloadzie)


BB_ammo_per_kill - ilosc ammo packow za zabicie
BB_ammo_per_dmg - ile dmg nalezy zadac zeby dostac 1 ammo packa
BB_save_ap - (1- zapis ammo packow wlaczony / 0 - wylaczony)


give_ap <nick> <ilosc> - Daje graczowi dana ilosc ammopacków


say /buy - otwiera sklep



Standardowa


załącznik


UPDATE

-Dodana komenda na dawanie ammo packow (give_ap "nick" "ilosc")
-Dodanie cvara BB_save_ap (1- zapis ammo packow wlaczony / 0 - wylaczony)
-Update przykladu (dodanie cvarow do ustawienia teamu i kosztu)

UPDATE nr2


-Poprawa jednego istotnego Buga (thx 4 R3X)


UPDATE nr3


-Naprawa spamu w logach
-Dynamiczne komendy(komendy na otwarcie menu mozemy ustawic w pliku bb-commands.ini w configs)
-Dynamiczne komendy nr2 wpisujac w konsoli/na say nazwe itemu mozemy go kupic

UPDATE nr4


-Poprawa obslugi komend
-Dodane 2 nowe natywy (podawanie liczby ap i ustawianie liczby ap)

Czym jest GIT?
Git to system kontroli wersji.

Czym jest system kontroli wersji
System kontroli wersji śledzi zmiany w naszych plikach. Oznacza to, że dzięki takiemu systemowi możemy się w każdej chwili cofnąć do dowolnej zapisanej wersji naszego pliku. Weźmy przykład, tworzymy bardzo rozbudowany plugin i w pewnym momencie widzimy, że w kodzie brakuje czegoś, co już napisaliśmy... Gdzieś zniknęło, wyparowało, ktoś to usunął, może my sami przez przypadek? Nie ważne, brakuje i to jest jedyny ważny fakt... W takiej sytuacji osoba nie używająca systemu kontroli wersji pisze ten kod od nowa. Osoba która korzysta z systemu kontroli wersji szuka ostatniej zapisanej wersji kodu, gdzie ten fragment jeszcze istnieje i po prostu przywraca ten fragment.

Ale czy to oznacza, że system kontroli wersji przydaje się przy dużych projektach?
Przy dużych, przy małych, przy każdych Nawet malutki plugin, który ustala tylko interp może być zarządzany w systemie kontroli wersji. Bo przecież sposób ustawiania interpu może się zmieniać i w pewnym momencie dojdziemy do wniosku, że poprzedni sposób był lepszy. I możemy spokojnie do niego wrócić

Czyli w systemie kontroli wersji możemy trzymać kod?
Tak, ale nie tylko kod. Możemy trzymać tam dowolne pliki, które się zmieniają. Na przykład referat do szkoły, pracę magisterską, pliki dźwiękowe nad którymi pracujemy, praktycznie wszystko.

Ma to jednak ograniczenie: systemy kontroli wersji najlepiej radzą sobie z plikami tekstowymi (czystym tekstem, tj plikiem z kodem źródłowym, plikiem HTML, plikiem TXT), z plikami binarnymi (którymi są na przykład pliki doc, docx, obrazki, dźwięki) już gorzej. Ale nie jest powiedziane, że całkowicie sobie nie radzą! Radzą, ale mamy mniej funkcji, dla przykładu brak możliwości porównania 2ch wersji plików lub automatycznego połączenia zmian z 2ch wersji. Musimy to wtedy zrobić ręcznie. Ale są odpowiednie wtyczki, które to ułatwiają, dla przykładu wtyczka do porównywania obrazków, która po prostu nam zaznacza kolorem na obrazie wszystkie zmiany.

A czy coś jeszcze potrafią te systemy kontroli wersji?
Ojj dużo więcej, niż tu opisałem Oczywiście zależy od samego narzędzia, którego używamy. Ale większość z nich potrafi oznaczać konkretne wersje plików własnymi tagami (dzięki temu szybko możemy znaleźć np wersję 1.4 naszego pluginu), możliwość tworzenia gałęzi, porównywania plików, automatycznego łączenia różnych wersji plików, wysyłania plików na serwer... Jest tego mnóstwo.

Gałęzi?
Tak Gałęzie. Prawie jak te na drzewie. Podam prosty przykład.

Tworzymy nową super fajną rzecz w naszym pluginie, ale zajmie to nam z 3 dni zanim będzie ona do użytku. W pewnym momencie, tak w połowie tworzenia, dociera do nas informacja, że w dotychczasowej wersji jest bardzo poważny błąd i trzeba go szybko naprawić. Jest to dużo ważniejsze od tej nowej rzeczy którą właśnie piszemy. No i co teraz? mamy kod rozgrzebany na 4 strony świata i albo musimy chwilowo wyrzucić wszystko co pozmienialiśmy, albo skończyć to, co tworzymy teraz...

I tu nas ratują gałęzie. Każde repozytorium posiada tzw gałąź główną, którą nazwiemy teraz masterem. I wystarczy, że przed zaczęciem pracy nad nową rzeczą utworzymy nową gałąź i na niej tą rzecz będziemy robić. Wybucha alarm, trzeba naprawić błąd, przechodzimy więc grzecznie na gałąź główną i tworzymy z niej następną gałąź, na której naprawimy ten błąd. Przez to, że jesteśmy teraz na gałęzi głównej, cała nasza robota bezpiecznie sobie czeka na osobnej gałęzi. A my po naprawieniu błędu i opublikowaniu wersji bez błędu wracamy do roboty nad naszą super mega hiper rzeczą.

Dla wzrokowców:

                         --•--•--•--                 | Fix błędu
                        /           \
--•--•--•--•--•--•--•--+-------------+--             | Gałąź główna
                        \
                         --•--•--•--•--•--•--•--•--• | Nowa super hiper rzecz

Kropki to po prostu różne zapisane wersje kodu. + to rozdzielenie czyli w tym miejscu tworzymy nową gałąź i jak widać gałąź z Fixem błędu łączymy do głównej, to samo zrobimy oczywiście później z naszą nową funkcjonalnością.

W niektórych systemach kontroli wersji, m.in w GITcie będzie to wyglądać tak:

--•--•--•--•--•--•--•--+--•--•--•--                  | Gałąź główna | Fix błędu
                        \
                         --•--•--•--•--•--•--•--•--• | Nowa super hiper rzecz

Dlaczego? Ano dlatego, że na głównej gałęzi nie nastąpiły żadne zmiany (brak jak widać kropek), więc została ona po prostu całkowicie połączona z fixem błędu i tworzą one teraz jedną całość, a nie jakieś takie dziwne rozgałęzienia i łączenia jak wyżej. Oczywiście jeśli choć jedna zmiana byłaby obecna na gałęzi głównej to wyglądałoby to tak, jak "rysunek" poprzedni

Ale czym jest repozytorium?
Tak, wcześniej użyłem tego słowa. Repozytorium jest po prostu zbiorem plików, często jest to po prostu folder na dysku. Ten zbiór jest zarządzany jako całość, czyli tworzymy w nim gałęzie, zapisujemy wersję wszystkich plików itp. Najwygodniej dla każdego projektu (czyli pluginu osobnego albo zbioru pluginów działających razem) utworzyć osobne repozytorium. Dzięki temu zarządzamy jednym projektem niezależnie od innych. Głupotą jet wrzucanie plików z jednego projektu do osobnych repozytoriów, bo później się okaże, że wersja ta z tego repozytorium nie jest kompatybilna z tamtą z tamtego. Więc pamiętajmy - 1 projekt = 1 repozytorium.

No dobrze, ale co z tym GITem?
Opisałem ogólnie czym są systemy kontroli wersji. GIT jest jednym z nich. Jednym z lepszych, a moim zdaniem najlepszym

Słyszeliście może o innych: Bazaar, SVN, Mercurial...

Tak, są inne i też są ciekawe. Osobiście jednak używam GITa bo jest najwygodniejszy i chyba potrafi najwięcej. SVNa od razu odradzam. Z tego korzystają wielkie korporacje założone w zeszłym tysiącleciu, bo wtedy był tylko SVN dostępny. Jest stary, obolały, nie rozwijany od długiego czasu i co najgorsze, scentralizowany. Bazaar i Mercurial są też ciekawe, ale jakoś nigdy mnie nie przekonały tak, jak GIT.

Co to znaczy, że SVN jest scentralizowany?
To oznacza, że wszystko jest trzymane na serwerze. Jeśli chcemy pobrać inną wersję pliku, łączymy się z serwerem i on nam ją podaje. Oczywiście wersja na której aktualnie pracujemy jest skopiowana na nasz dysk, ale tylko jedną wersję na raz mamy. Co jest wadą, bo nie mając dostępu do serwera nie możemy w pełni pracować nad projektem. Poza tym potrzebujemy takiego serwera, możemy go uruchomić na własnym komputerze, ale to jest niewygodne i bardzo źle się tak pracuje. A teraz pracujmy na innym komputerze, bo np siostra nam zabrała laptopa i musimy na stacjonarnym kompie siedzieć. I zonk, oba komputery muszą być włączone i muszą mieć połączenie ze sobą, żebyśmy mogli pracować, bo inaczej serwera nie ma. Same kłopoty...

Czy to oznacza, że inne systemy kontroli wersji nie mogą się łączyć z serwerem?
To, że nie muszą nie oznacza, że nie mogą Git jest zdecentralizowany, ale nadal posiada architekturę umożliwiającą połączenie się z innymi. Jednak nie jesteśmy w stanie tutaj wyróżnić klienta i serwera, przynajmniej nie na stałe. Oznacza to, że możemy się połączyć z każdym komputerem, który posiada to repozytorium i je pobrać albo coś do tego komputera wysłać. Oczywiście wygodnie jest sobie wyznaczyć który z nich będzie serwerem, ale konieczne to nie jest. No i zawsze posiadamy pełną kopię całego repozytorium u siebie na dysku. Oczywiście jeśli chcemy, bo nie zawsze potrzebujemy pobrać wszystkie gałęzie, możemy pobrać to, co nas interesuje i korzystać z tego nawet bez połączenia.

Są też już gotowe, darmowe serwery, a właściwie serwisy oferujące repozytoria na swoich serwerach. Na przykład GitHub. Kosztem jednak jest to, że takie repozytorium jest publiczne, tj każdy może sobie je pobrać i przeglądać kod. Istnieje jeszcze Bitbucket w którym możemy za darmo tworzyć prywatne repozytoria, jednak z limitem do 5 osób na repozytorium. Oczywiście oba serwisy posiadają oferty płatne, gdzie nie mamy żadnych limitów na repozytoria prywatne.

Osobiście polecam wszelkie publiczne projekty trzymać na GitHubie, jest najbardziej popularny i jeśli ktoś będzie szukał naszego projektu, tam właśnie zacznie

No to super, więc jak korzystać z GITa?

Nie jest to takie trudne. Właściwie można wytypować 3 drogi:

• Wykonywać odpowiednie polecenia w konsoli
  Tak, wiem że to nie jest rozwiązanie, które spodoba się wszystkim, ale naprawdę używanie konsoli do tego typu zadań jest bardzo przyjemne i do tego ona właśnie została stworzona. Dla nieprzekonanych o tym osób są następne 2 sposoby, więc się nie martwcie. Jednak należy uważać, bo poniższe 2 mogą posiadać ograniczenia (w zależności od użytych narzędzi oczywiście), a konsola takich mieć nie będzie
  
  Bardzo dobry e-book odnośnie nauki GITa znajdziecie tu, nie dość że po polsku to naprawdę świetnie napisany
• Użyć edytora z wbudowaną obsługą GITa
  To rozwiązanie dla wielu osób będzie z pewnością najwygodniejsze. Możemy zarządzać dzięki niemu repozytoriami bez opuszczania edytora. Istnieją odpowiednie dodatki dla prawie każdego dobrego edytora. Nie znalazłem jednak takiego jak na razie dla AMXX Studio, ale nawet dużo nie szukałem, bo go nie używam, więc może istnieje.
  
  Przykładowe edytory z wbudowaną obsługą GITa:
  Atom Jak na razie do pobrania tylko pod Mac OS, ale można go skompilować dla innych systemów. Wydany przez speców od GitHuba, więc z nim się integruje najlepiej
  Qt Creator jest właściwie stworzony do tworzenia w C++ z użyciem bibliotek Qt, ale bardzo fajnie się w nim też pisze w PAWNie jeśli doinstalujemy podświetlanie składni
  
  Plugin do Notepad++
• Użyć zewnętrznego narzędzia okienkowego
  Czyli tzw nakładki Jest ich trochę, a 2 popularne i bardzo fajne to TortoiseGIT (narzędzie dostępne w specjalnym menu w prawokliku na plikach i folderach, więc nie uruchamiamy osobnego programu, bo się ładnie integruje z eksploratorem windows) oraz specjalny program od GitHuba. Służy on praktycznie w całości do integracji z GitHubem, ale spokojnie można go używać do repozytoriów trzymanych tylko lokalnie albo nawet na innych serwerach. Istnieje również aplikacja wydana przez twórców bitbucket o nazwie SourceTree, obsługuje ona też Mercuriala i jest bardzo rozbudowana. Zrobimy z niej praktycznie wszystko, więc linia komend nie jest potrzebna.
  
  Apka GitHuba pod windowsa, Mac OS, a nawet pod Androida
  Tutaj macie SourceTree
  No i oczywiście TortoiseGIT

I co najważniejsze, wszystkiego z tej listy można używać zamiennie. Nie jest nigdy tak, że jeśli używacie 1 rzeczy tu już innych się nie da, bo każda z aplikacji działa tak naprawdę poprzez komendy linii poleceń, więc są w 100% kompatybilne ze sobą.

Super, a czy będzie jakiś tutorial o obsłudze GITa?
Takowego nie przewiduję, tutoriali na internetach do GITa od groma, wyżej podlinkowałem najlepszy wg mnie e-book, który jest dostępny w bardzo wielu językach w tym w Polskim. Aplikacje są bardzo intuicyjne i każdy się ich nauczy, no może oprócz SourceTree, który jest mocno rozbudowany, ale żeby jego w całości ogarnąć to trzeba być naprawdę wyjadaczem

#include 
#include 
#include 

new stuck[33];

new const Float:size[][3] = 
{
	{0.0, 0.0, 1.0}, {0.0, 0.0, -1.0}, {0.0, 1.0, 0.0}, {0.0, -1.0, 0.0}, {1.0, 0.0, 0.0}, {-1.0, 0.0, 0.0}, {-1.0, 1.0, 1.0}, {1.0, 1.0, 1.0}, {1.0, -1.0, 1.0}, {1.0, 1.0, -1.0}, {-1.0, -1.0, 1.0}, {1.0, -1.0, -1.0}, {-1.0, 1.0, -1.0}, {-1.0, -1.0, -1.0},
	{0.0, 0.0, 2.0}, {0.0, 0.0, -2.0}, {0.0, 2.0, 0.0}, {0.0, -2.0, 0.0}, {2.0, 0.0, 0.0}, {-2.0, 0.0, 0.0}, {-2.0, 2.0, 2.0}, {2.0, 2.0, 2.0}, {2.0, -2.0, 2.0}, {2.0, 2.0, -2.0}, {-2.0, -2.0, 2.0}, {2.0, -2.0, -2.0}, {-2.0, 2.0, -2.0}, {-2.0, -2.0, -2.0},
	{0.0, 0.0, 3.0}, {0.0, 0.0, -3.0}, {0.0, 3.0, 0.0}, {0.0, -3.0, 0.0}, {3.0, 0.0, 0.0}, {-3.0, 0.0, 0.0}, {-3.0, 3.0, 3.0}, {3.0, 3.0, 3.0}, {3.0, -3.0, 3.0}, {3.0, 3.0, -3.0}, {-3.0, -3.0, 3.0}, {3.0, -3.0, -3.0}, {-3.0, 3.0, -3.0}, {-3.0, -3.0, -3.0},
	{0.0, 0.0, 4.0}, {0.0, 0.0, -4.0}, {0.0, 4.0, 0.0}, {0.0, -4.0, 0.0}, {4.0, 0.0, 0.0}, {-4.0, 0.0, 0.0}, {-4.0, 4.0, 4.0}, {4.0, 4.0, 4.0}, {4.0, -4.0, 4.0}, {4.0, 4.0, -4.0}, {-4.0, -4.0, 4.0}, {4.0, -4.0, -4.0}, {-4.0, 4.0, -4.0}, {-4.0, -4.0, -4.0},
	{0.0, 0.0, 5.0}, {0.0, 0.0, -5.0}, {0.0, 5.0, 0.0}, {0.0, -5.0, 0.0}, {5.0, 0.0, 0.0}, {-5.0, 0.0, 0.0}, {-5.0, 5.0, 5.0}, {5.0, 5.0, 5.0}, {5.0, -5.0, 5.0}, {5.0, 5.0, -5.0}, {-5.0, -5.0, 5.0}, {5.0, -5.0, -5.0}, {-5.0, 5.0, -5.0}, {-5.0, -5.0, -5.0}
}

public plugin_init() {
	register_plugin("Unstuck","1.5","NL)Ramon(NL edited by Muzzi");
	register_clcmd("say /odblokuj", "cmdUnstuck");
	register_clcmd("say_team /odblokuj", "cmdUnstuck");
}
public cmdUnstuck(id)
{
	static Float:origin[3];
	static Float:mins[3], hull;
	static Float:vec[3];
	static o;
	if (is_user_connected(id) && is_user_alive(id))
	{
		pev(id, pev_origin, origin)
		hull = pev(id, pev_flags) & FL_DUCKING ? HULL_HEAD : HULL_HUMAN
		if (!is_hull_vacant(origin, hull,id) && !get_user_noclip(id) && !(pev(id,pev_solid) & SOLID_NOT)) {
			++stuck[id]
			pev(id, pev_mins, mins)
			vec[2] = origin[2]
			for (o=0; o < sizeof size; ++o) {
				vec[0] = origin[0] - mins[0] * size[o][0]
				vec[1] = origin[1] - mins[1] * size[o][1]
				vec[2] = origin[2] - mins[2] * size[o][2]
				if (is_hull_vacant(vec, hull,id)) {
					engfunc(EngFunc_SetOrigin, id, vec)
					effects(id)
					set_pev(id,pev_velocity,{0.0,0.0,0.0})
					o = sizeof size
				}	
			}
		}
		else
		{
			stuck[id] = 0
		}	
	}
}

stock bool:is_hull_vacant(const Float:origin[3], hull,id) 
{
	static tr
	engfunc(EngFunc_TraceHull, origin, origin, 0, hull, id, tr)
	
	if (!get_tr2(tr, TR_StartSolid) || !get_tr2(tr, TR_AllSolid)) //get_tr2(tr, TR_InOpen))
		return true
	
	return false
}

public effects(id) {
	set_hudmessage(255,150,50, -1.0, 0.65, 0, 6.0, 1.5,0.1,0.7) // HUDMESSAGE
	show_hudmessage(id,"[BaseBuilder] Zostales Odblokowany!") // HUDMESSAGE
	message_begin(MSG_ONE_UNRELIABLE,105,{0,0,0},id )      
	write_short(1<<10)   // fade lasts this long duration
	write_short(1<<10)   // fade lasts this long hold time
	write_short(1<<1)   // fade type (in / out)
	write_byte(20)            // fade red
	write_byte(255)    // fade green
	write_byte(255)        // fade blue
	write_byte(255)    // fade alpha
	message_end()
	client_cmd(id,"spk fvox/blip.wav")
}