Skocz do zawartości

Kormic

Zasłużony
  • Ilość zawartości

    11012
  • Rejestracja

  • Ostatnia wizyta

  • Wygrane w rankingu

    230

Treść opublikowana przez Kormic

  1. Miałem iść spać, bo do roboty trzeba wstać, ale zdaje się, że noc nieco mi się przeciągnie. Po pierwsze, komenda /skeconomy jest bardzo brzydko napisana, bo zostały w niej powielone warunki sprawdzające czy argumenty zostały podane. Można przecież ją skrócić do następującej postaci: if arg 1 or arg 2 or arg 3 is not set: send "..." stop if arg 2 is "add": # [...] else if arg 2 is "set": # [...] else if arg 2 is "remove": # [...] O wiele ładniej, nieprawdaż? Zaskoczę Was, bo można jeszcze prościej to załatwić za pomocą pola 'usage' w komendzie i usunięcia opcjonalności argumentów (nawiasy kwadratowe). Wtedy pierwszy warunek staje się całkowicie zbędny. Po drugie, komenda /transfermoney posiada ten sam problem z niepotrzebnie opcjonalnymi argumentami, których istnienie i tak dalej jest sprawdzane w kodzie. Co więcej, warunki w linijkach 46 i 59 nie mają żadnego sensu, ponieważ same typy argumentów wymagają aby podany gracz był na serwerze (typ 'player' oznacza gracza obecnego na serwerze) i żeby podany drugi argument był liczbą. Po trzecie, sortowanie potencjalnie dużej listy na każde zawołanie gracza jest bardzo nieodpowiedzialne i generuje niepotrzebne obciążenie dla serwera. Lepszym rozwiązaniem będzie skorzystanie z jakiegoś periodicala, który okresowo sortowałby tę listę ze stanami kont graczy i tworzył na ich podstawie toplistę zapisywaną do jakiejś listy globalnej. Jej zawartość byłaby następnie pobierana przez komendę kiedy to tylko potrzebne. Zalecam sprawdzić skrypt PyraTop REBORN (autorstwa mojego dobrego przyjaciela @PanMaruda), który można znaleźć na tym forum. Służy on właśnie do tworzenia toplisty na podstawie dowolnej listy zmiennych. Pozdrawiam.
  2. Zdarzenia 'on join' i 'on login' odpowiadają zdarzeniu dołączania gracza na serwer gdy już fizycznie się na nim znajduje. Wbrew nazwie, zdarzenie 'on login' nie ma nic wspólnego z jakimkolwiek logowaniem, a więc nie ma tutaj mowy o jakiejkolwiek interakcji z pluginem LoginSecurity. Cały kod poza komendą wykonuje się przy dołączeniu gracza (w ostatnim listenerze z dwutickowym opóźnieniem). Jeżeli chce Pani aby skrypt nasłuchiwał do zdarzenia logowania za pomocą pluginu LoginSecurity, jest to możliwe z pomocą dodatku skript-reflect, ponieważ plugin udostępnia kilka metod i zdarzenie pozwalające to osiągnąć. Mogę napisać taki skrypt na zlecenie, więcej szczegółów można znaleźć w temacie podlinkowanym w mojej sygnaturze (na samym dole tego postu). Pozdrawiam.
  3. @SkryptExpert Ten skrypt nie zadziała, ponieważ nie można porównywać okresu czasu (timespan) z liczbą, a sekcja 'else' nie jest przyporządkowana do jakiegokolwiek warunku. Jeżeli to ma działać, należałoby napisać w kodzie '{@cooldown} seconds'. Co więcej, zdarzenie 'on death' jest wywoływane przy śmierci dowolnego bytu, nie tylko gracza. Warto również sprawdzić czy atakujący byt jest graczem. on death of player: attacker is a player # [...] Na koniec dodam, że skrypt miał dodawać cooldown na nagrodę uzyskaną z ponownego zabicia tego samego gracza. Poniżej podsyłam moją propozycję rozwiązania. options: cooldown: 5 minutes reward: 1000 on death of player: attacker is a player if difference between {cooldown::%attacker's uuid%::%victim's uuid%} and now is less than {@cooldown}: send "Ups! Masz cooldown..." to attacker stop set {cooldown::%attacker's uuid%::%victim's uuid%} to now add {@reward} to attacker's balance send "Otrzymałeś {@reward}$." to attacker Pozdrawiam.
  4. Problem został rozwiązany.
  5. No właśnie, nie ma co wynajdywać koła na nowo. @milonn Od siebie dopowiem jeszcze, że zamiast wysyłać puste linie (z perspektywy gracza tym jest ciąg przełamań linii) kilka razy po 100 lepiej jest zbudować sobie długi tekst zbudowany ze stu przełamań linii (new line), a następnie wysyłać go tylko mod(ilość wiadomości, 100) razy. Ograniczamy w ten sposób ilość iteracji jaką musi wykonać pętla. # [...] set {_clearChatMessage} to nl repeated 100 times loop mod({_numberOfMessagesToRemove}, 100) times: send {_clearChatMessage} # [...] Pozdrawiam.
  6. Również chciałbym zaoferować swoje usługi. Więcej informacji poniżej. Jest to ten sam link co w mojej sygnaturze. Pozdrawiam.
  7. Zlecenie zostało wykonane.
  8. Faktycznie, zwracam honor. Wyrażenie zwraca listę bloków i je ustawia. Niemniej jednak, moja uwaga co do 'an anvil' nadal jest słuszna, ponieważ skrypt podmienia jedynie nieuszkodzone kowadła, więc nie ma mowy o regeneracji. Wątpię aby silnik miał wpływ na to, bo aliasy są zdefiniowane w samym Skript'cie. Mogę tutaj tylko powiedzieć, że mój serwer postawiony na localhost'cie jest oparty o silnik Paper 1.21-111. a wymienione wtyczki mają dokładnie te same wersje co Twoje. Przetestowałem również kod Coffeina i warunek porównujący region z tekstem działa, więc musiałem najprawdopodobniej zapomnieć o usunięciu drugiego takiego samego regionu w innym świecie (choć byłem święcie przekonany, że go usunąłem). Ewentualnie doznałem jakiegoś bardzo rzadkiego błędu ze strony Skripta. Nadal jednak oba kody Coffeina borykają się z błędami, o których wspominałem wyżej i wymienię je ponownie: otwieranie niefunkcjonalnego GUI kowadła i działanie naprawiającego skryptu jedynie po kliknięciu na nieuszkodzone kowadło. Aby on działał, należałoby wykorzystać zdarzenie 'on rightclick on any anvil'. Przepraszam za zamieszanie i pozdrawiam.
  9. Zalecam przeczytać ten fragment FAQ pluginu OreAnnouncer i upewnić się, że permisje na serwerze związane z tym pluginem zostały poprawnie dodane. Warto również sprawdzić czy bloki w pliku konfiguracyjnym blocks.yml są zapisane według tego fragmentu wiki pluginu. Pozdrawiam.
  10. @CoFFeIN04 @polsatgraniepl @Xyntegi_ok Zanim zamknę temat, chciałbym powiedzieć, że wszystkie powyższe kody nie działają na wersji 1.21 z najnowszą wersją Skripta i WorldGuarda, ponieważ: Skript nie jest w stanie zrozumieć tekstu jako regionu (to znaczy, pobrać regionu na podstawie jego nazwy), porównywanie obiektu regionu z tekstem nigdy nie zadziała, co jest bezpośrednio powiązane z tym co napisałem wyżej. Jak można więc pobrać region na podstawie nazwy? Cóż, jedyny działający sposób w czystym Skript'cie to użycie wyrażenia '%text% parsed as %*type%'. Przykład poniżej. set {_region} to "kowadla" parsed as region Dzięki powyższej linijce uzyskujemy region na podstawie jego nazwy. Należy jednak uważać, ponieważ nie zadziała on dla regionów dzielących tę samą nazwę, ale istniejących w różnych światach (WorldGuard dopuszcza tworzenie takich regionów). Po otrzymaniu obiektu reprezentującego region reszta kodu regenerującego uszkodzone kowadła staje się trywialna. every 10 seconds: set {_region} to "kowadla" parsed as region set (blocks in region {_region} where [input is any anvil]) to anvil Wspomnę jeszcze tylko o tym, że choć wedle dokumentacji słowo 'region' w składni wyrażenia 'blocks in %region%' jest opcjonalne, ze względu na kolizję składni musi ono się tam znaleźć. Finalnie, jeszcze mam trzy uwagi- jedną do Coffeina i dwie do polsatgranie. @CoFFeIN04: otwieranie GUI kowadła poprzez Skripta co prawda zadziała, ale takie GUI jest bezużyteczne, ponieważ nic nie da się w nim zrobić. Warto tu powiedzieć, że jest to problem związany z Bukkit API, a nie z samym Skriptem. Aby uporać się z tym problemem, należy wykorzystać albo wysyłanie pakietów, albo pakiet NMS. Można się tutaj posłużyć biblioteką AnvilGUI, która zdecydowanie ułatwia te zadanie. @polsatgraniepl: Alias 'an anvil' obejmuje jedynie nieuszkodzone kowadło. Aby skrypt obsługiwał kowadła w dowolnym stanie, należy użyć aliasu 'any anvil'. Zalecam nie podawać typu przy wyrażeniu 'input', ponieważ czasem powoduje to brak działania filtru. Przynajmniej tak było w wersji Skripta 2.9.0, nie miałem okazji przetestować tego w wersji 2.9.1. Zdarzenie 'anvil damage' jest jednym z tych zdarzeń, których użyteczność jest niemalże bliska zerowej, ponieważ (najprawdopodobniej) nie posiada jakichkolwiek wartości możliwych do pobrania związanych ze zdarzeniem, co jest następstwem wpakowania go do klasy SimpleEvents, która "przechowuje" dziesiątki innych takich mało użytecznych zdarzeń. Pozdrawiam.
  11. Ten temat został przeniesiony.
  12. Ten temat został przeniesiony.
  13. Problem został rozwiązany.
  14. Ten temat został przeniesiony.
  15. Ten temat został przeniesiony.
  16. Problem został rozwiązany.
  17. Problem został rozwiązany.
  18. Ależ to nie jest bug. Po prostu skrypt jest tak napisany. Proszę spojrzeć do linijki 19. Przy każdym wykopaniu kamienia wysyłana jest wiadomość na czacie gracza jeśli wykopał on tyle samo lub więcej kamienia niż jest wymagane (w skrypcie jest ustawione 500). Jak ma to działać inaczej to trzeba zmienić ten warunek. Wystarczy zmienić '>=' na '=' lub 'is'. Pozdrawiam.
  19. @Indyv Jedyny dodatek, który ma prawo działać na tym serwerze to skript-reflect, ponieważ wspiera on najnowszą wersję Skripta (2.9.1). Co do pozostałych dodatków: skUtilities - stary dodatek, przestał on być rozwijany w 2018 roku i wspiera on wersję Minecrafta nie wyższą niż 1.11, skRayFall - nieaktualizowany od 2 lat, zakończył swoje wsparcie na wersji 1.19.1, SharpSK - również stary dodatek, aktualizowany ostatnio w 2017 roku, przeznaczony na wersje nie wyższe niż 1.12. Jeżeli skrypty nie działają poprawnie, zawsze należy sprawdzić czy wersje zainstalowanych dodatków do Skripta są aktualne. Wszystkie trzy wymienione wyżej dodatki nie mają możliwości współpracy z najnowszą wersją Minecraft i Skripta, więc należy je usunąć z serwera. Pozdrawiam.
  20. Tak długo jak w kodzie nie ma warunków sprawdzających czy gracz jest operatorem, nie ma to żadnego znaczenia, więc szukałbym przyczyny gdzie indziej. Mogę pomóc, ale: Pozdrawiam.
  21. Nie widzę błędów w skrypcie, zresztą potwierdził to Skript przy przeładowaniu skryptu. Wypadałoby jednak poprawić użycie niezapisanej zmiennej lokalnej '{_player}' w listenerze zdarzenia 'on chat' na zwyczajne 'player', aby wiadomość do gracza faktycznie była wysyłana. Przetestowałem kod u siebie i wszystko działa jak należy (z uwzględnieniem poprawki, o której wspomniałem wyżej). Dla porównania podam specyfikację swojego serwera: Silnik: Paper 1.21-111, Skript: 2.9.1, Lista dodatków do Skripta: skript-reflect 2.5.1. Rozumiem, że nie działa anulowanie wysyłania wiadomości przez gracza na czacie. Możliwych powodów jest kilka, więc wymienię tylko te, które na ten moment przychodzą mi do głowy: na serwerze znajduje się skrypt lub wtyczka (plugin) powodująca anulowanie wysyłania wiadomości i wysyłanie jej sformatowanej wersji, co jest marną implementacją formatowania czatu, wersja Skripta jest nieaktualna lub któryś z dodatków jest nieaktualny, inny skrypt lub wtyczka posiada listener o wyższym priorytecie, który unieważnia anulowanie następujące w tym skrypcie. W przypadku pierwszego i trzeciego należy samodzielnie przeszukać foldery 'plugins/Skript/scripts/' i 'plugins/'. Jeśli chodzi o drugie, proszę wpisać komendę '/sk info' i podać wszystkie informacje wyświetlone przez Skripta. Czyszczenie czatu powinno wykorzystywać efekt 'send "" to all players', ponieważ efekt 'broadcast' tyczy się również konsoli, a wysłanie 100 pustych linijek w niej z pewnością jest zachowaniem niepożądanym, bo znacznie utrudnia zarządzanie serwerem. Sugeruję również korzystać z list zmiennych, które pozwalają na wydajniejsze zarządzanie zmiennymi. Na forum ten temat był przytaczany wielokrotnie, więc zalecam poczytać. Pozdrawiam.
  22. Problem został rozwiązany.
  23. Ten temat został przeniesiony.
  24. Co prawda problem został już rozwiązany na serwerze Discord SkUnity, ale powiem co było przyczyną. Dla pocisków należy korzystać z wyrażenia 'last shot %entity%'. W tym przypadku więc jest to 'last shot arrow'. Pozdrawiam.
  25. Problem został rozwiązany.
×
×
  • Dodaj nową pozycję...