Ranking

Tak, ale tworzenie customowych bloków nie jest takie proste. Jeżeli chcesz w pełni imitujące nowe bloki potrzebujesz do tego resourcepacka i umiejętność robienia takowego. Przykładowym pluginem jest Oraxen, który wykorzystuje to, że noteblocki mają tonę typów ze względu na dźwięk. Problemem tego jest to, że należy zablokować używanie noteblocków w celu grania na nich. Jeżeli ogarniasz jave, możesz zajrzeć do kodu oraxena, powinno ci to ułatwić robienie customowych bloków w skrypcie. Natomiast jeżeli customowa tekstura nie jest ci tak bardzo potrzebna, to możesz zapisywać lokalizacje postawionego bloku jeżeli spełnia wymagania customowego i podmieniać drop podczas niszczenia (pamiętaj o usuwaniu zapisanej lokalizacji). Jeżeli chcesz to bardziej rozbudować to oprócz lokalizacji możesz zapisywać również twój customowy typ bloku, aby ułatwić szukanie dropu odpowiedniego dla twojego customowego bloku. Przykładowo: function findDrop(type: text) :: itemstack: if {_type} = "ruby_ore": return red dye named "Ruby" return {_none} on place of redstone ore: if name of player's tool = "Ruby Ore": set {customOre::%location of event-block%} to true set {customOre::%location of event-block%::type} to "ruby_ore" on mine of redstone ore: if {customOre::%location of event-block%} is set: clear drops clear {customOre::%location of event-block%} clear {customOre::%location of event-block%::type} drop findDrop({customOre::%location of event-block%::type}) Dawno skryptów nie pisałem, więc nie wiem czy zadziała, ale powinno

Zmienne tymczasowe to np {_cos::%player%}?

https://skripthub.net/tutorials/47 ^Tutaj masz tworzenie receptur do craftowania. Własną teksturę też powinno móc się zrobić, tylko trzeba się bawić bodajże z NBT tagami/datapackami. A jak chcesz zrobić custom drop to masz tutaj przykład: on place of coal ore: if name of player's tool is "&7Nowy blok": set {miejsce.%location of event-block%} to "nowy blok" on break of coal ore: if {miejsce.%location of event-block%} is "nowy blok": drop 5 coal named "&7Kozacki węgielek" Wygląd przedmiotów również zmieniasz przez nbt tagi/datapacki

Mógłbyś opróżnić skupy lub zrobić nieskończone skupy które by sie same opróżniały? Każdy skup jest pełny oprócz drewna i dużo graczy nie ma jak zarobić. Jak będą pełne skupy będzie dużo nieopłaconych nieruchomości, chyba, że ktoś ma dużo oszczędności na koncie. Gracze teraz mogą zarobić tylko na drewnie

Przydałoby się, aby cesarstwo wyłożyło pieniądze na infrastrukturę naszego miasta, budowę oraz odnowienie budynków miejskich (np. odnowienie białej galeria, budowę ratuszu). Z tego co wiem to jest kilku uzdolnionych obywateli, którzy chętnie wykonaliby projekt i budowę danych obiektów. Osobiście mogę wykonać projekt i przebudowę białej galerii, oczywiście po wcześniejszym zaakceptowaniu projektu. Czas pomyśleć o rozwoju miasta, w którym brak takich budynków jak ratusz, sąd itp.

O co chodzi? SSCC "Standard Skript Code Conventions" jest zestawem reguł pisania skryptów stworzonym przez destroyer'a4017. Określa on styl kodowania, który zapewnia kompatybilność z innymi skryptami, łatwość utrzymania/modyfikowania kodu oraz sprawia, że skrypt jest prosty do odczytania. Nazwy plików Nazwy plików kończących się na ".sk" nie powinny zawierać następujących znaków: # ` $ % { } (spacji) Jeśli w nazwie chcesz zawrzeć wersję skryptu powinna ona znaleźć się na końcu, za nazwą skryptu: skrewards-v1.2.3.sk Nazwy zmiennych Poniższe zasady odnoszą się tylko do zmiennych globalnych, nie do lokalnych (zaczynających się od _). Nazwy zmiennych powinny być zapisane według konwencji camelCase, gdzie nie występują spacje oraz pierwsza litera każdego słowa (wyłączając pierwsze) zaczyna się z wielkiej litery. Zmienne tworzone przez skrypt powinny być definiowane w sposób {<nazwa skryptu>::<nazwa zmiennej>}, co ułatwia usuwanie danych danego skryptu albo aktualizowanie zmiennych z wcześniejszej wersji skryptu, na przykład: # Zamiast takiej zmiennej {current.reward} # Użyj następującego wzoru {skrewards::currentReward} Zmienne dynamiczne oraz listy powinny być stopniowane, co jest bardziej obiektowym podejściem i umożliwia zapętlanie danych. # Zamiast takich zmiennych {reward.level.modifier.1} {reward.level.modifier.2} {reward.level.modifier.3} {rewardstatus.%player%} {info.%player%.mined.diamonds} {info.%player%.mined.emeralds} # Użyj następujących wzorów {skrewards::rewardLevelModifier::1} {skrewards::rewardLevelModifier::2} {skrewards::rewardLevelModifier:: 3} {skrewards::rewardStatus::%player%} {skrewards::info::%player%::minedDiamonds} {skrewards::info::%player%::minedEmeralds} # Lub {skrewards::info::%player%::mined::diamonds} {skrewards::info::%player%::mined::emeralds} Jeśli piszesz API, powinieneś wpisać dane do zarezerwowanych nazw zmiennych {<nazwa skryptu>::api::<output ID>}. Jeśli używasz skQuery, możesz zapisywać dane do tych zmiennych gdy podprogram/funkcja jest wykonywany/a. W zwykłym Skript powinieneś zdeklarować komendy możliwe do użycia tylko z konsoli, które wpisują dane do tych zmiennych. Schemat ten pozwala twórcom skryptów tworząc własny skrypt pozyskiwać informacje z innych. Jeśli Twój skrypt jest BIBLIOTEKĄ, której jedynym celem jest udostępnienie funkcji, należy wtedy pominąć fragment ::api i używać {<nazwa skryptu>::<output ID>}. Zmienne API powinny być usunięte zawsze gdy serwer jest wyłączany. Porządkowanie kodu Stworzony kod musi być uporządkowany w określony sposób. Nie powinieneś wpisywać zdarzeń i komend w losowej kolejności; muszą być czytelnie oddzielone. Każdy z elementów może być pominięty, o ile są one w odpowiedniej kolejności. script options (jeśli używasz skQuery) aliasy [aliases:] zmienne [variables:] opcje [options:] podprogramy/funkcje (jeśli używasz skQuery) nowe komendy [command /komenda:] on script load: on script unload: okresowe zdarzenia (np. every 10 seconds, at 10:00) inne zdarzenia Zdarzenia i Warunki Zdarzenia zawsze powinny zaczynać się od słówka "on", mimo, że będą działać bez niego. Kiedy tylko to możliwe, powinieneś unikać używania selektorów w linii definiującej zdarzenie, np.: on right click with porkchop: on left click on tnt: on damage of cow: Należy uogólnić takie zdarzenia i skorzystać z warunków: on right click: if tool of player is porkchop: # dalszy kod on left click: if clicked block is tnt: # dalszy kod on damage: if victim is a cow: # dalszy kod Stosując warunki, NIGDY nie powtórzysz tego samego zdarzenia kilka razy w jednym skrypcie. Warunki powinny ZAWSZE zaczynać się od słówka "if" i kończyć dwukropkiem. NIGDY nie używaj warunków bez wprowadzenia dalszego kodu do ich wnętrza. To pozwoli twórcom skryptów w łatwy sposób dodać kod przed i po warunku albo dodać "else:". # Zamiast on damage: if victim is a player: {skrewards::info::%victim%::isInvincible} is true cancel event set {skrewards::info::%victim%::isInvincible} to false # Użyj takich warunków on damage: if victim is a player: if {skrewards::info::%victim%::isInvincible} is true: cancel event set {skrewards::info::%victim%::isInvincible} to false Specyfikacja Lambdy Lambdy są nową funkcją skQuery i mogą być używane we wszystkich wersjach powyżej 1.17.0. Pozwalają sporą ilość kodu skompresować do kilku linii. Lambdy, tak długo jak długo będą używane rozsądnie, będą spełniać wymagania SSCC. Lambdy mogą być brane pod uwagę jeśli: [*]Użyte są zamiast funkcji do wykonania POJEDYNCZEGO zadania [*]Użyte są do zaciemnienia kodu przez stworzenie bardzo skompresowanego kodu [*]Lepiej opisują ciąg zadań - - - Jeśli stosujesz się do tych zasad, umieść w publikacji swojego skryptu plakietkę: Kod z linkiem do oryginalnego tematu: [url=http://dev.bukkit.org/bukkit-plugins/skript/forum/tutorials/69108/][img=https://i.imgur.com/BZ8lAno.png][/url] Kod z linkiem do tego tematu: [url=http://skript.pl/index.php/topic/1877-][img=https://i.imgur.com/BZ8lAno.png][/url] Źródło: http://dev.bukkit.org/bukkit-plugins/skript/forum/tutorials/69108

Wujek google znalazł w 30 sekund. on join: make player execute command "/hub"