Kormic

@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.

@MOLINEK66 W wyżej zaprezentowanym skrypcie widzę trzy wady: Dobrą praktyką jest przyporządkowanie zmiennych związanych z danym skryptem do jednej, wspólnej listy. Oferuje to łatwiejsze zarządzanie nimi (zmiennymi). Przykładowo: {inspectPlayers::isChecked::%arg 1%} {inspectPlayers::inspectionPlace} W kodzie powinien być dodany warunek blokujący inicjację sprawdzania gracza, który jest już sprawdzany. Analogiczny warunek powinien istnieć dla zakończenia sprawdzania. Przy zakończeniu sprawdzania gracz powinien być teleportowany do jego poprzedniej lokacji. Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

Zarzut nietrafiony, ponieważ identyczne ryzyko niesie ze sobą de facto każdy inny skrypt i wtyczka przeznaczone do zabezpieczania dostępu hasłem. Ponadto, instalacja na serwerze dwóch różnych narzędzi do tego samego celu bez sensownego powodu nie wróży nic dobrego. Mała uszczypliwość z mojej strony - skrypt jest przeznaczony do zabezpieczania kont z permisją operatora, więc utratą zwykłych graczy z powodu bana nie ma co się martwić. Co do reszty punktów i rzeczy, które wypunktowałeś Przyjacielu, nie mam zastrzeżeń. Zgadzam się z ogólną myślą zawartą w Twoich wiadomościach. @MOLINEK66, z punktu widzenia bezpieczeństwa, ten skrypt zawiera jedną poważną wadę - PINy nie są hashowane. Gorąco zachęcam do zapoznania się z ideą hashowania, której znajomość jest niezbędna w przypadku zarządzania PINami i hasłami. Gdyby ktoś był zainteresowany dłuższymi rozważaniami na ten temat, polecam przeczytać ten wątek. Jeśli chodzi o samo hashowanie w Skript, te wyrażenie z pewnością pomoże. Pozdrawiam.

Ten temat został przeniesiony.

@RtSyS W artykule, który poleciłem, autor pokazał kilka różnych rozwiązań (a w zasadzie to obejść, autor określił je jako "workarounds") tego samego problemu. Wystarczy, że wykorzystasz taki, który najlepiej odpowiada Twoim potrzebom. Jeżeli nie masz pewności co będzie dla Ciebie najlepszym rozwiązaniem, proponuję wypróbować je wszystkie i zobaczyć jak działają. Podejrzewam, że pierwszy, opisany jako "Remove Vanilla Atttribute Modifiers", wystarczy jako rozwiązanie Twojego problemu. Pozdrawiam.

Problem został rozwiązany.

Ten temat został przeniesiony.

@wikt0r3k Twój kod zawiera kilka błędów: Funkcje wywołuje się w Skript poprzez samą ich nazwę i listę argumentów między nawiasami. Słowo run w tym miejscu jest błędne. Okalające procenty są wykorzystywane tylko do zagnieżdżania wartości zmiennej w tekście. Nie powinny się one pojawić przy przekazywaniu wartości jako argumentów do funkcji. Ponadto: random player out of all players in world "%loop-world%" można zapisać krócej jako random player out of all players in loop-world. all players in world {_world} powinno być zapisane jako all players in {_world}. Zalecam zapoznanie się z podstawami składni Skript. Pozdrawiam.

@RtSyS Gorąco polecam tę lekturę. Powinna pomóc skoro mówimy o wersji serwera nie starszej niż 1.20.5. Pozdrawiam.

Skrypt został niepoprawnie wklejony, przez co wygląda jakby był ucięty w połowie. Ponadto, Paper od paru lat oferuje anty x-ray z bogatą konfiguracją na poziomie silnika, co deklasuje zaprezentowane przez Ciebie rozwiązanie. Pozdrawiam.

W takim razie proszę o informacje zwrócone przez komendę /sk info i wyświetlony błąd przy przeładowaniu skryptu. Pozdrawiam.

Ten temat został przeniesiony.