Kormic

Zwracam uwagę, że jest to dział Skrypty > Nauka. Proszę zapoznać się z regulaminem i nie umieszczać takich komentarzy. To, że Pan coś przekreśli, nie znaczy, że nie jest to brane pod uwagę. Niemniej jednak podpinam się pod uwagą Pana wyżej. Nie ma potrzeby definiowania argumentów jeśli nie są one nieużywane w dalszym kodzie. Wtedy również warunek sprawdzający argument stanie się całkowicie zbyteczny. Prawda, jest to najlepsze rozwiązanie. Jednak w myśl porzekadła "nie pamięta wół jak cielęciem był" proszę być bardziej wyrozumiałym.

Z początku rozum podpowiada, że Pana rozwiązanie z teleportacją gracza do innego gracza, który go zaatakował przed spadkiem w otchłań, nie powinno działać. Po chwili jednak doszedłem do wniosku, że jest możliwy dość specyficzny scenariusz, w którym Pana skrypt paradoksalnie działa. Otóż nie jest to jedyne miejsce (mowa o listenerze zdarzenia, w którym pojawiają się linijki takie jak na przykład "teleport victim to location of ({combat.attacker.%{_p}%} parsed as a player"), w którym Pan używa niezdefiniowanej wcześniej zmiennej {_p}. Użycie niezdefiniowanej zmiennej zawsze skutkuje zwróceniem wartości <none>, co niekoniecznie musi zwracać błąd. Tak więc istnieje szansa, że Pan ma zapisane zmienne o nazwach {combat.<none>}, {combat.attacker.<none>}, itd. Nie ma problemu z odwołaniem się do takiej zmiennej, co łatwo pokazać za pomocą przykładowego kodu poniżej. command /test: trigger: set {_zmienna::%{_p}%} to 1 # zmienna {_p} nie została nigdzie wcześniej zdefiniowana, a więc zwraca ona <none> broadcast "%{_zmienna::<none>}%" Z początku by się mogło wydawać, że powyższy kod nie zadziała, ale nic bardziej mylnego. Na czacie zostanie wyświetlona wartość "1". Co prawda ja odwołałem się bezpośrednio do <none> w zmiennej i Skript mnie ostrzegł o możliwym konflikcie nazewnictwa, ale w Pana przypadku niekoniecznie musi się tak dziać, gdyż Pan ponownie używa zmiennej {_p}. Tak więc Pan nie wprost pobiera wartość chociażby zmiennej {combat.<none>}, której wartość wcześniej została zapisana również przez użycie niezdefiniowanej zmiennej {_p}. Mam nadzieję, że wytłumaczyłem to jasno i klarownie. Pana skrypt może działać, ale działa on w sposób nieprzewidywalny i w wyniku tego, że dla wszystkich graczy mamy zmienną {combat.<none>}, w przypadku większej ilości walk między graczami działanie skryptu stanie się nieprzewidywalne, co może doprowadzić do dziwnych sytuacji (na przykład będą teleportowani inni gracze, którzy walczą w tym samym momencie).

Jak Pan chce sprawić, aby skrzynka pojawiła się w próżni/otchłani? Współrzędna Y bloków musi należeć do przedziału [-64;319], tak więc niemożliwym jest stawianie bloków poniżej dolnej granicy tego przedziału bez użycia odpowiednich modyfikacji na serwerze. EDIT: Pragnę dodać, że Pana skrypt jest napisany w sposób ignorujący dobre praktyki. Podam dwa moim zdaniem najważniejsze problemy z tym kodem. Zmienne gracza są zapisywane jako pojedyncze, niezależne zmienne, a nie listy, co jest złym rozwiązaniem. Jeśli Pan będzie miał potrzebę wyczyszczenia, bądź, co gorsza, zapętlenia listy, nie będzie to taka prosta w wykonaniu operacja. # Zła praktyka: set {combat.%player%} to true set {combat.attacker.%{_p}%} to victim # Dobra praktyka: set {combat::%player%} to true set {combat::attacker::%{_p}%} to victim # Dzięki takiemu zabiegowi jesteśmy w stanie łatwo manipulować tymi listami. Przykłady poniżej. clear {combat::*} clear {combat::attacker::*} loop {combat::*}: # ... Dodawanie dużych w opóźnień może być przyczyną późniejszych problemów w skrypcie. Moja uwaga się koncentruje na linijce "wait 30 seconds". Dlaczego może to generować problemy? Dlatego, że jeśli chociażby serwer przestanie działać w ciągu tych 30 sekund, dalsze instrukcje po tym opóźnieniu nigdy nie zostaną wykonane. Konsekwencją tego może być później znajdywanie na serwerze nieusuniętych skrzyń, które zostały postawione przez działanie ów skryptu. Na koniec dopowiem, że zauważyłem dziwną rzecz w Pana kodzie i zapewne jest to przyczyna braku działania kodu w przypadku wpadnięcia do otchłani. Mowa o linijce "if {combat.attacker.%{_p}%} isn't victim:" - nigdzie Pan nie zdefiniował wyżej w tym listenerze zdarzenia "on damage:" czym jest zmienna lokalna {_p}. EDIT: Dopatrzyłem się tego samego problemu na samym początku skryptu - w pierwszym listenerze zdarzenia "on damage:" odwołuje się Pan do zmiennej {_p}, która nie została jakkolwiek zdefiniowana.

Nie od razu Rzym zbudowano. Każda nauka wymaga praktyki i czasu, każdy tak zaczynał. Nikt na tym forum nie jest wyjątkiem od tej zasady, wliczając Pana. Niemniej jednak mogę pomóc w zrozumieniu jak należy skonstruować taki mechanizm cooldownu. Udostępniam przykładowy kod poniżej. function cooldownMessage(time: timespan, cooldown: timespan) :: text: set {_remainingTime} to "%difference between {_cooldown} and {_time}%" replace all ("minutes" and "minute") in {_remainingTime} with "m" replace all ("seconds" and "second") in {_remainingTime} with "s" replace all " and" in {_remainingTime} with "," return "Odczekaj %{_remainingTime}%." command /komenda: executable by: players trigger: if {cooldowns::komenda::%player%} is set: set {_cooldownTime} to 10 seconds set {_t} to difference between {cooldowns::komenda::%player%} and now if {_t} is less than {_cooldownTime}: send cooldownMessage({_t}, {_cooldownTime}) to player stop set {cooldowns::komenda::%player%} to now # Dalsza część kodu (kod w tym miejscu wykona się tylko wtedy, gdy gracz już nie ma cooldownu (lub nigdy go nie miał)) Wyjaśnię krok po kroku działanie powyższego skryptu. Czas wykonania komendy zapisujemy do zmiennej {cooldowns::komenda::%player%}. Może się ona całkowicie inaczej nazywać, ważne aby to była lista. Komenda ma narzucony warunek możliwego jej wykonania tylko przez graczy. Zapobiega to próbie użycia jej przez konsolę. W sekcji "trigger" komendy sprawdzamy czy zmienna ma ustawioną wartość - to znaczy czy gracz jej kiedykolwiek wcześniej użył. Jeśli nie, warunek nie jest spełniony, i przechodzimy do ostatniej linijki (a więc zapisujemy obecny czas do zmiennej gracza i wykonuje się dalszy kod komendy). Jeśli jednak warunek "if {cooldowns::komenda::%player%} is set:" jest spełniony (a więc gracz już kiedyś wcześniej użył komendy), sprawdzamy różnicę czasu między czasem obecnym a czasem w zmiennej gracza (to znaczy kiedy gracz ostatnio użył ów komendy). Warto zauważyć, że jest to czas od ostatniego użycia komendy. W przypadku gdy ta różnica czasu jest mniejsza niż nasz cooldown (w powyższym przykładzie jest to 10 sekund), wysyłamy graczowi informację ile musi odczekać, aby mógł ponownie wykonać komendę. Sama wiadomość jest tworzona przez naszą funkcję cooldownMessage([...]), która zwraca wiadomość o tym jak długo musi gracz czekać. Tak więc wywołujemy ją i po jej wywołaniu zatrzymujemy skrypt (instrukcja "stop"), aby reszta komendy się nie wykonała. Sama funkcja pobiera dwa argumenty - czas od ostatniego użycia komendy i czas cooldownu. Te dwie informacje wystarczą aby obliczyć czas pozostały do końca cooldownu (odpowiednik %remaining time%). Wynik różnicy tych czasów jest zapisywany jako tekst do zmiennej {_remainingTime}, aby można było na niej dokonać operacji zamiany pewnych fraz (na przykład "minutes" na "m"). Mając czas pozostały do oczekiwania na możliwość ponownego użycia komendy, zamieniamy "minutes", "seconds" i " and" odpowiednio na "m", "s" i " ,". Ostatnia operacja jest po to, aby zastąpić spójnik "and" przecinkiem. Finalnie, gdy już mamy sformatowaną zmienną {_remainingTime} według naszych potrzeb, zwracamy ją w funkcji, co pozwala wysłać wiadomość graczowi. Wydaje mi się, że wyjaśniłem to tak szczegółowo jak tylko potrafiłem. Niemniej jednak i tak zachęcam do lektury wcześniejszych artykułów - pomogą one Panu w nauce Skripta. W ramach Pana edukacji zostawiłem strukturę kodu tak prostą jak to tylko możliwe, aby mógł Pan samemu poeksperymentować i dodać to co jest potrzebne.

Proszę bardzo. Skrypt nie był testowany, więc w razie problemów proszę się zgłosić. Dodam jeszcze, że Pan złożył zlecenie na skrypt w złym dziale. Dział "Nauka" służy do umieszczania prostych skryptów będących owocem czyjejś nauki. command /radio <text>: executable by: players trigger: set {_radioNumber} to arg parsed as integer if {_radioNumber} is not set: if arg isn't "opusc": send "Użycie komendy: /radio <numer od 1 do 500>, /radio opusc" to player stop set {_number} to {radioChat::radioNumber::%player%} remove player from {radioChat::radioMembers::%{_number}%::*} clear {radioChat::radioNumber::%player%} send "Opuściłeś czat radia nr %{_number}%" to player stop if {_radioNumber} isn't between 1 and 500: send "Numer radia musi być liczbą między 1 a 500." to player stop add player to {radioChat::radioMembers::%{_radioNumber}%::*} set {radioChat::radioNumber::%player%} to {_radioNumber} send "Dołączyłeś do czatu radia nr %{_radioNumber}%." to player on chat: if {radioChat::radioNumber::%player%} isn't set: stop set {_radioNum} to {radioChat::radioNumber::%player%} set chat recipients to {radioChat::radioMembers::%{_radioNum}%::*}

Funkcja powinna być poza definicją komendy, nie w jej środku. Odsyłam do artykułów objaśniających jak używać funkcji w Skript. Przykładowy artykuł poniżej. Odnosząc się do Pana wcześniejszego pytania, ostatnio na forum pojawiło się podobne pytanie o przekształcenie tekstu wyświetlanego przez %remaining time%. Sam próbowałem wstawić wywołanie funkcji zmieniającej tekst tej zmiennej, jednak skutkowało to nadpisywaniem przez Skripta tej wiadomości jej domyślną wartością ("Sorry, you're using this command [...]" czy jakoś tak). Link do wcześniej wspomnianego wątku poniżej.

Implementacja takiego mechanizmu nie jest trudna, zresztą Pan ma już paradoksalnie lwią część wymaganego kodu. Wystarczy jedynie dodać kod jakiejś komendy, która zmieniałaby wartość zmiennej {autoMessage::%player%}. Udostępniam poniżej przykład komendy umożliwiającej przełączanie pojawiania się automatycznych wiadomości na czacie. command /toggleautomsg: executable by: players trigger: if {autoMessage::%player%} is true: set {autoMessage::%player%} to false send "Automatyczne wiadomości wyłączone." to player stop set {autoMessage::%player%} to true send "Automatyczne wiadomości włączone." to player Chciałbym zaznaczyć, że rozszerzanie tego wątku o kolejne pytanie miałoby sens tylko jeśli oba pytania dotyczyłyby tej samej sprawy. W tej sytuacji było to zbyteczne, gdyż przedstawił Pan dwa różne problemy. Wracając do meritum, w tym przypadku niemożliwym jest przetłumaczenie "seconds" na "sekundy". Dla potwierdzenia mojej tezy można spróbować wstawić do pola "cooldown message" wywołanie jakiejs funkcji tłumaczącej timespan %remaining time%. Jak więc można sobie z tym poradzić? Tutaj zalecam skonstruować samemu mechanizm cooldownu dla graczy - przykład poniżej. command /komenda: executable by: players trigger: if {cooldowns::komenda::%player%} is set: set {_t} to difference between {cooldowns::komenda::%player%} and now if {_t} is less than 1 minute: send cooldownMessage(player, {_t}) stop set {cooldowns::komenda::%player%} to now # dalszy kod Funkcja cooldownMessage mogłaby zwracać wiadomość o cooldownie dla gracza z przetłumaczonymi jednostkami czasu. Takie tłumaczenie można zrealizować za pomocą instrukcji "replace" - odsyłam do dokumentacji. Jeśli nie chce Pan samemu od podstaw tworzyć systemu cooldownów, polecam skrypt AxCooldown.

W mojej ocenie Pana kod nie powinien wpłynąć w większym stopniu na wydajność pracy serwera (można utożsamiać z licznikiem TPS (ticks per second)). Niemniej jednak stwierdzam, że takie podejście jest skrajnie niewydajne, ponieważ przy dodaniu każdej kolejnej rangi, którą gracz może posiadać, wymaga to dodania kolejnego zagnieżdżonego warunku, co jest zabójcze dla czytelności kodu, a więc i jego dalszego rozwoju. Co prawda Pan wykonał krok w dobrą stronę dodając tę drobną optymalizację do kodu, lecz jest ona zdecydowanie niewystarczająca. Wracając do istoty sprawy - sugeruję utworzenie dwóch list, w których będzie Pan zapisywał nazwy permisji oraz wiadomości witające/żegnające graczy, a następnie zapętlał je. Poniżej udostępniam kod, który prezentuje w jaki sposób podjąłbym się napisania takiego skryptu. function joinLeaveMessage(p: player, join: boolean): set {_permissions::*} to "uvip", "svip", "vip" set {_messages::*} to "UVIP", "SVIP", "VIP" loop {_permissions::*}: if {_p} doesn't have permission "%loop-value%.wiadomosc": continue if {_p} has permission "*" or "join.wiadomosc": stop if {_join} is true: send "%{_messages::%loop-index%}% +" to all players stop send "%{_messages::%loop-index%}% -" to all players stop on join: joinLeaveMessage(player, true) on quit: joinLeaveMessage(player, false) Wart odnotowania jest fakt, iż rangi zapisałem do listy malejąco według ich priorytetu na serwerze. Zabieg ten ma na celu obsłużenie wyjątku, w którym gracz posiada więcej niż jedną permisję - wtedy skrypt wybierze permisję o wyższym priorytecie. Instrukcje "stop" w funkcji są po to, aby skrypt nie próbował wysyłać więcej wiadomości w przypadku gdy gracz ma co najmniej dwie rangi. Rzecz jasna, samą funkcję napisałem w celu skrócenia kodu. Na koniec chciałbym zaznaczyć, że nie sprawdziłem poprawności działania skryptu, gdyż to nie jest to dział zleceń. Mój kod ma jedynie na celu pokazanie pewnej idei, podejścia do problemu.

Wedle mojej wiedzy nie ma takich kursów, a nawet jeśli są, nie uzyskały one wielkiego rozgłosu. Korzystania z Bukkit API (de facto rdzeniu wszystkich innych API silników serwerów) w mojej ocenie najłatwiej jest nauczyć się poprzez oglądanie poradników na YouTube i przeglądanie poszczególnych artykułów na różnych forach (na forum skript.pl również kilkukrotnie padało Pana pytanie, więc gorąco zachęcam do przejrzenia pozostałych wątków). W szczególności pierwsza opcja jest bogata w wiedzę, ale jak to w Internecie - należy do wszystkiego podchodzić ze zdrową dozą sceptycyzmu, ponieważ we wcześniej wspomnianych poradnikach niejednokrotnie można uświadczyć złe praktyki. Tutaj dodam, że jeśli Pan będzie miał wątpliwości, warto w takiej sytuacji zadać tutaj pytanie na forum. Z pewnością przyjdzie z pomocą ktoś, kto zna się na rzeczy. Jeśli o mnie chodzi, ja korzystałem głównie z tych rzeczy, o których wspomniałem wyżej. Jedyne co mogę dodać to to, aby w ramach każdego artykułu i poradnika starać się wychodzić poza ich ramy - próbować nowych rzeczy, zadawać sobie pytania z gatunku "A co jeśli tak zrobię?". Naturalnie, na ~90% z tych pytań może Pan sobie samemu odpowiedzieć. Innymi słowy, jak to przy nauce każdego języka programowania, bądź technologii, klucz to praktykować na własną rękę, nie bać się eksperymentowania i w razie pytań najpierw samemu się zastanowić nad problemem, a dopiero gdy nie jest Pan w stanie sobie na nie odpowiedzieć, poprosić o pomoc kogoś bardziej doświadczonego.

Będąc szczerym, nie miałem świadomości o istnieniu takiego konkursu, jednak nie to jest najważniejsze. Podoba mi się Pana pomysł dodania powiewu świeżości do najbardziej podstawowych elementów Minecrafta. Jeśli miałbym podać jedną rzecz, która mogłaby się znaleźć w tej modyfikacji, byłyby to prawdopodobnie struktury generowane na mapie. Co prawda Microsoft ostatnimi czasy stara się nad rozwojem w tym kierunku, jednak zawsze mi brakowało jakichś mniejszych, a i bardziej tajemniczych struktur. Podam dwa pomysły w tej kwestii: ruiny domów/wiosek, a może i na przykład jakichś wież zamkowych, opuszczone niewielkie grobowce, w których będziemy znajdywali bronie oraz elementy zbroi, które mogą być własnością pochowanych tam osób, a po ich wzięciu będzie się pojawiała grupa zombie i szkieletów. Myślę, że jest to dobra propozycja, gdyż pomysłów na struktury jest nieskończenie wiele, więc można to rozbić na kilka commitów i tym samym pomóc sobie przy tym konkursie. Jedyny minus jest taki, że jeśli Pan nie posiada zmysłu artystycznego, trzeba będzie w tym celu znaleźć kogoś chętnego do budowy. Powodzenia w konkursie, wszystkiego dobrego.

Istnieje możliwość stworzenia systemu logowania poprzez wpisywanie hasła na czacie jako zwykłej wiadomości (a więc zdarzenie "on chat"). Wtedy byłbyś w stanie przechwytywać wiadomość wysłaną przez użytkownika, a jednocześnie anulować wysłanie jej na czacie, co nie powodowałoby pokazywania się ów wiadomości w konsoli. Oczywiście w grę również wchodziłoby hashowanie haseł (dla przykładu za pomocą wbudowanego wyrażenia w Skript), co jest zapewnieniem absolutnego minimum bezpieczeństwa. Zależy nam na bezpieczeństwie, dlatego zalecam zrezygnowanie z użycia algorytmu MD5 na rzecz algorytmu SHA-256. Chciałbym zaznaczyć, że odradzam tworzenia systemów logowania w Skript do użytku na większych serwerach poza sytuacją, w której to taki skrypt tworzysz na potrzeby jakiegoś kameralnego serwera, bądź dla własnej praktyki. Jak Pan wyżej napisał, najlepiej zainstalować ściśle do tego celu przeznaczony plugin, którego twórcy dokładają wszelkich starań, aby utrzymać najwyższy standard bezpieczeństwa. Kończąc mój wywód, podsyłam w linku idealny przykład dydaktyczny pokazujący jak NIE należy tworzyć systemów logowania: https://www.spigotmc.org/resources/login-skript-1-16.93729/. Problemem rzecz jasna jest zapisywanie haseł w formie zwykłego tekstu, a nie hashów, co jest stąpaniem po cienkim lodzie i proszeniem losu o wyciek bazy haseł.

Zawsze możesz sobie zrobić takiego case'a prostym szeregiem 'else if'. To prawda, tego to każdemu brakowało (i pewnie nadal brakuje). Niestety z operatorem || trzeba to załatwiać w ten sposób: if arg-1 is 1: set {_t} to true if arg-2 is 2: set {_t} to true {_t} is set # Dalszy kod Z operatorem && sprawa wygląda dość podobnie, ale należy przed warunkami ustawiać jakąś zmienną na true, a jeżeli któryś z warunków jest niezgodny, wykonujemy 'stop', aby zatrzymać kod.

Nie, nie będę ci niczego pisał. Musisz się samemu nauczyć. Musisz sprawdzić ten twój enchant w event-item, czy go posiada. Warunek masz w poradniku jak na tacy.

Niestety kolega nie sprecyzował na czym polega problem, więc możemy jedynie się domyślać co tak właściwie jest przyczyną jego dalszych zmagań z tym skryptem. Odnosząc się do Twojej uwagi, indeks w tym przypadku nie gra żadnej roli. Indeksowanie argumentów komend jest jedynie konieczne w sytuacji gdy nasza komenda zawiera więcej niż jeden argument. Pozwolę sobie to zademonstrować przy użyciu poniższego kodu. command /broadcast <string>: usage: A command for broadcasting a message to all players. permission: skript.command.broadcast permission message: You don't have permission to broadcast messages aliases: /bc executable by: players and console cooldown: 15 seconds cooldown message: You last broadcast a message %elapsed time% ago. You can broadcast another message in %remaining time%. cooldown bypass: skript.command.broadcast.admin cooldown storage: {cooldown::%player%} trigger: broadcast the argument Przykład zaczerpnięty z dokumentacji Skripta.

Warto byłoby je pokazać. Zakładam, że to są 'indentation error' (błędy wcięć w kodzie).

1. Użyj 'if victim is a player', a najlepiej to wywal ten warunek i użyj 'on damage of player'. 2. Powinieneś sprawdzać czy 'attacker is a player', abyś wiedział czy atakujący to w ogóle gracz. 3. W eventach 'on damage' i 'on death' używamy 'victim' (ofiara) oraz 'attacker' (atakujący). 4. Usuń tego 'victim' z procentów przy efekcie 'kill'. 5. Używaj list zmiennych, są one o wiele lepsze. Wystarczy poszukać na forum, wielokrotnie o tym pisałem. EDIT: Warto wstawić te dzielenie w nawias, aby ułatwić Skriptowi robotę przy przeładowywaniu skryptu.

Tak, możesz.

Kormic wygląda to na reklamę serwera, który miałby za niedługo powstać. John jednak chciałby się najpierw dowiedzieć czy ktokolwiek byłby zainteresowany tego typu serwerem i co by mógł zmienić/poprawić.

Co do pluginów to masz Launchpad i Launchpad Plus.

W takim razie proszę. on inventory click: if inventory name of current inventory of player is "&2test": cancel event event-slot is not cake named "&akliknij": kick player due to "&cNie kliknales w odpowiedni slot!" stop set {_i::*} to iron ingot named "&7Żelazo" and diamond named "&bDiament" give player (random item out of {_i::*})

Proszę. on right click on cake: set {_i::*} to iron ingot named "&7Żelazo" and diamond named "&bDiament" give player (random item out of {_i::*})

Skript może to zinterpretować jako odejmowanie, już były takie błędy i ludzie je zgłaszali do twórców Skripta.

W przypadku argumentów typu 'number' i 'integer' używamy 'arg [numer]', a nie 'arg-[numer]'. Tak więc jeżeli już bawimy się w podrzucanie gotowego kodu, upośledzanie użytkowników i pozbawianie ich samodzielności... command /dajlisc [<integer>]: cooldown: 5 second permission: give.lisc trigger: (arg 1) is not set: send subtitle "&c&lPodaj ilosc" to player stop give (arg 1) of kelp named "&c&l&kffff &5&lMagiczny lisc &c&l&kffff " with lore "&c&l&kffff &f&lWymien lisc u vilaggera na spawnie &c&l&kffff" to player

Co prawda zaburzy to lekko szanse procentowe u ciebie, ale proszę. on right click on ender chest: block under event-block is bedrock cancel event open chest inventory with 1 row named "&6Skrzynki" to player set slot 0 of player's current inventory to chest named "&7&lZwykla" set slot 2 of player's current inventory to chest named "&a&lPospolita" set slot 4 of player's current inventory to chest named "&b&lRzadka" set slot 6 of player's current inventory to chest named "&5&lEpicka" set slot 8 of player's current inventory to chest named "&6&lLegendarna" on inventory click: inventory name of current inventory of player is "&6Skrzynki" clicked inventory is not player's inventory if clicked slot is 0: cancel event if player doesn't have 1 tripwire hook named "&7&lZwykly Klucz": cancel event wait 0.2 seconds send player title "&4&lBLAD" with subtitle "&cNie masz klucza!" close player's inventory stop remove 1 tripwire hook named "&7&lZwykly Klucz" from player's inventory if chance of 80%: give 6 obsidian to player broadcast "&6%player% &7wylosowal: &6Obsydian (x6)" else if chance of 70%: give 32 brick block to player broadcast "&6%player% &7wylosowal: &6Cegly (x32)" else: give 16 apple to player broadcast "&6%player% &7wylosowal: &6Jablko (x16)"

Ponieważ dałeś to w procenty. Mimo wszystko to nie zadziała. Po prostu usuń te '%arg 1%'.