Craftlin Alpha

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

A co to w ogóle jest?
Minecraft Kotlin czyli język skryptowy do Minecrafta oparty na znanym i lubianym Kotlinie. 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: http://craftlin.net/Craftlin.jar
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: https://try.kotlinlang.org/) oraz dokumentacja API (punkt wyjścia: http://craftlin.net/docs/net.craftlin.api/-variables/index.html). Możesz też zacząć od przykładów: http://craftlin.net/#examples

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: https://gitlab.com/Libter/Craftlin/issues (preferowany język angielski, ale po polsku też się nie obrażę)
• Albo tutaj: https://discord.gg/GMsBJ6b
• 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: http://craftlin.net/
Miłej zabawy!

Jestem pod wrażeniem!

Czekam tylko na czas gdy przebije to skript.

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!

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

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.

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: https://discord.gg/GMsBJ6b

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

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.

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

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

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ą 

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

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

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!

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

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

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.

Ten Craftlin jeszcze żyje?  

12 minut temu, Rejszpat napisał:

Ten Craftlin jeszcze żyje?  

Jakoś tam żyje. Alpha#4 wyszła ostatnio.

Z okazji zbliżających się świąt postawię świeczkę dla "Craftlina".

Umarł zanim powstał [*]

@JanekJaran Nikt tego nie będzie używał skoro można pluginy napisać i nie są ograniczone w porównaniu do tego syfu. Szkoda waszego czasu.

@Libter Była reklama witcher thronebreaker i klikłem w reklamę, więc profit 50/50 - dawaj moje 1,5 grosza.

3 godziny temu, xN0MANDx napisał:

Z okazji zbliżających się świąt postawię świeczkę dla "Craftlina".

Umarł zanim powstał [*]

PS: Strona robiona w wordpress'ie czy ręcznie pisana ?

Craftlin nie umarł, powoli powstaje, ostatni commit niecałe 20 godzin temu.

5 godzin temu, xN0MANDx napisał:

Z okazji zbliżających się świąt postawię świeczkę dla "Craftlina".

Umarł zanim powstał [*]

Wypraszam sobie, jeszcze nie umarł - nowe funkcjonalności dochodzą od czasu do czasu, a po naprawieniu pewnego buga w Kotlinie który blokuje dosyć ważne ulepszenie dla Craftlina będzie jeszcze fajniej.

5 godzin temu, xN0MANDx napisał:

@JanekJaran Nikt tego nie będzie używał skoro można pluginy napisać i nie są ograniczone w porównaniu do tego syfu. Szkoda waszego czasu.

Ale kto powiedział, że Craftlin jest ograniczony? Bukkit API też teoretycznie można używać, a ma po prostu znacznie fajniejszą składnię nadającą się do prostych zastosowań.

23 minuty temu, Libter napisał:

jeszcze

jeszcze  

23 minuty temu, Libter napisał:

A zanim zaczniesz coś wyzywać od syfu popatrz na swój nick i swoje serwery

Ile procent funkcjonalności Skripta jest już w Craftlinie, jeśli można oczywiście zapytać i jeśli w ogóle komuś chciało się liczyć?

6 godzin temu, xN0MANDx napisał:

Umarł zanim powstał [*]

@JanekJaran Nikt tego nie będzie używał skoro można pluginy napisać i nie są ograniczone w porównaniu do tego syfu. Szkoda waszego czasu.

Jak tam się trzyma twoja sieć 30 POTĘŻNYCH, NAJWIĘKSZYCH I NAJLEPSZYCH RPG W POLSCE z 3 online łącznie.

A tak na poważnie:

- Mało kto o tym usłyszy, a jak usłyszy to nie będzie rozumiał jak to pisać, a jeżeli będzie wiedział jak to i tak nie będzie używać bo będzie mógł napisać plugin. To nie ma przyszłości i praktycznego sensu użytkowania.

16 godzin temu, xN0MANDx napisał:

To nie ma przyszłości i praktycznego sensu użytkowania.

Jak można mylić siebie samego z profesjonalnym, porządnym i przydatnym projektem?