Skocz do zawartości
Libter

Craftlin Alpha

Rekomendowane odpowiedzi

Właściciel

Po ponad miesiącu niezwykle wytężonej (:kappa:) pracy naszego zespołu programistycznego w składzie @Libter, @Reedzev_, @Ixidi mam przyjemność zaprezentować wam Projekt Craftlin.

JOSXYzq.png

A co to w ogóle jest?
Minecraft Kotlin czyli język skryptowy do Minecrafta oparty na znanym i lubianym Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!. Już sam ten fakt czyni go z założenia lepszym językiem niż Skript (oczywiście na razie ma mniej funkcjonalności, ale to kwestia czasu), a dodatkowo posiada proste, zwięzłe i funkcjonalne API oraz możliwość rozwoju w kierunku wieloplatformowości - wyobraź sobie te same skrypty na Bukkicie i Sponge!

No dobra, ale jak tego używać?

  1. Pobierz: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
  2. Wstaw do katalogu plugins i zrestartuj serwer
  3. Utwórz skrypt z rozszerzeniem .cl w katalogu scripts (utworzy się sam po restarcie)
  4. Wykonaj komendę /craftlin reload
  5. Profit!

Oczywiście do skryptowania przyda się znajomość Kotlina (nauczysz się go tutaj: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!) oraz dokumentacja API (punkt wyjścia: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!). Możesz też zacząć od przykładów: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!

Zanim wpadniesz w wir kodowania pamiętaj jednak, że to dopiero alpha. Do pełnego wydania API może zmienić się jeszcze 100 razy, a sam plugin nie nadaje się do użycia na produkcji.

Znalazłem błąd!

Spokojnie, to dopiero alpha, więc błędów powinno być od groma :>

  • Najlepiej zgłoś go tutaj: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść! (preferowany język angielski, ale po polsku też się nie obrażę)
  • Albo tutaj: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
  • Albo w tym dziale. W tych samych miejscach możesz zgłaszać także swoje sugestie!

Pamiętaj, żeby dokładnie opisać okoliczności jego powstania oraz załączyć zawartość katalogu scripts/errors (jeśli istnieje) lub log konsoli.

Super projekt! Jak mogę pomóc?

Jest wiele możliwości, ale na początku dołącz na Discorda (link powyżej) :) Następnie możesz:

  • Po prostu bawić się pluginem, pisać skrypty i zgłaszać błędy oraz sugestie.
  • Zostać testerem - jeśli jesteś dyspozycyjny i masz przynajmniej pół godziny czasu codziennie zapraszamy!
  • Zostać potężnym developerem - jeśli znasz Kotlina lub przynajmniej Javę, masz przynajmniej pięć wolnych godzin w tygodniu, a przy okazji jesteś osobą godną zaufania i potrafisz tworzyć piękne rozwiązania zamiast klepać kod zapraszamy jeszcze bardziej gorąco!

A na koniec link do strony: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!
Miłej zabawy!

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Użytkownik
1 godzinę temu, MrJuliusz napisał:

Jestem pod wrażeniem!

Czekam tylko na czas gdy przebije to skript.

Pewnie nigdy, bo 12 letnie marki nie zrozumieją składki, która jest trudniejsza od Skriptowej, ale również na to czekam!

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Właściciel
1 godzinę temu, MrJuliusz napisał:

@Libter Czy zamierzasz wprowadzić osobne forum do waszego języka czy będzie jakiś pod-dział dedykowany do craftlin?

Projekt nie jest ograniczony do terytorium Polski także docelowo powstanie craftlin.net/forum. Natomiast obecny dział prawdopodobnie zostanie w charakterze wsparcia w języku polskim.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Właściciel

Obecnie trwają testy wersji Alpha#2 z naprawionymi błędami oraz wsparciem dla tworzenia lokalizacji, spawnu mobów i dropu przedmiotów. Chętnych zapraszam na Discorda: Zarejestruj się lub zaloguj, aby zobaczyć ukrytą treść!

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Użytkownik

Sam pomysł bardzo fajny, ale... ze Skriptem bym tego nie porównywał - wasz projekt to po prostu takie prostsze pisanie pluginu w kotlinie, a Skript to jednak pisanie pluginu zdaniami po angielsku, które wymaga minimum pojęcia programistycznego, a wasz język wymaga jednak znajomości kotlina. Tak więc pomysł fajny, chętnie zobaczę jak się to będzie rozwijać, ale moim zdaniem nazywanie tego lepszym Skriptem jest nietrafione :/

Poza tym - rozmiar pliku .jar jednak trochę duży, 31 MB, wiem że kotlin musi swoje ważyć, no ale jednak trochę do dużo jak na plugin do MC

//edit
W sumie, tak po dłuższym zastanowieniu - jeśli ktoś umie kotlina i umie pisać skrypty do waszego pluginu, to już praktycznie umie napisać sobie własny, niezależny plugin, bo raczej takim skryptem ludzie i tak robią jakieś mniejsze rzeczy. Więc pomysł fajny, ale nie wiem czy zastosowanie by miał w praktyce

Edytowane przez Kamilkime

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Użytkownik

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.

 

Edytowane przez GotoFinal

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Właściciel

Wreszcie się zaczyna jakaś dyskusja :>

1 godzinę temu, Kamilkime napisał:

Sam pomysł bardzo fajny, ale... ze Skriptem bym tego nie porównywał - wasz projekt to po prostu takie prostsze pisanie pluginu w kotlinie, a Skript to jednak pisanie pluginu zdaniami po angielsku, które wymaga minimum pojęcia programistycznego, a wasz język wymaga jednak znajomości kotlina. Tak więc pomysł fajny, chętnie zobaczę jak się to będzie rozwijać, ale moim zdaniem nazywanie tego lepszym Skriptem jest nietrafione

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 :ancom:

1 godzinę temu, Kamilkime napisał:

Poza tym - rozmiar pliku .jar jednak trochę duży, 31 MB, wiem że kotlin musi swoje ważyć, no ale jednak trochę do dużo jak na plugin do MC

Zgadza się. Docelowo kompilator Kotlina ma pobierać się jednorazowo i aktualizować niezależnie od pluginu.

1 godzinę temu, Kamilkime napisał:

W sumie, tak po dłuższym zastanowieniu - jeśli ktoś umie kotlina i umie pisać skrypty do waszego pluginu, to już praktycznie umie napisać sobie własny, niezależny plugin, bo raczej takim skryptem ludzie i tak robią jakieś mniejsze rzeczy. Więc pomysł fajny, ale nie wiem czy zastosowanie by miał w praktyce

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.


53 minuty temu, GotoFinal napisał:

aż wpadłem pomarudzić:

No witam :bankappa:

54 minuty temu, GotoFinal napisał:

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.

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.

Godzinę temu, GotoFinal napisał:

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?)

@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ą :P

56 minut temu, GotoFinal napisał:

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. 

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.

Godzinę temu, GotoFinal napisał:

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. 

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 :>

Godzinę temu, GotoFinal napisał:

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.

Wiadomo że GitHub lepszy, ale taka już moja natura że musi być closed source :ancap: No i przede wszystkim dzięki za zainteresowanie się projektem!

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Użytkownik
19 godzin temu, Libter napisał:

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 :ancom:

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 :bankappa:

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ą :P

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 :ancap: No i przede wszystkim dzięki za zainteresowanie się projektem!

też średnio lubie API sponga, ale jednak entity czy bloki mają dobrze zrobione, trochę tylko zmienić by jednak pozbyć się nadmiaru pierniczenia z tym. Typy tylko na strigach to też jak napisałem beznadziejny pomysł w API bo ani to wygodne ani bezpieczne.

Bukkit nie jest takim typem abstrakcji, tylko większość obiektów cały czas gdzieś żyje i bukkit to ogarnia by nie tworzyć ich za dużo i za często.

I własny plugin jak najbardziej może być wieloplatformowy, a robiąc API pod wiele platform powinniście od razu pisać nad przynajmniej dwa, nie po to by było, ale po to by zobaczyć jak wiele jest różnić i że z waszymi rozwiązaniami nie będziecie w stanie tego dobrze wspierać. + możliwości, na każdym silniku są inne, nie każdy wspiera wszystkie featury, gdzie bukkit jest chyba najniżej i wspiera najmniej.

A closed source często ubija takie projekty, bo mała szansa że ktoś będzie chciał to dalej rozwijać i pomagać, a to tylko mały kawałek dupnego kodu, nie ma co go chować.

A skrypowych libek pod bukkita też jest sporo i to na różne języki, jak też np groovy - zdecydowanie ciekawszy pod szybkie skrypty, co prawda niby nie są pisane pod wieloplatformowość, ale wasza wieloplatformowość i tak nie istnieje i jest tylko pustym sloganem ;)

 

Pisze to jako osoba co robiła podobne API chcąc stworzyć diorite i poległa bo 2 wersje minecrafta potem 90% była już nieaktualna i tak właściwe legacy. A wy napisaliście legacy już od razu. Bukkit kompletnie nie odwzorowuje aktualnego wyglądu minecrafta, to jedna wielka paczka legacy dająca ci możliwości minecrafta beta ale pod najnowszą wersją MC :D

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Właściciel
4 godziny temu, GotoFinal napisał:

Typy tylko na strigach to też jak napisałem beznadziejny pomysł w API bo ani to wygodne ani bezpieczne.

Wygodne: prosta serializacja, prosty odczyt/zapis bez importów. Bezpieczne oczywiście mniej, ale dzięki abstrakcji zmiany w MC nie muszą oznaczać zmian w API (tak wiem, skończymy jak Bukkit Material z nazwami bez ładu i składu, ale do pełnego wydania jeszcze sporo może się zmienić :V).

4 godziny temu, GotoFinal napisał:

Bukkit nie jest takim typem abstrakcji, tylko większość obiektów cały czas gdzieś żyje i bukkit to ogarnia by nie tworzyć ich za dużo i za często.

Jak będzie potrzeba to Craftlina też można optymalizować.

4 godziny temu, GotoFinal napisał:

A closed source często ubija takie projekty, bo mała szansa że ktoś będzie chciał to dalej rozwijać i pomagać, a to tylko mały kawałek dupnego kodu, nie ma co go chować.

Projekty open source też często leżą martwe albo wolno się rozwijają także bez różnicy IMO. I proszę nie obrażać kodu :bankappa:, może spiesząc się do alphy nie wszystko jest najlepiej rozwiązane, ale staraliśmy się żeby było.

4 godziny temu, GotoFinal napisał:

skrypowych libek pod bukkita też jest sporo i to na różne języki, jak też np groovy - zdecydowanie ciekawszy pod szybkie skrypty, co prawda niby nie są pisane pod wieloplatformowość, ale wasza wieloplatformowość i tak nie istnieje i jest tylko pustym sloganem ;)

A te libki mają API czy składają się z dwóch klas do ładowania interpretera? Bo brzydko zaprojektowane Bukkit API kompletnie nie nadaje się do skryptów (do pluginów też zresztą słabo i jak nie zacznie się szybko tworzyć własnej abstrakcji to dopiero widać dupny kod, ale to inny temat). Co do wieloplatformowości zgodzę się - na razie to tylko slogan, ale zakładam że warstwa abstrakcji pozwoli na podłączenie się pod inne API (a przynajmniej nie widzę na razie niczego co by mogło w tym przeszkodzić).

4 godziny temu, GotoFinal napisał:

Pisze to jako osoba co robiła podobne API chcąc stworzyć diorite i poległa bo 2 wersje minecrafta potem 90% była już nieaktualna i tak właściwe legacy. A wy napisaliście legacy już od razu. Bukkit kompletnie nie odwzorowuje aktualnego wyglądu minecrafta, to jedna wielka paczka legacy dająca ci możliwości minecrafta beta ale pod najnowszą wersją MC :D

A mówiłem żeby robić Diorite jako silnik minimum, a nie kopiować vanillę... :> Owszem, możliwe że bazowanie na Bukkicie jest błędem, ale mimo wszystko nadal jest to najpopularniejsze API z największą liczbą developerów i nawet glowstone bazuje na nim zamiast robić własne. Także do gąbczastych czy innych silników mnie na razie nie przekonasz, bo po prostu nie ma popytu na nie.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników przeglądających tę stronę.

×