К сожалению (или к счастью) разрабы Create перестали поддерживать версию майна 1.20.1

В связи с этим я подумал стоит перехать на 1.21.1
Так мод ещё в разработке и ещё не скоро релизнется, то мне нет смысла писать на текущие версии )

Решил попробовать сделать проект сразу под несколько версий minecraft(на будущее), а потом и под несколько модлоадеров, хотя сейчас уже их 2, потому что большинство модов для 1.21.1 уже чисто на NeoForge, а в 1.20.1 остался Forge

Пока особо разработка фич в моде не продвигается, я всё ещё в процессе оптимизации архитектуры проекта, под minecraft-agnostic подход. Я не хочу завязываться на Api minecraft, так как оно жесть как дрейфует с каждым дропом, но и поддерживать несколько копий кодовых баз тоже не хочется. я вынес всю несвязную с майном логику и на мой взгляд ещё куча осталась в version модулях

Разработка продолжается, я выстроил структуру мода, чётко разделив код на 3 слоя - core, common и loader-leaf, что позволяет писать мод одновременно под разные версии и разные модлоадеры, что я считаю огромным преимуществом по сравнению с ветками или stonecutter.

В случае с ветками придётся их руками поддерживать, резолвить конфликты и как-то следить чтобы общий код(разбросанный по всем сурсам) не расходился между ветками, что я считаю большой запарой. Ну и тестировать разумеется сложнее будет так как надо будет постоянно между ветками переключаться

В случае со stonecutter у тебя попросту меньше гибкости и ровно такая же проблема тестируемости и консистентности между версиями. Придётся свапаться между версиями или лоадерами с такой же частотой. Как и в случае с многомодульной структурой с общим кодом придётся также заморачиваться над архитектурой и разделением ответственности, иначе код будет всё сложнее поддерживать из-за
дрейфов api майна.

Но и у моего подхода есть свои минусы:
1. Дублирование кода только из-за разных версий зависимостей, придётся поддерживать и обновлять копии.
2. Сложная архитектура - надо стараться по максимуму абстрагироваться от кода minecraft, чтобы испытывать как можно меньше боли при поддержке, копировании, портировании

Я принял эти минусы и считаю что мой поход лучше. Мне субьективно не нравится подход с препроцессингом.

Сейчас занят в основном ui/ux, продумываю систему периферии и занимаюсь выделением IDE в отдельную сущность, а из компьютеров я её удалю, она не вписывается в компах совсем. Я считаю IDE должна быть отделена от исполняющей сущности.

Хотя я и реализовал довольно сложную архитектуру, разрабатываю я сейчас только под одну версию и под один лоадер )))))))

Мне кажется будет супер забавно

Придумал ещё штуку: в компьютерном столе можно будет совместно разрабатывать код и наблюдать за разработкой другого, я считаю это очень крутая фича

Нарисовал я свои текстурки, рисовать я не умею, что получилось то получилось, мне нравится в целом)

Слева - Workbench
Справа - обычный комп

Вот что поделать....

Это последствия дрейфа между дропами майна.

Я часа 4 потратил чтобы разобраться почему не дропается item.

Нейронка потратила полчаса рыская по jar-никам и исходникам NeoForge...

А всё почему, потому что blocks остались как blocks. Но loot_tables почему-то надо было переименовать в loot_table.

И самое главное я знал что такое изменение было, но подумал что это лут таблиц не коснулось, так как там blocks.

Разработка активно продолжается, но пока я всё ещё не могу выложить мод в открытый доступ, даже для тестов, потому что толком основной usecase не покрыт увы.

Коротко что было сделано:
1. Добавил runtime gametesting и подтянул тесты, чтобы дальше развивать систему без регрессий.

2. Я собрал новую screen-first/compiled UI-архитектуру: declarative DSL, layout-контейнеры, modifiers, цветовую модель, измерение текста и базовые примитивы рендера - В итоге получился Jetpack Compose like DSL, но без его жирного рантайма и магических преобразований. По сути я сделал минимальный рантайм, все статичные элементы просто складываются в список и потом уже при отрисевке просто рисуется весь список элементов сплошняком, без динамических перерасчётов каждый кадр. Разумеется динамика есть, например ветвления, тултипы, popups, это приходится пересобирать, но не каждый кадр, а только когда состояние меняется. Досиг минимум overhead и максимум читаемости кода, пушто я задолбался смотреть на рисование прямоугольников с магическими числами.

Сейчас в процессе переноса всех своих UI экранов на новый DSL.

3. Перевел terminal/runtime на stream I/O и VT-последовательности, добавил terminal session model, scrollback, shared-session broadcaster и portable terminal item с 3D-моделью и отдельными текстурами. Теперь клиентский терминал связывается с сервером только посредством STDOUT и STDIN, что существенно снижает кол-во передаваемых данных, по сути довольно близко к Unix философии и SSH подобному взаимодействию

Сейчас хочу стабилизировать эти фичи и наконецто выложить первую версию для 1.21.1

А, да, теперь терминал это отдельный item

При нажатии ПКМ по компу, он к нему прикрепляется и с компом можно взаимодействовать. У терминала есть радиус действия, так что из жопы мира к компу не подлкючится.

С начала порта на 1.21.1 кодовая база выросла более чем в 2 раза. Жесть.

Итого на сегодня:
27к строк кода
263 коммита

Ни одной публикации, прошлую на 1.20.1 я удалил, так как толку в ней 0

Сделал и выложил первый релиз на 1.21.1, по сути своего рода Hello World!

Прошу любить и жаловать! Мод пока очень сырой, багов много, ну и в целом в моде особо пока ничего нет, 2 блока да предмет )
Плюс мод скорее всего не совместим с Kotlin For Forge, но это как я знаю решается.

Если кому интересно, то можете потестить, завести issues )

https://modrinth.com/mod/compukterkraft

На Modrinth довольно долго апрувят, так что продублирую мод здесь

пока на neoforge, если нужно будет, сделаю на fabric или вообще quilt

Вот такой логотип мне сгенерила нейронка Nano Banana. МНЕ КАЖЕТСЯ АХУЕННО

Вот второе лого

Пока мне абсолютно насрать как будет выглядеть хах, мне даже так нравится больше, пусть полная чушь, но пусть так. В любом случае компы в майне это настолько же странная штука, как и эти две картинки