Учебник 2022

Всем привет! Давненько наш учебник не обновлялся, пора что-то с этим делать. У меня появилось время и теперь я могу полноценно заняться 1.7.10 версией. Кто-то спросит: "а почему 1.7.10?", отвечаю, лично мне поступало довольно много сообщений с просьбой добавить уроки по 1.7.10. Также планируется дописывание старых статей(1.12.2), а возможно и в некоторых случаях полное переписывание!

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

 

[Sainthozier]

Хз какой толк от этих ваших 1.7.10. Его прошерстили вдоль и поперёк уже миллион раз за столько лет.
Я бы лучше посмотрел на best practices, потому что у коммерческих мододелов больше опыта и знаний со стороны тех. части, они обладают огромнейшим ресурсом, которого нет у обычного разраба - комьюнити для теста, которое сразу же сообщает о багах.

Вот от коммерческих мододелов часто слышишь, что некий мод X - говно, но пруфов никаких, никаких слов по факту. Даже знаю, что коммерция хейтит Вазки за то, что он распространяет херовые практики, не смотря на то, что для всех других он является чуть ли не иконой и примером в моддинге, кек.
Я понимаю, что фиксы - это чей-то хлеб, но надеюсь, что уже прошло достаточно времени, чтобы написать хотя бы простенький вариант лучших практик в моддинге, как стоит делать и как ни в коем случае не делать. И начать, думаю, следует с safe packet handler'a. Потому что люди 5 лет писали одинаково, словно под копирку, бед не знали, пока не пришёл, кажется, червяк и не поставил всех раком

Но в любом случае лайк за уделенное время в будущем, это ценный ресурс.

 

[Icosider]

1.7.10 всё же нужен, ибо нормального учебника по этой версии нет и не будет от других. Так что почему бы и нет?
На счёт best practices, соглашусь, но в тоже время 1.7.10 ещё пока не потерял своей актуальности и следовательно потеря "хлеба" есть. В целом, можно поговорить в данных статьях про пакеты, про правильное использование клонирования вещей, про различные дюпы, но зачастую, такие статьи нужны только в том случае, если подача в самом учебнике говно и переписывать просто лень. Я дам всю важную основу в 1.7.10, задача остальных сделать тоже самое(а может и лучше) для 1.12+, но не более. Всё остальное уже является побочкой, которую они должны изучить сами.

 

[TheAndrey]

Идея отличная, я только "за". Мне есть что высказать по поводу дюпов. По этой теме самому материал писать лень, пусть пишут за меня, я могу только подсказать. Хоть какая-то польза от относительно бесполезных знаний для меня.

Я понимаю, что фиксы - это чей-то хлеб

Зря переживаете. Багов в иностранных модах полно. Написание какой-то там статьи не приведёт к их исчезновению.

 

[GoogleTan]

Спойлер

Ты добавил старый трупик и хочешь удалить много часов моей работы? Куда катится этот форум....

а нужны ли нам статьи по 1.15?

Их легко можно перенести на 1.16, которая будет LTS с слов Лекса

 

[Icosider]

Просто перенеси по возможности на 1.16, а то там кто-то написал 1.16 раздел, а посмотрел я только сегодня и был в ужасе)

 

[promortred]

 

[Looffy]

го гайд по 1.12.2, желательно по созданию gui

 

[MJaroslav]

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

 

[GoogleTan]

Это и щас можно при помощи ПР в учебник... Я так по фану раздел 1.15 сделала)))

 

[Icosider]

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

Я 1.7.10 напишу, а дальше пусть портируют, дополняют. Оформление и прочее будет, да и сам теперь ПР буду смотреть, а то после 1.16 кровь из глаз

 

[GoogleTan]

А если я сделаю вариацию учебника на котлине

 

[Icosider]

Не надо, кому надо, сами перепишут на котлин, зачем других принуждать переходить на другой язык? Даже если это будет отдельно, лучше уж сделать как в gradle, когда можно менять dsl с groovy на kotlin, но не как отдельный раздел. Вообще, надо вернуть выпадающий список для выбора API

 

[MJaroslav]

Если и делать, то с переключалкой как у градл доков (там груви и котлин варианты).

 

[Icosider]

А я по твоему что выше написал? xD

 

[hohserg]

И начать, думаю, следует с safe packet handler'a.

Вся, информация, приходящая с клиента - потенциально ложь. При разработке нужно иметь это ввиду. Все.

 

[TheAndrey]

Нет, не всё. Сколько раз видел выборку игрока по entityId, передачу dimensionId Такой подход открывает возможности для шалостей над другими игроками. Хотя бы кратко описать надо, как получать достоверные данные: игрок и мир. Например, для работы кнопок в инвентаре лучше использовать player.openContainer, нежели традиционную передачу XYZ блока, что открывает простор для пакетхаков на сборс настроек механизмов в привате.

 

[Icosider]

Не player.openContainer, а enchantItem или как-то так метод называется. А если гуишка не имеет контейнера, что тогда? Координаты можно сверять, можно плейсера проверять, как это в табличке сделано и т.п. И entityId/dimensionId это самое малое что могут сделать, больше забавляет, когда урон через mouseOver делают и шлют пакет без единой проверки при обработке, а ещё когда отсылают стэки предметов или же NBT, который потом суют в TileEntity#readFromNbt. В общем список можно продолжать до бесконечности

 

[necauqua]

Нет, не всё

И всё последующее сообщение подтверждает что таки всё, привет

 

[MJaroslav]

А я по твоему что выше написал? xD

Лол, я. видимо, тогда на первом предложении читать закончил.