R3X

Weaponbox to broń, która leży na ziemi od razu na poczatku rundy. W odróżnieniu od tej wyrzuconej przez gracza może zawierać więcej niż jeden egzemplarz, to taki worek z wyposażeniem. Ta funkcja pobiera pierwsze id broni jakie znajdzie w weaponboxie.

To działa tak jak przekazanie parametru przez wskaźnik w cpp. Funkcja addSomeNoise nie otrzyma kopii tekstu "Hello John", ale dokładnie ten sam adres pamięci w którym przechowywany jest ten tekst w funkcji plugin_init(). Obie funkcje operują więc na dokładnie tym samym stringu.

public plugin_init() {
    new szMyAwesomeText[256];
    formatex(szMyAwesomeText, charsmax(szMyAwesomeText), "Hello %s", "John");
    log_amx("%s", szMyAwesomeText); //Hello John
 
    addSomeNoise(szMyAwesomeText, charsmax(szMyAwesomeText));
    log_amx("%s", szMyAwesomeText); //Hello John!!!
}
 
addSomeNoise( szText[], size )
{
    add(szText, size, "!!!");
}

Nie zawsze jest to pożądane, dlatego można zabezpieczyć przekazane tablice przed zapisem przez użycie słowa kluczowego const

public plugin_init() {
    new szMyAwesomeText[256];
    formatex(szMyAwesomeText, charsmax(szMyAwesomeText), "Hello %s", "John");
    log_amx("%s", szMyAwesomeText); //Hello John
 
    addSomeNoise(szMyAwesomeText, charsmax(szMyAwesomeText));
    log_amx("%s", szMyAwesomeText); //Hello John!!!
}
 
addSomeNoise( const szText[], size )
{
    //Błąd kompilacji
    add(szText, size, "!!!");
}

Dodałem zdarzenie gdy gracz patrzy na konkretny piksel, Ciężko było użyć silnika, bo np pod kątem byt nie będzie dokładnie takiego rozmiaru co piksel. Pomogła matematyka. Kod wciąż wymaga optymalizacji, ale zaczęło się coś dziać

Canvas

w ramach eksperymentu i `for the lolz` pracuję nad własnym rendererem wewnątrz serwera hlds. Canvas, czyli płótno. O co chodzi?

Plugin oddaje do dyspozycji API, dzięki któremu stworzymy płótno o dowolnych (niestety ograniczonych) rozmiarach. Na tym płótnie możemy rysować ustawiając odpowiednio kolor każdego z pikseli. Rysowaniem zajmuje się Program, rejestrując go podajemy nazwę publicznej funkcji, która będzie wołana co ramkę serwera i w ten sposób możemy aktualizować stan płótna.

Aktualnie płótna można dodawać i konfigurować jedyne z menu dostępnego pod komendą

amx_canvas

Można tam dodawać płótna, zmieniać wymiary, rozmiar i program.

Interakcja

Samo rysowanie to mało. Oczywiście, że chciałoby się mieć wpływ na to co jest rysowane będąc graczem. Podstawowa interakcja to pozostawanie w zasięgu. Główny plugin pozwala zarejestrować callbacki wołane gdy gracz wchodzi i wychodzi z zasięgu płótna. Pozwala to np. zmienić wyświetlany kolor, gdy ktoś patrzy.

Bardziej zaawansowany jest interfejs związany z klawiaturą. Jeśli zdecydujemy się zablokować kamerę gracza na płótnie, wysyłane będą forwardy (również dostępne jako rejestrowalne callbacki) gdy gracz naciska, puszcza lub przytrzymuje klawisz. Na razie nie ma żadnych blokad. Sterując mini-grą gracz będzie biegał i strzelał. Wkrótce się to zmieni

W planach jest także interfejs dotykowy, tzn gdyby jeden piksel był większy niż gracz to możliwe będzie precyzyjne określenie na którym z pikseli gracz stoi. Z tym wiąże się mnóstwo pomysłów do zrealizowania.

Innym typem interakcji może być strzał w piksel. Umożliwiłoby to np. grę w kółko i krzyżyk, gdzie gracze na przemian strzelają w pole gdzie chcą postawić swój znak.

Inicjalizacja

Głównie z powodów technicznych narodziła się idea inicjalizacji. Narysowanie dwustu pikseli na raz zawiesiło mi serwer na dobre kilka sekund, a chwilę potem dostawałem channel overflow. Jako obejście wybrałem liniowe rysowanie pikseli w pierwszych chwilach życia płótna. Podstawowy initializer rysuje po 4 piksele na ramkę, od pierwszego do ostatniego. Potem będzie więcej opcji.

Ograniczenia

Silnik hl pozwala klientowi rysować ~256 bytów. Każdy piksel płótna jest bytem, więc teoretycznie możemy osiągnąć kwadrat 16x16. Jednak kto pierwszy ten lepszy, więc od tej puli należy odjąć wszystko co jest narysowane na mapie + miejsce na nowe obiekty jak wypadające po śmierci bronie czy rzucone granaty. Będąc sam na serwerze bez zamiaru strzelania się z kimś używałem płótna 28x8. Gdyby ktoś chciał umieści płótno na żywym serwerze wątpię czy udałoby się to zrobić dla rozmiarów większych niż w sumie 100-150 (np. 15x10 ).

Demo

Podczas prac robiłem krótkie filmiki z postępów. Oto lista: http://www.youtube.c...hKwIexxiDB238rI

Źródło

https://github.com/e...iks/amxx-canvas

Na razie nie ma sensu robić paczki. Wersja jest dość wczesna. Da się już coś zrobić, ale raczej również jako ekperyment. 

W najprostszym przypadku do działania strony potrzeba 3 stanowisk:

 - programisty

ogarnia html, php itd; w przypadku forum, programistami są np. twórcy phpBB; jeśli chcesz własny skrypt musisz się nauczyć technologii z posta wyżej

- administratora systemu

ogarnia serwer, robi kopie zapasowe, kontroluje zużycie zasobów (np. twardego dysku)

- webmastera

konfiguruje skrypt, dodaje zawartość, w przypadku forum pilnuje też porządku, ustanawia regulaminy

Korzystając z gotowca (CMS albo skrypt forum) masz 2 role do obsadzenia. Webmasterem możesz być znając podstawy html, sysadmin musi znać system operacyjny i software serwera. Pewno, że możesz działać bez administratora. Póki wszystko działa nie ma on co robić. Jednak jak coś się zepsuje ktoś to musi naprawić

Nie wiem co dokładnie masz na myśli przez "przejąć". Skrypt? Prawa administracyjne?

Jeśli na prawdę chcesz `zrobić` stronę no to to jest kanon webdevelopera

Html: http://www.w3schools.com/html/

do treści

CSS: http://www.w3schools.com/css/

do wyglądu

JS: https://developer.mo...docs/JavaScript

do logiki po stronie klienta

Oraz np. PHP http://www.php.net/

do logiki po stronie serwera

Zamiast php może być Python, Ruby, ASP, NodeJS i pewnie jeszcze kilka innych

Jeśli chcesz być webmasterem i tylko zarządzać stroną to rozejrzyj się za CMS, nie wiem jakie są teraz modne, kiedyś bawiłem się http://www.joomla.pl/ i była spoko. Do zarządzania taką stroną i tak warto żebyś zapoznał się z kanonem będzie Ci dużo łatwiej

Zawsze przenosisz do 0,0,0, ponieważ

set_user_origin(id, origin)

w tym miejscu używasz lokalnej tablicy origin[3], a globalna origin[33][3] nigdy nie otrzymuje położenia żadnego gracza.

Nie potrzebujesz lokalnej tablicy, możesz wpisać od razu do globalnej:

get_user_origin(ofiara, origin[id])//pobieranie pozycji
origin[id][1] += 20;

a potem

set_user_origin(id, origin[id])

Jednak [1] += 20 nie gwarantuje, że to będzie za plecami wybranego gracza. Musisz wiedzieć gdzie gracz patrzy i do originu dodać wektor przeciwny do znormalizowane wektoru wzroku, pomnożonego przez odległość (np. 20)

Jako, że fakemeta rulez:

new Float:fVec[3];
pev( ofiara, pev_v_angle, fVec ); 
fVec[2] = -fVec[2];

//Znormalizowany wektor przeciwny do wektora wzroku
angle_vector( fVec, ANGLEVECTOR_FORWARD, fVec );

//przedłużony do 20 jednostek
fVec[0] *= 20.0;
fVec[1] *= 20.0;
fVec[2] *= 20.0;

taki fVec musisz dodać do origin[3], i bedziesz mial 20 jednostek za plecami

alias +blabla "blabla, blabla, +forward"
alias -blabla "-forward"

bind w +blabla

Chodziło o

amxx list

Sigsev masz gdy odwołujesz się do komórki pamięci której nie ma lub nie jest przeznaczona dla Ciebie. Serwerowi brakuje ramu albo masz plugin który używa złych offsetów np. pdata. Widzę, że masz orpheu, z tym modułem najłatwiej się dobrać do niedostępnego obszaru pamięci.

Hej,

chciałbym prosić o zmianę nicku losowy, nieobraźliwy. Zużyłem swój limit w miesiącu, a ktoś przypadkiem dwa razy przywrócił mi mój stary nick.

No chyba że złamałem regulamin. W takim przypadku należy mi się jakieś info/ostrzeżenie, wtedy będę wiedział, że nie mogę mieć wpływu na to jak się nazywam,

Nie pozdrawiam,

reksu

wróć do swojej funkcji

set_user_health( id, iHealth );

Chodziło o moment zmiany skilli, najłatwiej to było osiągnąć właśnie na zamknięcie menu. Jestem przekonany, że serwer MySQL jest przygotowany na dużo większe obciążenie niż ruch, który moglibyśmy wygenerować przez tę zmianę

kombinowaliśmy z zapisem expa po wyjściu z menu, jednak zarówno menusów jak i warunków jest dużo i to będzie spory problem, dlatego polecam Ci spróbować przywrócić zapis po rundzie

żeby usunąć laga musisz zmienić zapis na asynchroniczny, tj 

save_common.inl

// This function will save the XP for all players
public Player_SaveAll()
{
	if ( !get_pcvar_num( CVAR_uwc3ng_save_xp ) )
	{
		return;
	}

	new players[32], numofplayers, i;
	get_players( players, numofplayers );

	for ( i = 0; i < numofplayers; ++i )
	{
		Player_SaveXP( players[i], false );
	}

	return;
}

zamień 

Player_SaveXP( players[i], false );

na

Player_SaveXP( players[i], true);

no i przestaw cvara uwc3ng_save_end_round na domyślne 1

sqlite powinien być szybszy, ale przy synchronicznych zapytaniach też może być lag, najlepiej by było przerobić zapisywanie na metody asynchroniczne 

pewnie przez to

uwc3ng_save_end_round "0" // Czy zapisywać XP pod koniec każdej rundy - możliwy lag (1 - TAK, 0 - NIE)

a xp sie zapisuje?