Kormic

Nie ma problemu. Cieszę się, że Pan zrozumiał. Co do matematyki, oczywiście nie pamięta wół jak cielęciem był, ale w mojej ocenie nie jest jej tutaj zbyt wiele poza wykorzystaniem trygonometrii do tworzenia okręgu. Funkcje sinus i cosinus najlepiej jest graficznie zrozumieć jako współrzędne x i y przy poruszaniu się po okręgu o promieniu 1. Współrzędna x-owa (potocznie: lewo, prawo) to cosinus, natomiast współrzędna y-owa (potocznie: góra, dół) to sinus. Jeśli kąt jest równy 0, zaczynamy po prawej stronie. Uzasadnieniem tego jest fakt, iż cos(0) = 1, a sin(0) = 0. Tak więc, tłumacząc to na współrzędne, otrzymujemy punkt (X,Y) = (1,0). Zwiększając kąt będący argumentem obu funkcji, poruszamy się po wcześniej wspomnianym okręgu przeciwnie do ruchu wskazówek zegara. W celu dalszego zrozumienia polecam Panu wyszukanie sobie wykresów funkcji sinus i cosinus. Przydatne również mogą okazać się materiały do nauki obrazujące wyżej wspomniane poruszanie się po okręgu. Oczywiście zastosowałem w swoim wywodzie kilka skrótów myślowych i pominąłem nieskończenie wiele innych przypadków, jednakże najprościej zacząć od jakiegoś przypadku i próbować zrozumieć całą stojącą za tym teorię drogą indukcji (od szczegółu do ogółu). Na koniec dodam, że nietrudno wywnioskować pewną rzecz. Jeśli chcemy poruszać się po okręgu o promieniu r (gdzie r to dowolna liczba rzeczywista), wystarczy przemnożyć obie współrzędne przez ten promień.

@maloy78 Zakładam, że składnia tworząca GUI pochodzi z dodatku SkQuery. Na tym forum wielokrotnie było mówione, że przez te opóźnienie (jak dobrze pamiętam, bez niego kod nie zadziała) istnieje ryzyko szybkiego otwarcia jakiejś skrzynki i duplikowania przedmiotów. Sugeruję Panu skorzystać z domyślnej składni w Skript'cie. Jest to w mojej ocenie bezpieczniejsze rozwiązanie. command /creategui: trigger: set {_gui} to chest inventory with 3 rows named "&6Test" set slot 1 of {_gui} to iron ingot set slot 2 of {_gui} to iron ingot open {_gui} to player on inventory click: if name of clicked inventory is "&6Test": index of clicked slot is 1 or 2 cancel event close player's inventory

Tak się składa, że już kiedyś pisałem taki skrypt. Proszę uprzejmie.

Czy sprawdził Pan rzeczy, o których mówiłem? Pomijam literówkę przy 'or', bo to jest nieistotne. Proszę pokazać zawartość listy {dragon::*} i nazwy tych GUI, o których Pan mówi.

Ta część jest prosta w napisaniu. Wystarczy zmienić display name, tablist name i natemag gracza oraz ustawić skin. W internecie można znaleźć kilka skryptów i pluginów czyniących to. Jeśli gracze w zależności od permisji mają widzieć różne nazwy, wymaga to obsługi pakietów. Jest to możliwe do napisania, trzeba wysyłać je przy każdorazowej zmianie trybu incognito gracza i przy dołączaniu na serwer. Moja odpowiedź jest lakoniczna i pomija wszelkie technikalia, natomiast mogę od razu powiedzieć, że do tego zadania lepszy byłby plugin. Zdaje się, że plugin HaoNick wprowadza to czego Pan chce i z pewnością nie jest to jedyny publiczny plugin wprowadzający takie funkcjonalności.

Nie zaszyfrowanych, a hashowanych. Jest to ogromna różnica. Coś zaszyfrowanego zawsze można odszyfrować jeśli zna się sam mechanizm danego szyfru, więc jest to operacja wykonywalna w obie strony. Hashowanie natomiast jest operacją nieodwracalną, działa tylko w jedną stronę. Mając jakieś dane możemy łatwo wyznaczyć ich hash, w drugą stronę jest to z praktycznego punktu widzenia niemożliwe biorąc pod uwagę moc obliczeniową dzisiejszych komputerów. Oczywiście istnieje jeszcze prawdopodobieństwo kolizji hashów (dwie różne wartości wejściowe mające taki sam hash), ale jest ono na tyle niskie w przypadku SHA-256, że po znalezieniu jej Pan stałby się sławny. Jest jeszcze opcja hashowania funkcją MD5, ale odradzam korzystania z niej. Jest to zdecydowanie mniej bezpieczny algorytm, podatny na wyżej wspomniane kolizje hashów. Ponieważ funkcja hash jest funkcją działającą tylko w jedną stronę, należy poddać wiadomość napisaną przez gracza hashowaniu i porównać wynikowy hash wiadomości z wartością zmiennej przechowującej hash hasła gracza. Ja rozumiem Pana działanie i po przemyśleniu sprawy zgadzam się z Panem. Po prostu pokazałem drugą stronę medalu takiego rozwiązania i fakt, że takie podejście w przypadku graczy ze zmiennym IP tworzy w konsekwencji wiele niepotrzebnych zmiennych w bazie. Na Pana miejscu stworzyłbym jakąś zmienną gracza zapisująca adres IP, na którym się ostatnio logował na serwer (na przykład 'set {autoLogin::%player's uuid%} to player's ip'). Jeśli przy dołączeniu adres jest inny niż ostatnio, autologin nie następuje. Wtedy zmienna od autologinu będzie posiadała w nazwie tylko UUID gracza, a zapisywanie w nazwie dodatkowo adresu IP będzie już niepotrzebne.

Trudno jest mi jednoznacznie określić przyczynę braku działania Pana skryptu, ponieważ nie wiem jak wygląda zawartość listy {dragons::*} i nie wiem jak wygląda GUI tworzone przez Pana skrypt. W tej sytuacji mogę wskazać dwa najbardziej prawdopodobne scenariusze. Przy kliknięciu na wspomniane smoki numer 3 i 7 warunek porównujący zawartość listy {dragons::*} z nazwą klikniętego inwentarza nie jest spełniony. Tutaj sugeruję dodanie jakiejś instrukcji 'send' po przejściu przez warunek (wyświetlający jakąkolwiek wiadomość, ma to być jedynie informacja) i dodatkowo 'send' przed tym warunkiem wyświetlający nazwę inwentarza 'name of event-inventory'. Dla porównania może Pan również sprawdzić 'name of clicked inventory'. Może mieć Pan w tym lub w jakimkolwiek innym skrypcie (a nawet w pluginie) listener zdarzenia 'on inventory click' (Bukkit API: InventoryClickEvent), który odwołuje anulowanie zdarzenia. Plugin/skrypt może mieć wyższy priorytet dla tego listenera i w tych specyficznych warunkach jest powodem tego dziwnego problemu. Nie traktowałbym tej sugestii na ten moment poważnie, gdyż jest to mało prawdopodobne. Pan powinien na razie się skupić na samym tym skrypcie, później na innych skryptach i finalnie na pluginach. Na pierwszy rzut oka skrypt wygląda całkowicie w porządku, niemniej jednak nie widzę całej prawdy, więc w tej chwili wróżę z fusów. Oczywiście najlepsza i jedyna metoda debuggingu to wysyłanie wiadomości na czacie. Niech Pan sprawdzi wszystkie kluczowe zmienne i wyrażenia, które Pan wykorzystuje w tym skrypcie. Jest szansa, że Pan zauważy jakąś nieprawidłowość. Kończąc mój wywód, do ewentualnego tworzenia testowego kodu listenera 'on inventory click:' może Pan wspomóc się tym warunkiem.

@milonn Co prawda skrypt ma wiele błędów i usterek, ale odniosę się do tych najbardziej krytycznych/rażących. To nie jest prawda i to jest Pana największy grzech. Pan zapisuje hasła użytkowników do zmiennych w postaci niezmodyfikowanego tekstu. Jeśli ktoś nieupoważniony uzyska dostęp do plików serwera, może równie dobrze pobrać kopię bazy danych czy też pliku variables.csv i wtedy konta wszystkich użytkowników będą zagrożone. Zdaje się, że Pan pytał około tydzień temu jak sprawić, aby taki skrypt miał zabezpieczone hasła. Powiedziałem Panu, że dobrym rozwiązaniem będzie hashowanie haseł. Nie rozumiem dlaczego Pan tego nie wdrożył. Rozumiem, że to jest swego rodzaju ukłon w stronę graczy, ale w mojej ocenie wystarczyłby jedna zmienna automatycznego logowania na jedno konto. Trzeba mieć na uwadze to, że niektórzy gracze mogą korzystać z internetu mobilnego lub po prostu mieć router, który zmienia adres IP każdorazowo przy resecie. Nie zapominajmy również o proxy i VPN. Jeżeli coś jest niedopracowane, nie powinien Pan tego dodawać do skryptu. Zamiast tego lepszym podejściem byłoby dopracowanie tej komendy i dodanie jej do kodu przy aktualizacji skryptu. Brakuje jeszcze informacji o tym jakie dodatki są wymagane do działania skryptu. Zdarzenie 'on any movement' to element składni dodatku SkQuery. Nie ma jednak potrzeby korzystania z niego, gdyż Skript posiada swoje własne zdarzenie odpowiadające mu. Mówię o tym zdarzeniu. No dobrze, a teraz odnieśmy się do samego kodu. W kodzie można uświadczyć wiele zagnieżdżonych warunków, które zmniejszają czytelność kodu. Pokażę Panu jak można je poprawić. # Zły sposób: if [warunek]: if [warunek]: if [warunek]: # Dalszy kod... else: # Alternatywny kod else: # Alternatywny kod else: # Alternatywny kod # Dobry sposób (odwracanie warunków): if not [warunek]: # Alternatywny kod stop if not [warunek]: # Alternatywny kod stop if not [warunek]: # Alternatywny kod stop # Dalszy kod... Myślę, że powyższy przykład jest dla Pana wystarczająco przekonujący. Z niezrozumiałych mi powodów Pan używa w kodzie bardzo dużo opóźnień, czasem w miejscach, w których nie mają żadnego sensu. Proszę mieć na względzie to, że dobry kod powinien posiadać możliwie mało opóźnień. Wynika to z tego, że wszelkie opóźnienia są czyszczone przy wyłączeniu serwera, a więc kod po nich następujący nigdy nie zostanie wykonany. Można podążać za następującą regułą - jeśli nie ma potrzeby odliczania lub celowego opóźnienia kodu w celu polepszenia wrażeń z użytkowania skryptu (proszę interpretować wedle uznania), niech Pan nie używa opóźnień. Nie rozumiem na przykład dlaczego Pan wstawił opóźnienia przed zapisem zmiennych. Nie pojmuję również tego dlaczego Pan wstawił w pętlach 'while' opóźnienia trwające 14 dni, choć możliwe, że wynika to tylko i wyłącznie z tego title mającego trwać lata. Niemniej jednak, skłaniam Pana do refleksji w tej kwestii. Nie ma potrzeby rozdzielania listenera zdarzenia 'on join' na dwa osobne listenery. Czyni to kod mniej czytelnym. Jeśli Pan usunie z drugiego listenera te 2-sekundowe opóźnienie, będzie mógł Pan spokojnie połączyć oba te listenery. Przy rejestracji Pan w dziwny sposób sprawdza czy ilość znaków w haśle mieści się w dozwolonym zakresie. Zamiast dodawać i odejmować 1, proszę zastosować operatory porównania '>=' i '<='. Proszę nie brać moich uwag jako złośliwości z mojej strony, a przyjąć je z pokorą i postarać się poprawić ten skrypt. Pozdrawiam.

W takim wypadku proszę sprawdzić poniższą komendą co zwraca wyrażenie 'placeholder %text% from %player%'. command /smpplaceholdertest: executable by: players trigger: set {_value} to placeholder "dropsmp_speed" from player send "Kasa: %{_value}%" to player Jest Pan pewien, że to jest placeholder, o który Panu chodzi? Moja intuicja podpowiada mi, że placeholder "dropsmp_speed" zwraca wartość szybkości gracza ustawioną komendą, którą Pan podał, a nie jego stan konta (zakładając, że temu ma odpowiadać zmienna {kasa::*}).

W takim razie wystarczy, że sprawdzi Pan czy gracz trzyma książkę w ręce. if player's tool is book: # Dalszy kod Jeżeli Pan chce do tego wiadomość w przypadku braku książki w ręce, można to napisać w poniższy sposób. if player's tool is not book: send "&cBrak książki." to player stop # Dalszy kod Pozdrawiam.

Nie wiem skąd Pan wziął wyrażenie 'placeholder %text% from %players%', więc zakładam, że pochodzi ono z jakiegoś dodatku (najpewniej Skellett). on join: set {kasa::%player's uuid%} to placeholder "dropsmp_speed" from player if {kasa::%player's uuid%} >= 210: execute console command "dropsmp player %player's name% set szybkosc 200" Proszę uprzejmie. Wydaje mi się, że dobrze zrozumiałem Pana zlecenie. Jedynie zastanawiałem się nad Pana sformułowaniem "będzie powyżej 210", bo Pan napisał warunek sprawdzający czy zmienna jest większa, bądź równa 210. Mimo to, zostawiłem tak jak Pan napisał. Na koniec powiem o błędach w Pana kodzie. Nie ma potrzeby rozdzielania tak prostego kodu na dwa listenery zdarzenia 'on join'. Takie działanie czyni kod mniej czytelnym. W pierwszym listenerze zdarzenia 'on join' zabrakło apostrofu w wyrażeniu 'player's UUID'. Niezrozumiałym dla mnie jest dlaczego Pan próbował zapisać wartości tego placeholderu wszystkich graczy do zmiennej jednego konkretnego gracza. EDIT: @Żelazio Dodam, że jeśli Pan nie wykorzystuje w jakimkolwiek innym kodzie wartości zmiennej {kasa::%player's uuid%}, zbędnym jest jej tworzenie. Lepiej w takiej sytuacji wykorzystać zmienne lokalne. Podam przykład. # Jeżeli potrzebujemy tej zmiennej w jakimś innym kodzie, tak jest w porządku. set {kasa::%player's uuid%} to placeholder "dropsmp_speed" from player # Jeżeli nie wykorzystujemy w jakimkolwiek innym kodzie tej zmiennej, lepiej zrobić tak jak jest pokazane poniżej. set {_kasa} to placeholder "dropsmp_speed" from player Nie ma potrzeby zapełniania sobie pliku variables.csv (czy też przeznaczonej do zapisu zmiennych bazy danych) niepotrzebnymi nam zmiennymi globalnymi. Zmienne lokalne są tworzone tylko na potrzebę danego kodu - gdy on się zakończy, wszystkie zmienne lokalne są czyszczone.

Gdy pisałem artykuł, zamieściłem w nim definicje każdej funkcji wraz z opisem każdego z parametrów. Dodałem również przykłady użycia skryptu. Jeśli Pan ich nie przeczytał, proszę się z nimi zapoznać. Jeżeli jednak Pan mnie prosi o pomoc po przeczytaniu artykułu, śpieszę z tłumaczeniem. Więc tak. Każda z tych funkcja zwraca listę bloków, którą warto sobie zapisać do lokalnej listy zmiennych. Podkreślam, jest to lista bloków, nie lokalizacji. Mając zapisaną listę z owymi blokami, używamy efektu 'set %blocks% to %item type%'. Z początku może się wydawać to skomplikowane, ale zapewniam o jednym - skrypt został napisany w taki sposób, aby jego użytkowanie było możliwie proste. Jeśli Pan ma jeszcze jakieś pytania/wątpliwości, proszę dać znać. Ewentualny kod jest mile widziany. Pozdrawiam.

Faktycznie. Zapomniałem, że te wyrażenia zostały przeznaczone do usunięcia w wersji 2.8.0. Miło widzieć, że twórcy faktycznie chcą uczynić wektory w Skript wektorami w sensie matematycznym, a nie ich marnymi imitacjami. Być może jednak w najnowszej wersji jest już możliwy iloczyn skalara z wektorem (nie mylić z iloczynem skalarnym). Nie rozumiem jednak dlaczego Skript sugeruje dodanie tych wektorów. Zakładam, że twórcy tylko jedną taką wskazówkę dla dodawania. Nam rzecz jasna zależy na operacji iloczynu skalara i wektora. Niech Pan w takim razie spróbuje napisać tę instrukcję na dwa poniższe sposoby i po zapisaniu zmiennej {_cel} wyświetli ją na czacie. # 1. sposób (o ile można dokonać przemnożenia współrzędnych wektora przez skalar): set {_cel} to 0.8 * {_v} # Powyższa linijka powinna zwrócić wektor, którego moduł jest równy 80% modułu wektora {_v} # Moduł wektora: https://docs.skriptlang.org/expressions.html#ExprVectorLength # 2. sposób (o ile wystarczy pojedynczy znak mnożenia): set {_cel} to {_scalarVector} * {_v} Mam duże wątpliwości co do drugiego, gdyż matematycznie jest to operacja niedopuszczalna - mowa o mnożeniu macierzowym, gdzie ilość kolumn w pierwszej macierzy jest różna od ilości wierszy w drugiej macierzy (przy założeniu, że to są wektory wierszowe). Niemniej jednak warto to przetestować.

Aktualizacja v. 2.0 Nowości: - gruntowna przebudowa artykułu opisującego skrypt, - gruntowna przebudowa i optymalizacja kodu (m.in. zastosowanie funkcji trygonometrycznych do części rozwiązań). Z tego miejsca chciałbym serdecznie podziękować mojemu przyjacielowi (@PanMaruda) za wszystkie udzielone mi wcześniej porady. Nie sądziłem, że powrócę do tej abominacji po tylu latach, a jednak. Zapraszam Państwa do zapoznania się z wprowadzonymi zmianami i przetestowania skryptu pod kątem wszelkich błędów oraz sugestii jego udoskonalenia. Pozdrawiam.

Jeśli kod został zawarty w listenerze zdarzenia 'on damage:' i sprawdzono czy obaj uczestnicy zdarzenia (victim i attacker) to gracze, to prawie bezbłędnie Pan to napisał, bardzo ładnie. Jedyny błąd to pojedynczy znak mnożenia. Jeśli chcemy przemnożyć dwa wektory przez siebie (a więc wszystkie współrzędne pierwszego przez odpowiadające współrzędne drugiego), należy użyć podwójnego znaku mnożenia '**'. W razie niepewności ponownie odsyłam do dokumentacji.

SkWand Witam Państwa, jest to już moje trzecie publicznie udostępnione na tym forum dzieło. Jak można się domyślić po nazwie, jest to prosty skrypt dodający różdżkę, którą można strzelać. Cechy: - zestaw funkcji implementujących mechanizm strzelania z różdżki, - odrzucające pociski (a więc możliwość tzw. "rocket jumpingu"), - efekty dźwiękowo-wizualne przy zderzeniu pocisku ze ścianą, - możliwość konfiguracji właściwości różdżki i jej pocisków. Dodatkowo: - komenda /magicwand dająca graczowi z odpowiednią permisją różdżkę, - listener zdarzenia 'on right click:' obsługujący strzelanie z różdżki wraz z cooldownem. Wymagania: - Skript (min. 2.2-dev28) Użycie: Korzystanie ze skryptu jest banalnie proste. Po jego instalacji na serwerze wystarczy dać sobie różdżkę przy pomocy komendy /magicwand. Mając ją w ręce, możemy z niej strzelać poprzez wciskanie prawego przycisku myszy. Konfiguracja skryptu: Należy jeszcze wspomnieć o tym jak należy konfigurować ten skrypt w sekcji 'options' na górze kodu. Uznałem, że najlepiej będzie to zawrzeć w kilku moich zaleceniach, punkt po punkcie. 1. Prędkość pocisku powinna być dostosowana do wielkości pocisku (jego hitboxu). Jeśli prędkość będzie zbyt duża, a hitbox zbyt mały, skrypt nie będzie w stanie wykrywać bytów i ścian. 2. Nie należy ustawiać zbyt dużej maksymalnej odległości jaką może pokonać pocisk. Pozwala to uniknąć scenariusza, w którym wiele pocisków jest wystrzeliwanych jednocześnie. 3. Cooldown różdżki natomiast nie powinien być zbyt mały. Ponownie, wszystko sprowadza się do utrzymania stabilności serwera. 4. Zasięg odrzutu różdżki należy ustawić odpowiednio mały. Im jest on większy, tym silniejszy jest odrzut, dlatego należy ustawiać tę wielkość roztropnie. Informacje dodatkowe: W związku ze zmianami w arytmetyce wektorowej, które zostały wprowadzone w wersji 2.8.0, w przypadku posiadania tej wersji lub nowszych, należy zmienić każde podwojone wystąpienie znaków +, -, *, / na pojedyncze ich wystąpienie, na przykład: ++ -> +. Wtedy ostrzeżenie przy przeładowaniu skryptu zniknie. Pobieranie: https://code.skript.pl/7gO6bkfa Dziękuję za poświęcony czas na czytanie, życzę miłej zabawy ze skryptem. W razie problemów lub sugestii, proszę je zgłosić w sekcji komentarzy pod tym artykułem.

Miło mi to słyszeć. Proszę uprzejmie. Wydaje mi się, że o to Panu chodziło. options: worldName: world function hornCoralPlantsReduce(p: player): {hornCoralPlants::removeFifty::%uuid of {_p}%} is set set {_item} to living horn coral plant named "&6Rozgwiazda" with lore "&8» &7Waluta z &eEventu wakacyjnego &f(2024)" and "&8» &7Wymienisz ją na &fklucze &7pod &f/event" set {_number} to amount of {_item} in {_p}'s inventory {_number} > 0 set {_reducedNumber} to ceil({_number} / 2) remove {_reducedNumber} of {_item} from {_p}'s inventory clear {hornCoralPlants::removeFifty::%uuid of {_p}%} on death of player: "%regions at event-location%" contains "event-wakacyjny in world {@worldName}" keep inventory victim doesn't have permission "wakacje.drop1" set {hornCoralPlants::removeFifty::%uuid of victim%} to true on respawn: hornCoralPlantsReduce(player) on join: hornCoralPlantsReduce(player) Tutaj proponuję Panu zainteresowanie się pluginem WorldGuard Extra Flags. Po jego zainstalowaniu może Pan ustawić dla tego regionu blokadę latania przy pomocy elytry. Co prawda można to zablokować w Skript, ale jeśli plugin już to oferuje, lepiej wybrać takie rozwiązanie.

Jakby poszukać po forum, z pewnością by się coś takiego znalazło. Niemniej jednak, nikt nie pisze skryptów o tak niskiej złożoności. Opiszę krok po kroku jak można samemu stworzyć taki skrypt. Nasłuchujemy do listenera zdarzenia 'on death:'. Sprawdzamy czy victim (ofiara) to gracz. Można również skorzystać po prostu ze zdarzenia 'on death of player:'. Sprawdzamy czy attacker (atakujący) to gracz. Ten warunek należy napisać w poniższy sposób. if attacker is a player: Przedimek 'a' ma tu znaczenie, gdyż samo 'player' oznaczałoby, że się próbujemy odnieść do któregoś z uczestników tego zdarzenia (ofiary lub atakującego). Dzięki temu przedimkowi Skript rozumie, że jest to warunek sprawdzający czy ktoś po prostu jest graczem, nie jakimś konkretnym. Jeśli powyższe warunki zostały spełnione, wysyłamy wiadomość do attackera (atakującego) za pomocą efektu 'message/send'. Proszę zwrócić uwagę na to, że w dokumentacji podane są również przykłady do każdej instrukcji. Powinny one pomóc w zrozumieniu.

Proszę zauważyć, że w moich skryptach wklejam sekcję import zawsze nad wszelkim kodem, aby Skript w pierwszej kolejności pobrał z innych API wszystkie potrzebne rzeczy. Sam autor skript-reflect zaleca tak czynić, więcej o tym można poczytać tutaj. Niemniej jednak dobrze, że się to wyjaśniło. Niech Pan jeszcze raz przejrzy wszystko to o czym pisałem i da znać czy działa jak należy.

Jak najbardziej. Wyjaśnię w kilku krokach jak można taki skrypt napisać. Nasłuchujemy do listenera zdarzenia 'on damage:'. Sprawdzamy czy ofiara (victim) to gracz. Zapisujemy do jakiejś zmiennej lokalnej (na przykład {_v}) wektor zaczynający się w lokalizacji zaatakowanego i kończący się w lokalizacji atakującego. Tutaj przyda się te wyrażenie z dokumentacji. Normalizujemy ów wektor (zmniejszamy jego moduł (długość) do 1). Powinniśmy tak zrobić, gdyż obrażenia zadawane przez strzałę zależą od jej prędkości, a bez normalizacji mielibyśmy sytuację, że im dalej stałby atakujący, tym szybciej strzała wędrowałaby w jego kierunku (a więc zadawałaby więcej obrażeń). Możemy przemnożyć (ale nie musimy) ten wektor przez jakąś stałą, aby zmienić prędkość strzały. Niestety, Skript nie wspiera mnożenia wektorów przez skalar. Jesteśmy zmuszeni więc stworzyć wektor o identycznych współrzędnych (np. 'set {_scalarVector} to vector 0.8, 0.8, 0.8'). Gdy już stworzyliśmy sobie taki wektor, możemy go przemnożyć przez nasz wektor z punktu 3 i zapisać wynik tego mnożenia (który jest rzecz jasna wektorem) do jakiejś zmiennej lokalnej. Najprościej jest posłużyć się tym wyrażeniem. Finalnie, możemy użyć efektu 'shoot'. Na końcu musimy dodać nasz wektor, aby Skript wiedział w jakim kierunku ma zostać wystrzelona strzała.

Niech Pan wyłączy serwer, usunie mój skrypt i spróbuje ponownie go włączyć. Jak już Pan to zrobi i serwer się uruchomi (co będzie oznaczało, że zawinił mój skrypt, choć nie wiem w jaki sposób), niech Pan sprawdzi rozmiar listy i powie mi co skrypt wyświetla na czacie. Mowa o wcześniej przeze mnie udostępnionej komendzie /coralslist. Po tym zdecyduję co dalej. Zapewne kolejnym krokiem będzie sprawdzenie za pomocą komendy pluginu ile istnieje takich hologramów i ręczne pousuwanie ich.

W takim razie Pan dobrze zrobił jeśli Pan przeczytał wszystko to co napisałem. Mam nadzieję, że Pan najpierw przeczytał cały post, a dopiero później wkleił kod komendy. Przejrzałem logi i zauważyłem wiele błędów z różnych pluginów, ale też znalazłem błędy przy samym Skript'cie. Szczerze mówiąc, nie jestem w stanie wywnioskować co jest przyczyną. Abstrahując, na przyszłość zalecam wrzucać wszelkie logi i dłuższe skrypty na serwis code.skript.pl. Wydaje mi się, że plugin powinien udostępniać jakąś komendę wyświetlającą nazwy wszystkich istniejących hologramów. Proszę poszukać.

Wszystko zależy od tego co Pan zrobił i czy Pan podążał za moimi instrukcjami. Jeśli tak, proszę powiedzieć na którym kroku doszło do zakończenia pracy serwera. Mimo wszystko sugeruję ręczne usunięcie tych hologramów. Korzystanie z listy wszystkich hologramów jest dość niebezpieczne, a ja nie chcę wyrządzić krzywdy Panu serwerowi.

Ach tak... zapomniałem. Mój błąd. Oczywiście bez tej linijki nie zadziała wywołanie jakiejkolwiek metody z DecentHolograms API. Cieszy mnie to, że Pan również myśli. Zedytowałem skrypt, który wcześniej podesłałem Panu. Niech Pan przetestuje komendę, którą przesłałem Panu w celu sprawdzenia rozmiaru listy zapisującej ID oraz przykładowych ID w niej zapisanych. Powinno być w niej tyle ID, ile jest starych hologramów. Jeśli lista okaże się pusta albo ilość zapisanych ID będzie mniejsza niż ilość starych hologramów, obawiam się, że Pan będzie zmuszony ręcznie je usunąć. Każdy hologram postawiony przez skrypt ma nazwę "hornCoralID_<liczba między 1 a 1 000 000>". Po chwili wpadłem jednak jeszcze na jeden pomysł. Co prawda bezpośrednio w API nie jest to udostępnione, ale możemy pobrać nazwy wszystkich hologramów na serwerze. import: eu.decentsoftware.holograms.api.DHAPI eu.decentsoftware.holograms.api.holograms.Hologram command /coralsclear: permission: server.command.coralsclear trigger: loop {hornCoralPlants::hologramIDs::*}: set {_holoFullID} to "{@hologramIDPrefix}_%loop-value%" DHAPI.removeHologram({_holoFullID}) clear {hornCoralPlants::hologramIDs::*} clear {hornCoralPlants::corals::*} set {_hologramNames} to Hologram.getCachedHologramNames() loop ...{_hologramNames}: loop-value starts with "{@hologramIDPrefix}" DHAPI.removeHologram(loop-value) send "&aWyczyszczono wszystkie zmienne i hologramy związane z koralowcami." to sender Niech Pan wrzuci taki skrypt, ale dopiero po tym jak Pan przeczyta mój post do końca. Co prawda warunek powinien powstrzymać (o zgrozo) usunięcie wszystkich hologramów, ale prosiłbym, aby Pan na początku stworzył jakieś trzy hologramy zaczynające się tym samym ciągiem znaków. Na przykład niech Pan stworzy 3 hologramy o nazwach "hologramCoralTest1", "hologramCoralTest2" i "hologramCoralTest3". Do tego niech Pan zmieni w trzeciej linijce od końca ''{@hologramIDPrefix}" na "hologramCoralTest". Jak już Pan to zrobi, niech Pan wykona poniższą komendę. import: eu.decentsoftware.holograms.api.holograms.Hologram command /coralstesting: permission: server.command.coralstesting trigger: set {_hologramNames} to Hologram.getCachedHologramNames() loop ...{_hologramNames}: loop-value starts with "hologramCoralTest" send "Test pomyślnie ukończony." to sender Jeśli tylko trzy razy (nie więcej!) wyświetli się napis "Test pomyślnie ukończony.", może Pan spróbować wykonać powyższy skrypt. Mam nadzieję, że wszystko pójdzie po Pana myśli. EDIT: Na koniec dodam, że Pan powinien użyć tej komendy tylko jeśli rzeczywiście powstało wiele nieusuwalnych hologramów. Jeśli jednak jest ich nie więcej niż kilkadziesiąt, sugeruję ręcznie je pousuwać komendami z pluginu DecentHolograms.

No dobrze. Mam nadzieję, że przynajmniej wyświetliła się Panu wiadomość o wyczyszczeniu zmiennych, bo jeśli nie, oznacza to niewykonywanie się kodu komendy. Już patrzę w czym problem. Zauważyłem, że linijka 82. jest zbędna. Może Pan ją usunąć. Niech Pan sprawdzi czy lista {hornCoralPlants::hologramIDs::*} zawiera jakiekolwiek elementy. command /coralslist: permission: server.command.coralslistsize trigger: send "Ilość zapisanych ID: %size of {hornCoralPlants::hologramIDs::*}%" to sender size of {hornCoralPlants::hologramIDs::*} > 0 set {_i} to 1 loop {hornCoralPlants::hologramIDs::*}: if {_i} > 20: exit loop send "Zapisane ID: %loop-value%" to sender add 1 to {_i} Komenda wyświetli rozmiar listy z ID oraz wyświetli pierwsze 20 zapisanych ID. Powinny to być liczby między 1 a 1 000 000 (milion).