Ranking

Ja oddawać wam motyw pod forum mc. Mi się już średnio przyda, więc czemu by nie wrzucić gdzieś. Bazuje na domyślnym motywie mybb, zauważyłem że troche rzeczy nie wygląda jak trzeba po ostatnich update mybb jak np. edytor, którego ikonki wyglądają... średnio. Download(klik)

Dzięki działa ;D

Zawsze można function silnia1(i: integer) :: integer: if {_i} < 1: return 1 else: set {_x} to silnia2({_i}-1) return {_i} * {_x} function silnia2(i: integer) :: integer: if {_i} < 1: return 1 else: set {_x} to silnia1({_i}-1) return {_i} * {_x}

Wreszcie się zaczyna jakaś dyskusja Owszem, wymaga znajomości Kotlina ale próg wejścia jest znacznie niższy niż przy pisaniu pluginów ze względu na maksymalną prostotę API. Na chwilę obecną osoby które nie pisały nigdy w Kotlinie piszą craftlinowe skrypty na drop Zgadza się. Docelowo kompilator Kotlina ma pobierać się jednorazowo i aktualizować niezależnie od pluginu. Własny plugin nie jest wieloplatformowy i musi używać syfnego Bukkitowego API, a tu docelowo będzie rozbudowany framework dla skryptów w którym znacznie łatwiej będzie pisać mniejsze projekty. Dodatkowo skrypty można przeładowywać co znacznie przyspiesza prace, pozostaje tylko stworzenie wtyczki Craftlina do IntelliJ. No witam Generalnie jeśli nie podoba mi się coś z Bukkita to nie dodaję tego w takiej formie do API, liczy się prostota i odwzorowanie Minecrafta. Poza tym silniki Bukkitowe pozostają mimo wszystko najpopularniejsze, a pisanie na Sponge którego API uważam za słabo udokumentowane i nadmiernie skomplikowane (wszędobylskie Optionale chociażby) zdusiłoby projekt w zarodku. @Kamilkime odpowiedziałem wyżej. Zgodzę się do abstrakcji, jednak Bukkit sam w sobie jest abstrakcją i nie powoduje to rażącego spadku wydajności, ale na największe serwery pewnie Craftlin już się nie nada. Pobieranie gracza po nicku pójdzie do poprawki, a odnośnie UUIDów - to dopiero alpha, wiadomo że będą Hmm, w sumie zobaczę jak to jest rozwiązane w Sponge. Oparcie implementacji API na extension functions też w sumie może być dobrym pomysłem. Typy i bloków i przedmiotów są na stringach, gdybyś czytał dokumentację zamiast dekompilować kod to wiedziałbyś że enumy są tylko na użytek wewnętrzny żeby było wiadomo jakie bloki muszą uwzględniać implementacje Wiadomo że GitHub lepszy, ale taka już moja natura że musi być closed source No i przede wszystkim dzięki za zainteresowanie się projektem!

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.

Musisz nadać divowi, który ma być tłem mniejszy z-index niż ma div, który jest zawartością strony (domyśla wartość to 0) oraz nadać kilka atrybutów, aby to miało ręce i nogi: .background{ position: absolute; top: 0; left: 0; z-index: -1; } Musisz też przypisać klasę background temu divowi , który ma być tłem.

@xAxee, zapomniałeś o "}" Poprawiony kod: command /pay [<offlineplayer>] [<integer>]: trigger: if arg 2 is set: set {_pl} to arg 1 set {_p} to arg 2 if {money::%player%} >= {_p}: remove {_p} from {money:%player%} add {_p} to {money::{_pl}%} send "&6Przekazales %{_p}% graczowi %{_pl}%" else: send "&6Nie masz tyle &a&l$ &6%{money::%player%}% / %{_p)%" else: send "&6Poprawne uzycie: &c/pay gracz ilosc"

Cześć Dziś Pewien użytkownik Poprosił mnie o napisanie Skryptu Na CheckPointy Więc z nudów go napisałem i dodałem parę rzeczy Skrypt Polega na ustawieniu punktów a następnie obliczeniu odległości pomiędzy jednym a drugim punktem Bez Zbędnego gadania przechodzę do prezentacji Skryptu Komendy: /checkpoint - informacje o komendach skryptu /checkpoint set <Nazwa pkt> - Ustawia punkt /checkpoint list - Pokazuje ustawione punkty /checkpoint del <pkt> - Usuwa punkt /checkpoint wyznacz <pkt 1> <pkt 2> - wyznacza odległość To Do: - Dodanie gui z CheckPontami /// Zrobione - Poprawienie estetyki - Dodanie gui do teleportów Propozycje Użytkowników: - Dodanie configu yaml - Dodanie teleportacji do punktow /// Zrobione - Dodanie "poruszających się hologramów" SSy: Wersje: 1.5 - Dodanie gui pod /list, Dodanie teleportu miedzy punktami Gdy skrypt dojdzie do wersji 2.0 nie bedzie już wspierany i ulepszany! /// Wszelkie Opinie Wskazane

Proszę: Jak widać można zapisać to prościej

✯SkStatTrak✯ Co to za skrypt? SkStatTrak dodaje do naszego serwera StatTrak z gry Conter Strike Global Offensive. Do naszej broni/narzedzia możemy dodać licznik zabójstw, zabitych mobów albo wykopanych bloków. Features: - StatTrak w lore - Automatyczna aktualizacja skryptu po przez wpisanie /stattrak update - Wykrywanie nowej wersji Permissions: - stats.admin - Dostep do komendy /stattrak Komendy: - /stattrak give nick - - /stattrak update - - /stattrak reload - Screenshots: Download: Download