Ranking

Cześć Chciałbym wam przedstawić pewien system funkcji. Mianowicie chodzi o system zarządzania cooldownem. Funkcje udostępniam ponieważ wiele użytkowników nie wie jak poprawnie stworzyć cooldown a ten system funkcji powinien im to ułatwić. Funkcje są dostępne tutaj Środowisko: - skript min 2.6 - serwer 1.18.1 Jak używać? Najpierw trzeba stworzyć nasz cooldown funckją createCooldown(nazwa cooldowna, czas) np: on load: createCooldown("heal", 10 second) Następnie w kodzie musimy sprawdzić status cooldowna gracza funkcją: getCooldown(gracz, "nazwa cooldowna") np: command /heal [<text>]: trigger: if getCooldown(player, "heal"): Nastepnie gdy wykonamy kod musimy ustawic cooldown gracza funkcją: setCooldown(gracz, "nazwa cooldowna") np: setCooldown(player, "heal") Opis wszystkich funkcji: createCooldown(%string%, %time span%, %boolean-2%) - Tworzy cooldown deleteCooldown(%string%) - Usuwa cooldown setCooldown(%player%, %boolean%) - Ustawia status cooldownu getCooldown(%player%, %string%) - Zwraca status cooldownu w booleanie (np true) getCooldownBoolean(%player%, %string%) - Zwraca status cooldownu w booleanie (np false) getCooldownDate(%player%, %string%) - Zwraca date wygaśnięcia cooldownu (np 22.08.19 15:00) getCooldownTime(%player%, %string%) - Zwraca czas wygaśnięcia cooldownu (np 10 second) getCooldownText(%player%, %string%, %format%) - Zwraca przetłumaczony czas cooldownu (np 10 minut i 2.34 sekund) Małe wyjaśnienie: %string% - nazwa cooldownu (np "poradnik") %time span% - czas cooldownu (np 10 second) %player% - gracz (np player) %boolean% - status cooldownu (np true) %boolean-2% - czy automatycznie ma ustawić cooldown na true (np true) %boolean-3% - Włączenie bypassa do ominięcia cooldownu (np false) %format% - Customowa lista tłumaczeń (np "lat" and "rok", "miesiecy"...) Przykładowe skrypty z użyciem tych funkcji: Automatyczna aktualizacja Jeżeli chcesz aby ten skrypt aktualizował ci się automatycznie pobierz skrypt AxAutoUpdate

Skript-mirror W tym poradniku przedstawię wam jak tworzyć własne efekty, wyrażenia i warunki za pomocą pięknego dodatku skript-mirror oraz jego forka skript-reflect Ogólny wzór składni [text] Opcjonalne (text) Wymagane text1|text2 albo %text% typ zmiennej np Składnia [(xAxee|Ax)] [the] (plugin|plg) (man|manager) (disable|off) (plugin|plg) %string% Moze jedynie zostać: plg man disable plg "Ticker" Albo: xAxee the plugin manager disable plugin "Ticker" Uwaga ! Jeżeli na początku damy local to dany efekt / wyrażenie / warunek będzie mógł być wykorzystany tylko w skrypcie w którym się znajduje ! ! Efekty / wyrażenia / warunki muszą być nad wykonywanym kodem lub w innym skrypcie ! ! Do podanych argumentów zwracamy się expr-<numer argumentu> ! ! Efekty / wyrażenia / warunki mają małą siłę i zostaną "pokonane" jeżeli jakiś dodatek posiada takie wyrażenie, dlatego dobrze gdy mają przedrostek ! Efekty (Effects) (Coś co wykonuje jakiś kod) dealy effect #Zatrzymuje kod w efekcie i dalszy kod w skrypcie continue #Wznawia zatrzymany kod Najpierw musimy zdefiniować składnie naszego wyrażenia [local] effect <składnia>: parse: #Opcjonalnie #kod (domyślne ustawiania zmiennyc) trigger: #Wymagane #kod np: effect [AxTops] (clear|reset) all [top] points: trigger: loop {points::*}: set {points::%loop-index%} to 0 Taki efekt możemy użyć np tak: command /pointsreset: permission: * trigger: reset all top points send "&7Zresetowanie" stop Warunki (condition) (Warunki wykorzystujemy w ifach) Również najpierw musimy zdefiniować wyrażenie [local] condition <składnia>: check: #wykonywany kod continue ! Continue dajemy wtedy gdy kod spełnił warunek i kod za ifem może się wykonać (czyli zwróci true) ! np: condition [AxTops] %player% can buy (for|with) %number%: check: if {points::%expr-1%} >= expr-2: continue Możemy to wykorzystać jako: command /kupmiecz [<text>]: trigger: if player can buy for 200: add diamond sword to player remove 200 from player's points send "poprawnie zakupiono!" stop send "Nie masz tyle punktow" Wyrażenia (expression) (Coś co zwraca wartość) Definiujemy [plural] [local] expression <składnia>: parse: #Opcjonalnie #kod... get: #Opcjonalnie #kod... return... add: #Opcjonalnie #kod... set: #Opcjonalnie #kod... remove: #Opcjonalnie #kod... remove all: #Opcjonalnie #kod... delete: #Opcjonalnie #kod... reset: #Opcjonalnie #kod... ! W return dajemy wartość którą ma zwrócić wyrażenie (tak jak w funkcji) ! ! Aby pobrać zmienianą wartość w set/add/remove należy wpisać change value ! ! Return type to typ zwracanej wartości ! ! przedrostek pluar określa zwracaną wartość jako pojedyńczą ! np: plural expression [AxTops] %player%['s] points: return type: number get: if {points::%expr-1%} is not set: return 0 return {points::%expr-1%} add: add change value to {points::%expr-1%} set: set {points::%expr-1%} to change value remove: remove change value from {points::%expr-1%} delete: delete {points::%expr-1%} reset: set {points::%expr-1%} to 0 Możemy to wykorzystać jako: command /points [<player>] [<text>] [<number>]: permission: * trigger: if arg 2 is "reset" or "clear": reset arg-1's points send "&7Zresetowanie" stop if arg 2 is "get": send "&7Gracz %arg 1% posiada &a%arg 1's points% &7punktow" stop if arg 3 is set: if arg 2 is "set": set AxTops arg 1's points to arg 3 send "&7Ustawiono punkty" if arg 2 is "add": add arg 3 to AxTops arg 1's points send "&7Dodano punkty" if arg 2 is "remove": remove arg 3 from AxTops arg 1's points send "&7Zabrano punkty" Wszystko razem Skript-reflect Jest to fork skript-mirrora który poprawia wiele rzeczy oraz dodaje np własne wydarzenia (eventy) Zdarzenia (Events) Definiujemy custom event "<nazwa>": pattern: <skladnia> event-values: <zmienne które można pobrać z eventu> check: #kod który wykona się przed wywołaniem eventu w skripcie continue ! Możemy stworzyć event który nie ma w sobie żadnych zmiennych, staczy że usuniemy event-values ! np: custom event "onPlayerBuy": pattern: buy event-values: player, number check: continue aby event zadziałał trzeba jeszcze go kiedyś wywoływać, od tego mamy efekt call event %event% Jednak musimy jeszcze jakoś pobrać event (jako typ) oraz podać mu argumenty które będzie można wykorzystać w evencie, od tego mamy expresje: new custom event %string% [using %objects%] aby podać zmienne które będziemy używać w evencie, musimy je najpierw zapisać do listy a potem podać w wyrażeniu Przykład z użyciem gracza oraz jakiejś liczby set {_list::player} to player set {_list::number} to arg-1 new custom event "onPlayerBuy" using {_list::*} No i brawo! Nasz event jest gotowy do nasłuchiwania Całość w przykładowej komendzie powinna wyglądać tak: #Rejestrujemy event custom event "onPlayerBuy": pattern: buy event-values: player, number check: continue command /kilof [<number>]: trigger: #jakis tam kod od kupowania #Podajemy argumenty oraz pobieramy event set {_list::player} to player set {_list::number} to arg-1 set {_event} to new custom event "onPlayerBuy" using {_list::*} #Wywołujemy event call event {_event} #Nasłuchujemy eventu on buy: send "&7Brawo! udalo ci sie cos kupic! za cene &6%event-number%" to event-player Dzięki za uwagę no i wszelkie błędy / pomysły proszę zgłaszać Pozdrawiam Aksik

Zawartość Minecrafta 1.14 każdy raczej już sobie prześledził, testował itd. Jednak niektórzy mylą 1.14 z 1.15 albo 1.15 z 1.17 itd. Co nas czeka w 1.15 BUZZY BEE UPDATE? Informacje Potwierdzone. 1.Bloki: a)Blok miodu b)Ul c) Wosk 2. Craftingi a) Ciemny pryzmaryn tworzymy (czarny barwnik na środku, 8 odłamków pryzmarynu dookoła) 3. Moby: a) Pszczoły w pobliżu Ula 4.Pozostałe: a) Miód b) Miód w butelkach c) Rusztowanie przepala 2 bloki d) Naprawienie błędu z Pigmanami 5.Drobne zmiany: a)Podświetlanie się przycisków w menu b) Wybuch TNT laguje o wiele MNIEJ c) O wiele SZYBSZE renderowanie terenu AKTUALIZACJA zostanie wydana 10 Grudnia 2019r. I będzie dotyczyła głównie Lasu.

Kup komende /afk już dziś! Tylko 100 złotych miesięcznie!

Zawsze działa, ale regulaminowo będzie zakazane. A czy wykrywanie nastąpi ręcznie czy za pomocą pluginu to się zobaczy.

A takie coś tu działa, czy nie?

command /itemcatch: trigger: set {drop::%Player%} to true on drop: if {drop::%Player%} is true: set {drop::%Player%} to false drop event-item named "antypickup" at player cancel event remove 1 of player's tool from player on pickup: if name of event-item is "antypickup": cancel event

Wy nie jesteście zleceniodawcami, wy jesteście nabijaczami postów, pozdrawiam :)

styl jest ładny nawet bardzo, ale można dostać jeszcze większej depresji niż na normlnym xD

Pragnienie będzie OK. Ale system wagi bardzo utrudnia rozgrywkę i jestem absolutnie przeciw. Pozostawiłbym jednak zmianę szybkości przy odpowiedniej nawierzchni (np. ścieżka/beton)

Moim zdaniem najlepszy będzie do tego JSON

Ostatnio przebywając na forum zaniepokoiła mnie jedna oferta. Nie wiem, czy Was również, ale chciałbym przedstawić Wam jej nieopłacalność. Oto oferta: Niby wszystko fajnie, ale do czasu, gdy się dowiadujemy, że skrypt za 10 zł lub za 3 zł to jest kilka linijek, do których nie trzeba praktycznie nic umieć. Przykładowy skrypt /dajrange [gracz] [ranga] command /dajrange [<player>] [<text>]: permission: rejszpat.dajrange permission message: &cbrak uprawnień trigger: execute console command "pex user %arg 1% group set %arg 2%" broadcast "Gracz %arg 1% otrzymał rangę %arg 2%" Bądźmy szczerzy, czy był on wart 10 złotych? Ja bym na Waszym miejscu za tyle nawet pluginu nie kupił! Kolejny skrypt. Nawet dłuższy od wcześniejszego, a cena jest niższa! Podejrzane. Przykładowy skrypt /helpop [treść] command /helpop [<text>]: permission: rejszpat.helpop.send permission message: &cbrak uprawnień trigger: if arg 1 is set: loop all players: if loop-player has permission "rejszpat.helpop.receive": send "&cHELPOP &7%arg 1%" to loop-player else: send "&ctreść jest pusta" to player Następna komenda. Przykładowy skrypt /stan konta A chwila, po co robić na to skrypt? Przecież mamy plik Commands.yml w głównym katalogu serwera. Możemy go uzupełnić np. tak: command-block-overrides: [] aliases: stankonta: - "money" Ale jak już tak bardzo chcemy zrobić to skryptem, to: command /stankonta: permission: rejszpat.stankonta permission message: &cbrak uprawnień trigger: send "Twój stan konta wynosi %player's money%" to player To jest kilka przykładów. Później może wstawię ich więcej.

aż wpadłem pomarudzić: Zacznę od tego że bazują na API bukkita i chcąc zrobić API które będzie możliwe do zaimplementowania potem wygodnie w sponge już zrypaliście cały projekt co podobny bład popełniłem bawiąc się z diorite. Jak widzicie jakieś rozwiązanie w bukkicie to na 90% jest to najgorsze z możliwych. I coś co kamilkime napisał gdzieś indziej: jak już ktoś dobrze ogarnia kotlina to po co mu taki plugin? wygodniej i wydajniej będzie zwyczajnie napisać plugin w kotlinie. Dodajecie masę narzutu swoją abstrakcją, bo abstrakcja niestety kosztuje, np każde pobranie graczy wymaga wrappowania ich w wasze obiekty, moglibyście takie wrappery cachować oczywiście, ale wtedy jak wszystko będziecie cachować to znowu sporo pamięci ucieknie. Podobnie pobierania gracza po nicku leci po pętli zamiast jakiś lookup mapą (no i gdzie po uuid? o.O, co to, 2010?) Reprezentowanie entity klasami to niestety też problem, mojang co chwile coś psuje i zmienia i odwraca entity do góry nogami, powstają potem koszmarki jak w bukkcie że albo dana rzecz nie jest wspierana bo devi uznali że pewnie i tak się zmieni, albo masz kilka metod od tego samego bo zmieniało się API, tutaj lepiej brać trochę przykład z sponge. Tutaj niestety zasada composition over inheritance się sprawdza, trudniej potem zrobić wygodne i szybkie API, ale tylko walcząc w ten sposób idzie zrobić coś co się nie popsuje w kolejnej wersji mc za mocno. Mając prosty system propertisów jest ten plus że można o danym ustawieniu zwyczajnie zapomnieć jeśli zostanie usunięte nie zasyfiając tak kodu, albo jak np dodadzą żę teraz każdy mob może się starzeć? musiecie zmieniać hierarchie wszystkich klas, tworzą się duplikaty metod itd. A mając tylko jakieś property: mob.set(Age, child) zmieniacie tylko wewnętrzną implementacje by od teraz nie ignorowała tej wartości dla wybranych modów. Dodatkowo korzystając z kotlina możecie dodawać klasy z extension methods które ludzie mogą importować dowolnie jak chcą i mieć dostępną metode mob.setAge kiedy chcą - co ułatwia użycie API nie wiążąc niczego z implementacją. A itemy tylko na stringach to też problem, a zrobienie BlockType na enum to już najgorsze co mogliście zrobić, enum z materialami to rzecz na którą każdy developer bukkita marudzi i mówi że to był największy bład jaki kiedykolwiek zrobili, na plus że rozdzieliliście tam jednak subid i wszystko jest na "płasko". Bloki się zmieniają a niektóre silniki wspierają mody i pluginy. Enumy powinny być do rzeczy niezmiennych, szczególnie projektując API. No i github jest lepszy do publicznych projektów bo ktoś go odwiedza A robienie tego closed source jest jeszcze bardziej bez sensu - no chyba że to tylko jakiś bład, ale wali 404.

po co komu zaśmiecać serwer pluginami.. w config.yml ustawiasz formatowanie czasu na HH:mm skrypt: every one minute: set {_now} to now if {_now} is 22:00: #kod