Skocz do zawartości

Witamy w Nieoficjalnym polskim support'cie AMX Mod X

Witamy w Nieoficjalnym polskim support'cie AMX Mod X, jak w większości społeczności internetowych musisz się zarejestrować aby móc odpowiadać lub zakładać nowe tematy, ale nie bój się to jest prosty proces w którym wymagamy minimalnych informacji.
  • Rozpoczynaj nowe tematy i odpowiedaj na inne
  • Zapisz się do tematów i for, aby otrzymywać automatyczne uaktualnienia
  • Dodawaj wydarzenia do kalendarza społecznościowego
  • Stwórz swój własny profil i zdobywaj nowych znajomych
  • Zdobywaj nowe doświadczenia

Dołączona grafika Dołączona grafika

Guest Message by DevFuse
 

Puchate - zdjęcie

Puchate

Rejestracja: 17.06.2014
Aktualnie: Nieaktywny
Poza forum Ostatnio: 19.07.2019 13:40
*****

#698363 Zablokowanie działania funkcji, gdy admin jest na serwerze.

Napisane przez Sooldierr w 22.04.2015 19:28

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++


  • +
  • -
  • 1


#697941 [CS:GO] Perm Mute

Napisane przez Amaroq w 19.04.2015 01:54

Moim zdaniem to lepiej byłoby napisać ten plugin już pod nową składnię, gdyż SM 1.7 został już stabilną wersją. Przydałoby się poprawić/zmienić parę rzeczy.

new String:nick[MAXPLAYERS+1][33];

na

new String:nick[MAXPLAYERS+1][MAX_NAME_LENGTH];

Zamienić to

RegConsoleCmd("mutemenu", MuteMenu);

na

RegAdminCmd("mutemenu", MuteMenu, ADMFLAG_GENERIC);

w związku z powyższym usunąć to

public Action:MuteMenu(client,args)
{
    if(CheckCommandAccess(client, "generic_admin", ADMFLAG_RESERVATION, false))    MuteMenu2(client);
}

i zamienić

public Action:MuteMenu2(client)

na

public Action:MuteMenu(client,args)

Usunąć to

for(new client = 1; client <= MaxClients; client++)
        {
            if(IsClientInGame(client))
            {
                if(AreClientCookiesCached(client))
                {
                    OnClientCookiesCached(client);
                }
            }
        }

Prawdę mówiąc nie wiem co to ma na celu, forward OnClientCookiesCached sam się wywołuje, jak wczyta ciasteczka.

GetClientName(client, nick[client], 32);

->

GetClientName(client, nick[client], MAX_NAME_LENGTH);

Do usunięcia

OnClientCookiesCached(client);

To też out

public OnPluginEnd()
{
    for(new client = 1; client <= MaxClients; client++)
    {
        if(IsClientInGame(client))
        {
            OnClientDisconnect(client);
        }
    }
}

ponieważ OnClientDisconnect wykonuje się przy zmianie mapy, więc dodatkowe wywołanie go jest chyba bezcelowe :P

 

Tutaj mały błąd

for(new i=1;i<GetMaxClients();i++)

na

for(new i=1;i<=MaxClients;i++)

i mała poprawka

new String:buffer[50];
new String:poz[10];
for(new i=1;i<=MaxClients;i++)
    {
        if(!IsClientInGame(i))    continue;

        FormatEx(buffer, 49, "%s %s", nick[i], ma_mute[i] ? "[MUTED]" : "");
        FormatEx(poz, 9, "%i", i);

        AddMenuItem(menu, poz, buffer);
    }

Zmienne przeniesione poza pętle + zmiana z Format na FormatEx

 


  • +
  • -
  • 2


#695404 Admin On Server - Aktywność adminów na serwerze

Napisane przez DarkGL w 03.04.2015 10:28

opis
Plugin zbiera informacje o czasach grania adminów i zbiera je w jeden plik logów w którym znajdziecie informacje o ilości czasu spędzonym na serwerze przez adminów.

http://darkgl.pl/ind...ow-na-serwerze/

instalacja
Standardowa

inne informacje
Plików z logami należy szukać w folderze logs nazwa pliku w formacie
dzien_miesiac_rokadminActivity
download
Załączony plik  adminOnServer.sma   2,17 KB  490 Ilość pobrań
  adminOnServer.amxx
  • +
  • -
  • 5


#663139 "Dziwny" round sound

Napisane przez bambus199810 w 11.09.2014 18:21

Witam, często zamiast mojej muzyki pod koniec rundy słychać takie jakby prychanie prrr hmrrrr jakby ktośtak prcyhał :D Trwa to długo więc nie wiem co sie dzieje. Proszę o pomoc.


  • +
  • -
  • 3


#662927 Długość trwania display fade

Napisane przez SeeK w 10.09.2014 00:14

Tak też ostatecznie postanowiłem zrobić. Wysyłam po prostu fadea co sekundę.
  • +
  • -
  • 1


#662166 EngFunc_FindEntityByString nie znajduje paki

Napisane przez szelbi w 04.09.2014 21:36

Masz w pierwszym poście ;)
  • +
  • -
  • 0


#662190 Press To Pickup – Podnoszenie broni jednym klawiszem

Napisane przez Oporowiec w 05.09.2014 01:27

no dobre :)
mam pytanie, jest możliwość aby zamiast nazwy broni dodać jej ikonę? (tekst zastąpić np. sprites)

chodzi mi o te ikony:
amxx_1329068326__2.jpg




#661947 Ostrzeżenie a regulaminy

Napisane przez G[o]Q w 03.09.2014 13:38

btw skoro dzial jest moderowany to po co karać za post który moderacji nie przeszedł?

Nie wystarczyło odrzucić postu z powodem że forum to nie bazar? przecież nie trzeba dawać warnów przy każdej okazji
 


  • +
  • -
  • 5


#661090 [ROZWIĄZANE] Szukam Buy 3 Smoke Granade za 10 000 $

Napisane przez radim w 29.08.2014 20:55

@up

client_print(0, print_chat, "Masz za malo pieniedzy!")
na:

client_print(user_Id, print_chat, "Masz za malo pieniedzy!")

  • +
  • -
  • 2


#655595 Deploy crashuje serwer - niewidoczna broń

Napisane przez GwynBleidD w 08.08.2014 18:42

A powiedz mi BlackPerfum kilka rzeczy

1. czy dostrzegasz w tym rozwiązaniu rekurencję?
2. czy jest ona niezbędna?
3. Czy potrafisz przewidzieć WSZYSTKIE warunki wyjścia z niej i dopilnować, aby zawsze nastąpiło wyjście z niej?

Rozumiem argument, że broń nie zmieni się poprawnie, jeśli w PRE podmienimy parametr, dlatego owszem należy wywołać zmianę broni jeszcze raz, ale po co tu rekurencja... Przelećmy pętlą po wszystkich broniach gracza w Poście (bo Pre nie ma sensu używać, jeśli nie podmieniamy zmienianej broni) i po wyrzuceniu niepotrzebnych zmieńmy na jedną z tych, które gracz użyć może, jednak już używając execute bez B...

Tworzenie rekurencji poprzez Ham jest niezalecane i to mocno... w jakimkolwiek przypadku... Nie dość, że sam pawn rekurencji nie optymalizuje, więc wychodzi ona dużo bardziej kosztownie, niż pętle, to jeszcze przy okazji mielimy wszystkim, co silnik robi podczas zmiany broni + wszystko co po drodze robi Ham i niech nam jeszcze do tego samego eventu inny plugin się podepnie... Istna katorga i nie dziwię się, że serwer by padł tylko od tego, nawet gdy rekurencja zakończy się prawidłowo.
  • +
  • -
  • 2


#653133 wysyłanie e-mail z serwera

Napisane przez Oddaj Wiertarke w 27.07.2014 01:51

Łap to powinno Ci pomóc.

http://amxx.pl/topic...12-smtp-client/


  • +
  • -
  • 1


#651073 [Poprawione] Lepszy sposób zmiany prędkości gracza

Napisane przez Gość w 18.07.2014 20:48

totalna bzdura Ham_CS_Player_ResetMaxSpeed nie zmienia offsetu m_flWeaponSpeed. Jedynie pobiera z niego wartość...

Nigdzie tak nie napisałem, ŁŻESZ.
 

uznałeś iż wartość offsetu m_flWeaponSpeed jest zmieniana w Ham_CS_Player_ResetMaxSpeed

Nigdzie tak nie napisałem. ŁŻESZ.
 
 

Dlatego iż tylko część broni używa tego offsetu:

Zalinkowałeś fragment kodu, który… nie istnieje!
HLSDK nie udostępnia broni innych, niż glock.
Jeśli korzystałeś z CSSDK, to Cię zaskoczę, bo kod jest nieoficjalny i błędny.
Jeśli sam próbowałeś odtworzyć kod źródłowy CSa, to Cię zaskoczę, ale mylisz się.
 
 
Reszta posta, standardowo, wyssana z palca. BZDURY.
 
 
 
edit:
Widzę, że w wyniku moich uwag, zmieniłeś Ham_Item_PreFrame na Ham_CS_Item_GetMaxSpeed.
Jest postęp, teraz uwzględniasz już Zoom oraz rozbrajanie bomby!
Teraz jeszcze został Ci spawn, ale… zamiast rejestrować 2 eventy, wystarczy Ham_CS_Player_ResetMaxSpeed.
 
Podsumowując, cieszę się, że wreszcie przyznałeś się do błędu i poprawiłeś podstawowe błędy.

Jednak nie na marne się produkuję.




#650805 [Poprawione] Lepszy sposób zmiany prędkości gracza

Napisane przez Gość w 17.07.2014 20:41

Zajawka


ale już nie pamiętam

A szkoda.
 

Wstęp :: Wyjaśnienie ogólne



Ham_Item_Deploy wykonuje się, gdy gracz wyciąga broń, zresztą zgodnie z dokumentacją kanapki.
Zmiana prędkości gracza następuje jedynie m.in. po zmianie broni.
 
Ham_Item_Deploy różni się od CurWeapon tym, że jest niezawodne i wykonuje się równo raz dla wyciągnięcia broni.
Jest to zdecydowanie lepsza metoda od CurWeapon, gdyż jest niezawodna; jednakże jest to tylko jeden z wielu przypadków, gdy następuje maksymalna zmiana prędkości gracza.
 
Innymi słowy, nie uwzględniłeś ŻADNEGO przypadku zmiany maksymalnej prędkości gracza poza tym jednym, jedynym, tj. po zmianie broni, co spowoduje, że Twoja metoda zadziała jedynie w nielicznych przypadkach.
 

Czarno na białym :: Logi



Ponieważ, pomimo przeczytania kilki artykułów na temat zmiany prędkości u gracza, dalej "nie pamiętasz", kiedy dokładnie ona zachodzi i, będąc członkiem Support Teamu AMXX.pl, piszesz takie brednie, mało tego, podając argumenty wyssane z palca (czyt. ŁŻESZ!), przedstawię czarno na białym, że się mylisz.
 
Wobec tego gwałtu na jakości i rzetelności Support Teamu, którego się dopuściłeś, po blisko pół roku, na nowo zainstalowałem starego, poczciwego CSa 1.6 i jakże kochanego HLDSa tylko po to, by pokazać, jak kłamliwym w swej "profesji" i niegodnym jakiegokolwiek zaufania w tej kwestii uzerem (przez "z" specjalnie) jesteś.
 
Stworzyłem prosty plugin, który będzie notował pewne eventy związane z tym tematem i linkowanym, plus kilka eventów jako punkt odniesienie (start i koniec rundy).
Dodatkowo, notowana będzie maksymalna prędkość gracza tuż po wystąpieniu eventu, oraz moje wypowiedzi, odpowiadające działaniom przeze mnie podejmowanym.
Plain SMA (myślę, że nie wymaga komentarza):
Spoiler

Plain log (cut to session, puste linie dodane przeze mnie w celu zwiększenia czytelności).
Spoiler

Notki odn. testów:

  • sv_maxspeed na serwerze testowym wynosi 1000
  • Dodałem się jako admina w postaci jednej linijki do users.ini
  • Reszta bez zmian; czysta instalka:
    • HLDS 48/1.1.2.7/Stdio 6027 secure  (10)
    • Metamod 1.21.1-am
    • AMXX 1.8.3 3983 (base + cstrike); linux

Ham_Item_PreFrame
Ma tylko jedną wadę tzn. to jest think wykonuje się tyle samo ile gracz posiada fps. Zatem podczas 1 min gry może wykonać się 6000 razy nawet jeśli stoimy w miejscu i totalnie nic nie robimy  Czegoś tak nie optymalnego nie chcemy. Dlatego ta opcja od razu odpada.

Patrzę na logi trwające 2 minuty i 17 sekund i nie widzę, by Ham_Item_PreFrame wykonał się (6000 / 10) × (2 × 60 + 17) = 100 × 137 = 13700 razy., a podpowiem, że miałem ok. 100 fpsów.
 
Ham_Item_PreFrame bowiem nie wykonuje się "tyle samo ile gracz posiada fps"; czyt. ŁŻESZ.
 
 

Ham_CS_Player_ResetMaxSpeed
Patrząc na to teoretycznie to ta funkcja nie posiada wad ale jednak w praktyce się znajdują. Tzn:
• wykonuje sie parę razy więcej niż powinna gdyż nasza prędkość jest resetowana także podczas freeze time'u, śmierci, spawn'u

  • BzduraHam_Item_Deploy nie wykonuje się ani razu z faktu wystąpienia freezetime, tak samo jak Ham_CS_Player_ResetMaxSpeed.
    Logi po rozpoczęciu freezetime:
    L 07/17/2014 - 19:45:38: [test.amxx]L 07/17/2014 - 19:45:35: [test.amxx] logevent_round_start
    L 07/17/2014 - 19:45:36: [test.amxx] Benio: Dolaczenie
  • BzduraHam_Item_Deploy wykonuje się tyle razy samo, co Ham_CS_Player_ResetMaxSpeed po śmierci, dokładnie 1 raz.
    Logi po śmierci:
    L 07/17/2014 - 19:47:23: [test.amxx] Benio: Kill
    L 07/17/2014 - 19:47:23: [test.amxx] MaxSpeed: 250
    L 07/17/2014 - 19:47:24: [test.amxx] logevent_round_end
    L 07/17/2014 - 19:47:24: [test.amxx] Ham_Item_Deploy
    L 07/17/2014 - 19:47:24: [test.amxx] Ham_CS_Player_ResetMaxSpeed
    L 07/17/2014 - 19:47:24: [test.amxx] Ham_Item_PreFrame
    L 07/17/2014 - 19:47:24: [test.amxx] Ham_Killed
  • BzduraHam_CS_Player_ResetMaxSpeed ma się wykonywać podczas spawnu wielokrotnie (czyt. dla każdej broni).
    Logi ze spawnu:
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_CS_Player_ResetMaxSpeed
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_Item_PreFrame
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_Item_Deploy
    L 07/17/2014 - 19:45:38: [test.amxx] MaxSpeed: 1000
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_CS_Player_ResetMaxSpeed
    L 07/17/2014 - 19:45:38: [test.amxx] MaxSpeed: 250
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_Item_PreFrame
    L 07/17/2014 - 19:45:38: [test.amxx] MaxSpeed: 250
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_CS_Player_ResetMaxSpeed
    L 07/17/2014 - 19:45:38: [test.amxx] MaxSpeed: 250
    L 07/17/2014 - 19:45:38: [test.amxx] Ham_Item_PreFrame
    L 07/17/2014 - 19:45:38: [test.amxx] MaxSpeed: 250
    
     
    Jak widać w logach, po Ham_Item_Deploy prędkość wynosi tyle, co sv_maxspeed, a dopiero Ham_CS_Player_ResetMaxSpeed dla każdej kolejnej broni, ustawiają odpowiednią prędkość.
    Konkluzja: Twoja pożal się "metoda" nie zadziała, gdyż zostanie nadpisana kolejnymi wystąpieniami Ham_CS_Player_ResetMaxSpeed po których Ham_Item_Deploy już nie występuje!
    Innymi słowy, gracz nie uzyska zmiany prędkości dopóki po spawnie nie zmieni broni (tak samo, jak przy CurWeapon)! I tu JUŻ wychodzi Twoja ignorancja w kwestii 1."Nie pamiętam", 2. Braku jakiegokolwiek rzetelnego sprawdzenia tego, o czym piszesz.

W jakiś sposób trzeba rozróżnić wykonanie się tej funkcji w czasie freeze time'u i po nim

Bzdura. Zajmuje się tym Ham_CS_Player_ResetMaxSpeed, który i tak nadpisze zmiany dokonane w Ham_Item_Deploy podczas freezetime, o czym napisałem wyżej.
 


NAJWAŻNIEJSZE Ta funkcja jest dostepna dopiero w wersji 1.3 hamsandwich'a co jest jej największą wadą gdyż z wielu przyczyn nie każdy ma mozliwość jego aktualizacji

Bzdura. HamSandwich w wersji 1.3 jest domyślnym modułem AMXX od wersji 1.8.3, a więc NIE WYMAGA AKTUALIZACJI.
 
Przykład Twojej ignorancji i jej fatalne skutki, czyli Zoom.


L 07/17/2014 - 19:46:25: [test.amxx] Benio: Glock > AWP
L 07/17/2014 - 19:46:25: [test.amxx] MaxSpeed: 250
L 07/17/2014 - 19:46:26: [test.amxx] Ham_Item_Deploy
L 07/17/2014 - 19:46:26: [test.amxx] MaxSpeed: 250
L 07/17/2014 - 19:46:26: [test.amxx] Ham_CS_Player_ResetMaxSpeed
L 07/17/2014 - 19:46:26: [test.amxx] MaxSpeed: 210
L 07/17/2014 - 19:46:26: [test.amxx] Ham_Item_PreFrame
L 07/17/2014 - 19:46:26: [test.amxx] MaxSpeed: 210
 
L 07/17/2014 - 19:46:30: [test.amxx] Benio: Zoom
L 07/17/2014 - 19:46:30: [test.amxx] MaxSpeed: 210
L 07/17/2014 - 19:46:32: [test.amxx] Ham_CS_Player_ResetMaxSpeed
L 07/17/2014 - 19:46:32: [test.amxx] MaxSpeed: 150
L 07/17/2014 - 19:46:32: [test.amxx] Ham_Item_PreFrame
L 07/17/2014 - 19:46:32: [test.amxx] MaxSpeed: 150
 
L 07/17/2014 - 19:46:36: [test.amxx] Benio: Zoom x2
L 07/17/2014 - 19:46:36: [test.amxx] MaxSpeed: 150
L 07/17/2014 - 19:46:36: [test.amxx] Ham_CS_Player_ResetMaxSpeed
L 07/17/2014 - 19:46:36: [test.amxx] MaxSpeed: 150
L 07/17/2014 - 19:46:36: [test.amxx] Ham_Item_PreFrame
L 07/17/2014 - 19:46:36: [test.amxx] MaxSpeed: 150
 
L 07/17/2014 - 19:46:40: [test.amxx] Benio: Zoom 0
L 07/17/2014 - 19:46:40: [test.amxx] MaxSpeed: 150
L 07/17/2014 - 19:46:40: [test.amxx] Ham_CS_Player_ResetMaxSpeed
L 07/17/2014 - 19:46:40: [test.amxx] MaxSpeed: 210
L 07/17/2014 - 19:46:40: [test.amxx] Ham_Item_PreFrame
L 07/17/2014 - 19:46:40: [test.amxx] MaxSpeed: 210

Po zmianie broni na AWP, Ham_Item_Deploy zmienia prędkość na 250, a następnie Ham_CS_Player_ResetMaxSpeed na 210, po czym Ham_Item_Deploy już nie występuje ponownie.
Innymi słowy, Ham_CS_Player_ResetMaxSpeed nadpisze zmianę dokonaną w Ham_Item_Deploy tym samym sprawiając, że, znowu, Twoją metodę można wysłać jedynie do /dev/null.
Co się stanie po Zoomie? To samo! Ham_Item_Deploy nie wystąpi podczas, gdy Ham_CS_Player_ResetMaxSpeed owszem, nadpisując ustawienia Twojej (tfu!) "metody".
 
Spawnem i Zoom to nie jedyne eventy, których nie uwzględniłeś, a jeśli do Ham_Item_Deploy dodasz je, oraz wszystkie pozostałe eventy, podczas których zmienia się prędkość broni, ale nie ma ich w załączonych logach ze względów ograniczonej długości posta, uzyskałbyś dokładnie event Ham_CS_Player_ResetMaxSpeed, który to przecież pochodzi wprost z silnika gry i dlatego jest najoptymalniej zmieniać prędkość właśnie tam.
 
Jakiekolwiek rzadsze podmiany wartości zawsze zostaną nadpisane poprzez niekryte wystąpienia Ham_CS_Player_ResetMaxSpeed, a częstsze będą mniej optymalne.
 

TL;DR



27920 wykazał się, jako członek Support Teamu AMXX.pl, niekompetencją i totalną ignorancją, przedstawiając nieprzetestowany i niedziałający, zupełnie błędny sposób, który wyłoży się już przy, chociażby, wyciągnięciu AWP (sprawdź sam!), mało tego, bezczelnie nazywając tę "metodę" "lepszym sposobem zmiany prędkości gracza" (sic!), pokazując, msz, że nie jest godny rangi Support Teamu, gdyż nawet nie przetestował tego jakże błędnego sposobu, do tego okłamując czytelników, podając fałszywe argumenty "za" swoją niedziałającą metodą.

 

PS


Ode mnie, oczywiście, soczysty, czerwony minus i wniosek o zmianę rangi.




#645101 [ROZWIĄZANE] Brak działań administracji

Napisane przez GT Team w 23.06.2014 22:34

No przecież oczywiście, że o tym wiem, jak mogłes przeczytać chodzi dokładnie o dział forum ( propozycje ) -> oraz dawne moje zgłoszenia "zgłoś post moderatorowi". Tak więc powtarzam chodzi o tematy wcześniejsze, które nawet do teraz są nei zamknięte, a żaden Head się nie wypowiedział, co do tego, ( i teraz pytanie Czy musi się wypowiadać ? ). Nawet nie wiem, czy jest to propozycja, dobra, czy jak.. A może ktoras wejdzie w życie?