Kormic

Problem został rozwiązany.

Problem został rozwiązany.

Ten temat został przeniesiony.

Czy tak trudno jest sprawdzić działanie skryptu na serwerze przed udostępnieniem go na forum? Już przy samym przeładowaniu Skript poinformowałby o błędach. Pozdrawiam.

Określenia "dobre" i "darmowe" rzadko (jeśli w ogóle) idą w parze. Jeszcze rozumiem próbę tworzenia portfolio, ale wtedy co najwyżej obniża się cenę usługi, a nie oferuje się za darmo. Jaki macie w tym interes, aby oddawać kod za darmo? Jest to próba przyciągnięcia uwagi, naiwność czy pycha wynikająca z błędnej samooceny swoich umiejętności? Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

Jeżeli ma dojść do zmiany lokacji odrodzenia, należy ustawić odpowiednią wartość wyrażenia 'respawn location' w listenerze zdarzenia 'respawn'. Należy pamiętać, że zdarzenie jest wywoływane przed faktycznym zdarzeniem w grze, więc kod teleportuje gracza do pożądanej lokacji, a chwilę później teleportuje do spawnu, ponieważ taka jest lokalizacja respawnu. Gdyby to nie pomogło, warto podmienić 'on respawn' na 'on respawn with priority highest', aby uniknąć konfliktu z innymi pluginami i/lub skryptami. Pozdrawiam.

@Dominikanek Co dokładnie nie działa? Proszę wytłumaczyć. Warto również podać informacje zwrócone przez komendę /sk info oraz ewentualne błędy wyświetlane przy przeładowaniach skryptu. Pozdrawiam.

Ten temat został przeniesiony.

Ten temat został przeniesiony.

@koxmacius Ten skrypt to jest kwestia parunastu linijek, więc płacenie za niego to w mojej ocenie śmiech na sali. Jeśli jednak te wydawanie przedmiotów ma być jakoś uporządkowane i sensownie zorganizowane (przedmiotów do odebrania może być więcej niż gracz jest w stanie pomieścić w ekwipunku), wtedy dopiero widzę jakikolwiek w tym sens. Może Pan wejść w link w mojej sygnaturze (na dole tego i każdego innego mojego postu), gdzie można poznać szczegóły i warunki współpracy ze mną. Zaznaczam, że przyjmuję tylko płatne zlecenia. Pozdrawiam.

Ten temat został przeniesiony.

@NaxterEK Co prawda link już wygasł, ale zapraszam do kontaktu. Więcej szczegółów można znaleźć w linku w mojej sygnaturze (na samym dole każdego mojego postu). Pozdrawiam.

To prawda, kiedyś faktycznie był z tym problem, ale 'cooldown message' poprawnie parse'uje wszystkie wyrażenia (a więc również zmienne), choć trzeba uważać na zagnieżdżanie tekstu w wyrażeniach, bo powoduje to zwrócenie błędu. Testowy kod poniżej. local function formatTimespan(t: string) :: string: loop ("day", "hour", "minute", "second"): replace all (loop-value + "s" and loop-value) with (first character of loop-value) in {_t} return {_t} command /test: cooldown: 10 seconds cooldown message: test: %formatTimespan(concat(remaining time))% trigger: send "Test." Aby ominąć problem z cudzysłowami, o którym wspomniałem, skorzystałem z funkcji 'concat'. Pozdrawiam.

Problem został rozwiązany.

Proszę. command /diax [<text>]: executable by: players trigger: give diamond to player if size of (all players where [input's groups contain "legenda"]) > 0 Pozdrawiam.

Nie wiem jak pomóc, ponieważ Pan nie pokazał całego kodu. Nie widzę gdzie lista '{misja.%player%::*}' jest modyfikowana (zapisywana). Nie widzę również zdarzenia odpowiadającego za naliczanie zabójstw potworów. Co do samego "Wykonujesz misję <none>/20", nie widzę nigdzie tej 20-tki, więc albo to nie jest ten kod, albo jest ona zapisana w liście. Pozdrawiam.

Przejrzałem skrypt, w mojej ocenie Pana kod wygląda przyzwoicie. Nie uświadczyłem jakichkolwiek rażących błędów, niemniej jednak kilka złych praktyk przykuło moją uwagę, więc uznałem, że wspomnę o nich. Tak więc dołączę się do uwag Pana wyżej. Zalecam unikać zagnieżdżania w sobie warunków, gdyż zmniejsza to czytelność kodu. Uwagę skupiam tutaj głównie na komendzie "/sprawdz". Dla celów dydaktycznych pokażę dwa przykłady - jeden z zagnieżdżonymi warunkami, drugi z warunkami oraz użyciem instrukcji "stop". # 1. Zła praktyka: if arg-1 is set: if arg-2 is set: if arg-3 is set: # Dalsza część skryptu else: send "arg-3 not set!" to player else: send "arg-2 not set!" to player else: send "arg-1 not set!" to player # 2. Dobra praktyka: if arg-1 is not set: send "arg-1 not set!" to player stop if arg-2 is not set: send "arg-2 not set!" to player stop if arg-3 is not set: send "arg-3 not set!" to player stop # Dalsza część skryptu Kod staje się znacznie bardziej przejrzysty, nieprawdaż? Ekstrakcja nazwy użytkownika w listenerze zdarzenia "on inventory click:" z nazwy otwartego ekwipunku jest względnie "dzikim" podejściem. Bardziej elegancki byłby zapis nazwy gracza do jakiejś zmiennej, a następnie pobieranie jej wartości gdy zajdzie taka potrzeba. Nie rozumiem potrzeby opóźnienia o 5 ticków zbanowania gracza po jego wyjściu z serwera. Czy zostało to dodane w jakimś konkretnym celu? Co prawda w przypadku tego skryptu szansa na to jest pomijalnie mała, ale przy większych opóźnieniach może tak się zdarzyć, że w trakcie wykonywania kodu listenera (a konkretniej ów opóźnienia) nastąpi zakończenie pracy serwera. W rezultacie wszelki kod po opóźnieniu nigdy nie zostanie wykonany, co może generować wiele problemów. Należy uważać więc na dodawanie opóźnień i korzystać z nich tylko gdy zamknięcie serwera w ich trakcie nie będzie za sobą niosło poważnych konsekwencji, bądź w sytuacji gdy jest to absolutnie konieczne. Dobrym przykładem takiej sytuacji jest tworzenie ekwipunku i wprowadzenie opóźnienia o 1 tick w celu otworzenia tego ekwipunku (jak to zresztą zrobił Pan w swoim skrypcie).

Nie udzielam wsparcia użytkownikom wykorzystującym biały motyw forum. A tak na poważnie to dziękuję za zwrócenie na to uwagi, poprawię to w wolnej chwili. EDIT: Poprawione.

Ten temat został przeniesiony.

Problem został rozwiązany.

Ten temat został przeniesiony.

Ten temat został przeniesiony.