Kormic

@wikt0r3k Dokumentacja składni z SkBee nie jest szczególnie pomocna w przypadku efektu `delete world file...`, dlatego też postanowiłem zajrzeć do kodu źrodłowego SkBee. Ważne przy analizie źródła problemu są dwa niżej załączone fragmenty kodu: reg.newEffect(EffLoadWorld.class, "load world from [[world] creator] %worldcreator%", "load world %namespacedkey%", "unload [world] %world% [and (save|1:(do not|don't) save)]", "delete world file for [world] %string%", "delete world file for world with key %namespacedkey%") a także: if (this.pattern == 3 && LegacyUtils.IS_RUNNING_MC_26_1_1) { Skript.error("A world file cannot be deleted by name in Minecraft 26.1+"); return false; } if (this.pattern == 4 && !LegacyUtils.IS_RUNNING_MC_26_1_1) { Skript.error("A world file cannot be deleted by key in Minecraft 1.21.11 or below."); return false; } Pole "this.pattern" przechowuje indeks wzorca, który został wykorzystany. Możliwe wzorce załączyłem w pierwszym fragmencie, indeksacja zaczyna się od zera. Jaki płynie z tego wniosek? Jeżeli wersja serwera to 26.1 lub wyższa, należy wykorzystać ostatni wzorzec. W przeciwnym wypadku, należy skorzystać z przedostatniego wzorca. Z racji tego, że wersja twojego serwera to 26.1.2, powinieneś skorzystać ze wzorca "delete world file for world with key %namespacedkey%", gdzie `%namespacedkey%` to nic innego jak "%przestrzeń nazw%:%nazwa świata%". Jako przykład może posłużyć "minecraft:the_end". Pozyskanie samego klucza w przestrzeni nazw jest bardzo proste. Możesz wykorzystać to wyrażenie z SkBee, co finalnie daje instrukcję "delete world file for world with key (namespaced key of loop-world)". Pozdrawiam.

Fendi, mam podejrzenie graniczące z pewnością, że nie przeczytałeś mojego posta. W pierwszym akapicie podałem instrukcję, którą można wykorzystać, tę samą co ty. Ta dodatkowa matematyka to opis rozsądniejszego sposobu tworzenia sfery, bez konieczności zapętlania bloków wewnątrz niej.

Trzeba mieć na uwadze to, że wyrażenie `blocks around %location% in radius %number%` bierze pod uwagę wszystkie bloki, których środki są odległe o nie więcej niż zadany promień. W konsekwencji, jeśli zadana lokacja do zapętlania bloków nie leży w środku bloku, powstała sfera (czyli, jak to ująłeś, kula pusta w środku) nie będzie symetryczna. Jednym z możliwych rozwiązań jest wykorzystanie `location of block at %location%` jako środka sfery, którą chcesz utworzyć. Wtedy masz gwarancję symetrii. Inny sposób stworzenia sfery to wykorzystanie promienia wodzącego, który wskazuje miejsce utworzenia bloku. Tworzysz wektor o długości promienia sfery, którego yaw (obrót lewo/prawo) i pitch (obrót góra/dół) są modyfikowane z pewnym krokiem, dostosowanym do promienia sfery (im większy promień, tym mniejszy musi być krok, ponieważ powstaną dziury w powierzchni). Przykład implementacji takiego rozwiązania podałem poniżej. set {_r} to 5 set {_centerLoc} to location(100, 100, 100, "world") set {_rotationStep} to 10 set {_v} to vector(0, -{_r}, 0) loop ceil(180 / {_rotationStep}) times: loop ceil(360 / {_rotationStep}) times: set block at {_centerLoc} ~ {_v} to obsidian add {_rotationStep} to yaw of {_v} remove {_rotationStep} from pitch of {_v} Nie jest to optymalne rozwiązanie, ponieważ ustawia ono te same bloki wielokrotnie, szczególnie bliżej "spodu" i "szczytu" sfery. Dobrze napisany kod powinien brać to pod uwagę i modyfikować `yaw` ze zmiennym krokiem. Niemniej jednak, jest to i tak lepsze rozwiązanie niż zapętlanie wszystkich bloków, włącznie z tymi wewnątrz sfery. Mogłem także użyć wektorów sferycznych, ale uznałem składnię zwykłych wektorów za czytelniejszą. Pozdrawiam.

@PolsatGraniePL Rzeczywiście czasem można odnieść wrażenie, że dobre praktyki w Skript biorą się, przepraszam za wyrażenie, z dupy. Wynikają one jednak (zwykle, bo rzecz jasna nie każda rada musi być dobrą praktyką) z, jak to się profesjonalnie etykietuje, wymagań niefunkcjonalnych. W przypadku Skripta od kodu wymaga się, aby był niezawodny, czytelny i możliwie prosty. Na podstawie tych wymagań można oceniać jakość skryptów. Pozdrawiam.

@manesiuuuu Jeśli chodzi o skrypty chociażby w AutoHotkey, to nie. Jak w opisie oferowanych usług opisanych wyżej, zajmuję się jedynie skryptami do pluginu Skript na serwery Minecraft. Pozdrawiam.

A co się takiego zmieniło w tym 2026? W 2025 jeszcze można było się bawić? Skript to narzędzie, jak każde inne. Ma dużo ograniczeń i z pewnością to nie jest state of the art, ale nie przesadzajmy. Jego największą zaletą jest prostota i czytelność, dzięki czemu też znajduje zastosowanie. Pozdrawiam.

Ten temat został przeniesiony.

@xSebixx1 Należy sprawdzić również czy kliknięty inwentarz nie należy do gracza. clicked inventory is not player's inventory Pozdrawiam.

Ten temat został przeniesiony.

@naujan Rozwiązanie Twojego problemu znajdziesz w tym wątku. Pozdrawiam.

@Ryanlowkeygoat Proszę pokazać w jaki sposób cudzysłowy zostały podwojone. Mam na myśli linijkę kodu z podwojonymi cudzysłowami. Pozdrawiam.

Ten temat został przeniesiony.

Ad 1. Dobrze, ale zauważ, że znasz rozwiązanie tylko dlatego, bo wiesz jak wygląda kod definiujący komendę. Zwykły gracz nie będzie tego wiedział. Bądź co bądź, zgodziliśmy się, że prawdopodobieństwo dołączenia graczy o tych nazwach jest skrajnie małe, więc możesz to zignorować. Ad 4. Też mam takie przeczucie, niemniej jednak w przypadku takich stwierdzeń należy być ostrożnym, bo w rachubę wchodzi tu wiele zmiennych, między innymi: specyfikacja maszyny serwera, obciążenie, silnik, zainstalowane wtyczki, itd. Dobra praktyka nakazywałaby obsługę wszystkich, nawet najmniej prawdopodobnych scenariuszy, ale na mniejszym serwerze sądzę, że nigdy do tego nie dojdzie. Odpowiadając na ogół wiadomości, cieszę się, że moje wskazówki okazały się pomocne. Pozdrawiam.

Ten temat został przeniesiony.

@wikt0r3k Skrypt wygląda całkiem obiecująco, ale znajdują się w nim cztery rzeczy, nad którymi należałoby się pochylić: Komenda /friend [nazwa] nie zadziała w przypadku graczy, którzy mają nazwę add, remove, list, accept i reject. Prawdopodobieństwo, że gracz mający jedną z wymienionych nazw dołączy do serwera jest bardzo małe, jednakże trzeba o tym pamiętać. Aby to nie sprawiało problemu, sugeruję usunięcie tego "skrótu" i używanie pełnej formy, to znaczy /friend add [nazwa]. W przypadku stosowania opóźnień w kodzie należy być ostrożnym i mieć na uwadze to czy skrypt poprawnie będzie działał po restarcie serwera. Od razu mogę powiedzieć, że restart serwera w trakcie oczekiwania na wygaśnięcie zaproszenia sprawi, że nigdy do niego nie dojdzie. W tej sytuacji można zastosować wymienione dalej rozwiązania: horologe.sk - pozwala na tworzenie opóźnień, które są zapisywane przy zatrzymaniu serwera i kontynuowane po jego ponownym starcie, cykliczne zadanie (np. every 1 second) odliczające 60 sekund i zapisujące opóźnienie w zmiennej przypisanej do gracza, można też po prostu unieważnić zaproszenie przy zatrzymaniu serwera (zdarzenie on server stop), co wydaje się najlepsze. Cooldown nie powinien być zmniejszany co sekundę gdy gracz jest na serwerze, ponieważ sprawia to, że nie będzie on aktualizowany gdy gracz jest offline. Powinno być to zastąpione obliczaniem różnicy czasu. Poradnik opisujący to można znaleźć tutaj. Nie wiem czy można ponownie dołączyć do serwera (tzw. rejoin) w czasie krótszym niż sekunda, ale jeśli tak, istnieje ryzyko, że wiele instancji tej samej pętli while może działać dla jednego gracza jeśli wykona on rejoin np. w 0.9 sekundy (18 ticków) i przy okazji "ominie" wykonanie pętli. Jeśli moje obawy tutaj są uzasadnione, należałoby na przykład generować losowe UUID przy każdym rozpoczęciu pętli i zapisywać w zmiennej globalnej, i przy każdym jej wykonaniu sprawdzać czy UUID się zmieniło - jeśli tak, należy wyjść z pętli, czyli zakończyć ją. Pozdrawiam.