1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.
  2. Вы находитесь в сообществе Rubukkit. Мы - администраторы серверов Minecraft, разрабатываем собственные плагины и переводим на различные языки плагины наших коллег из других стран.
    Скрыть объявление
Скрыть объявление
В преддверии глобального обновления, мы проводим исследования, которые помогут нам сделать опыт пользования форумом ещё удобнее. Помогите нам, примите участие!

1.5.2 и 1.12.2 c Forge на 12-й Java? Не вопрос!

Тема в разделе "Модификации клиента", создана пользователем CyberMan, 3 май 2019.

  1. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Мой друг переделал свою сборку на 1.5.2 с Форджем, которая запросто идёт на любой современной версии java.

    Вот собственно сама сборка: https://yadi.sk/d/UDVUNWOnNgR5UQ

    Актуальная версия, работающая под:
    Java 6 (JDK);
    Java 7 (JDK, OpenJDK);
    Java 8 (OpenJDK, IBM J9);
    Java 9 (JDK);
    Java 10 (OpenJDK);
    Java 11 (OpenJDK, AdoptOpenJDK, IBM J9);
    Java 12 (JDK, AdoptOpenJDK, IBM J9);
    Java 13 (OpenJDK : Windows/x64).

    Сервер пока в разработке, и работы там достаточно много.


    Все ответы начиная с 18 мая будут вестись от его имени. Если ответ будет от меня, будет приметка.
     
    Последнее редактирование: 18 май 2019
  2. imDaniX

    imDaniX Активный участник Пользователь

    Баллы:
    96
    Имя в Minecraft:
    imDaniX
    [​IMG]
    Я, конечно, понимаю, что кому-нибудь эта версия да понадобится, но всё же, 6 лет...
     
  3. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Ну, у каждой версии есть свой шарм.
     
  4. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    попробуй запустить сборку на Java 12. Потом собери свою сборку без фиксов и снова запусти. Потом запусти эту сборку повторно.
     
  5. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Отвечает автор сборки, ниже привожу его слова.
     
  6. alexandrage

    alexandrage Старожил Пользователь

    Баллы:
    173
    Ну да, качасть сборку весом 271 МБ не считается. Когда можно было просто выложить форж с фиксом.
     
  7. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Там не только фордж, но и моды. Например, оригинальный CodechickenCore ты не запустишь на 12-й яве.
     
    Последнее редактирование: 18 май 2019
  8. alexandrage

    alexandrage Старожил Пользователь

    Баллы:
    173
    Окай.
     
  9. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Так как автор сборки пока не может писать сюда сообщения, так как сервер просто не дал ему залогиниться, предлагаю его развёрнутый ответ по поводу сервера и всей сборки в частности:

    Сервер (MCPC+): https://yadi.sk/d/VZ_rEWKgQo_UgQ

    Базовый, без плагинов. Тоже поддерживает Java 6 и выше.
    Тестовый запуск был проведен на Manjaro Architect (Linux): i7-7700K, Kernel 4.19-rt, OpenJDK 13-ea+18.
    Работоспособность была проверена совсем бегло заходом на локально поднятый, поэтому не гарантируется.

    Ну что ж, раз уж соизволил зарегистрироваться, предоставлю более подробную информацию. (Было бы сказано, что зарегистрировался, если бы не ERR_CONTENT_DECODING_FAILED)


    Данное произведение имеет относительно долгую историю.

    Первый импульс или let time = 0. Началось все во времена, когда подавляющее большинство серверов было под 1.4.7, а редкие люди все еще помнили про Ships and Boats, MineUP + GravityCraft под 1.2.5 (на замену обоих, в общем-то, уже есть относительно нормальные аналоги). Имея опыт сборки всевозможных клиентов, надумал я собрать такой, в который не стыдно будет рубаться на досуге. Взял стандартный пиратский лаунчер, прикрутил проверенный временем своеобразный базис индустриалочки да начал время от времени совершенствовать.

    Второй импульс: we need a portable. Прыгая с устройства на устройство, пришло понимание, что всякий раз ставить майн в AppData — не есть хорошо. Переустанавливать винду как чай пить тоже было делом у меня обыденным. В придачу ситуацию усугубляла необходимость проверять те или иные варианты сборки асинхронно (но в legacy режиме, поскольку от природы я не имею нужных для полноценной асинхронности возможностей противоположного пола). Поэтому, быстренько нагуглив возможные варианты, по инструкциям с разных сайтов и некоторых топиков данного русского ведра прикрутил я portable java + скрипты для имитации того, что папка с лаунчером на самом деле AppData. Размер сборки вырос значительно, сходство между Java в Program Files и "portable java" давало некоторый повод для подозрений, но сборка уже нормально могла запускаться с флешки и где бы то ни было — это радовало, этого было достаточно.

    Третий импульс: пахан и телега всея Руси. Процесс клепания сборки был бы типичным для всех индустриальных сборок, если бы не одно но: "пентиум с 2 гигами и без видюхи". Это ограничение не позволяло мне даже запустить некоторые сборки steamlynx, поскольку по факту майну я мог выделить ну не более гига. Сей, казалось бы, минус, стал первопричиной уклона в сторону легкости и стабильности. Вкус OutOfMemoryError заставлял с умом подбирать моды, а небольшое количество оных служило стимулом анализа их влияния на геймплей. Вместе с тем начались и различные манипуляции с байт-кодом, поскольку одними только модами сыт не будешь: незначительно редачился лаунчер, выпиливалась проверка версии библиотек (ради их обновления), доходило и до изменения некоторых аспектов модов (но как правило не дальше уровня InClassTranslator). Именно с этих времен в заголовке лаунчера висит уже не столь актуальное "Stability", поскольку полученная база великолепно оправдала ожидания, уложившись в указанные рамки и возымев нескучные обои. Примечание: текстур-пак, как и аудио-пак для audiotori, во благо минимализма к текущей версии не прилагается.

    Четвертый номер: взлет под крылом пингвина. Все шло хорошо. Даже очень. Точнее, на месте обездвиженно лежало. Вот так постепенно да нарастал интерес к Linux, потому как винда настолько поднадоела, что даже стоячий Haskell Platform не радовал. И однажды час X наступил.
    Стояла темная ненастная ночь. Незаметно, но громко, кулер орал. Это так пингвин под виртуалкой взлетал.
    Естественно, далее виртуалкой дело не ограничилось: уже спустя довольно незначительное время Ubuntu-based дистр лини встал второй системой. Вскоре встал и вопрос о запуске сборки под Linux, ведь жизнь не ограничивается юзаньем LibreOffice (вместо которого, впрочем, разумней использовать WPS Office), сидением в почти не падающем Firefox и шаманством в эмуляторе терминала. Первым делом пришло озарение, что portable java — ненужная при данных обстоятельствах ересь, повлекшее за собой окончательный отказ от ее использования. Вторым делом была написана версия скрипта запуска для bash, ведь не маст хэв юзать wine для запуска батников через cmd.exe. Третим делом оно запустилось. Впоследствие обнаружилось, что при использовании Optifine Ultra возможны разного рода косяки, что у меня проявилось в виде пропажи тех или иных частей тела у мобов: то и дело у свиней терялась голова. Не сразу стало ясно, что виноват именно Optifine, пока отказ от Ultra и гуглеж инфы не подтвердил подозрения. Имеем, что в итоге сборка стала кроссплатформенной, как и надлежит быть Java-приложению.

    Пятый элемент: the unstable, night watch. Несмотря на полученный опыт, спустя пару недель или месяцев я все же обратно слез на винду. Сидел я скучно и неинтересно, пока родная материнка Foxconn не сдохла: дальнейший осмотр показал, что она вообще неизвестно каким боком работала, она в принципе уже теоретически была пару лет как мертва. Время до закупки через Авито новой материнки "навороченный Kraftway" с процессором 2 Duo и дополнительными 2 гигами оперативки, суммарно все около 2К, стало для меня углублением в Java, в основном по части докладов JUG. После пересборки ПК еще немного посидел на винде, но в итоге свалил на Gentoo Linux. Исходя из логики сей писанины, можно было бы вам ожидать, что сейчас пойдет про то, что опять нужны какие-то изменения, даб все работало, но нет: Gentoo меня где только не насиловала, но только не по части майна. Проблемой стало резкое снятие тех самых ограничений, благодаря которым сборка имела приятное качество. Стало возможно напихать больше модов, конкретные оптимизации стали не нужны. В этот момент сборка перестала быть стабильной и начала жрать больше памяти, нежели привычное до этого "меньше гига". Но не все было так уж плохо: в процессе возни я выяснил, что жителям можно без модификаций добавлять звуки, а фоновая музыка загружается через форик (т.е. не ограничивается теми номерами, что в resources определены), о чем соизволил и на Minecraft Wiki спустя какое-то время написать. Также обнаружилось, что, сколь 1.5.2 является "переходной стадией между 1.4.7 и 1.6", столь легко падает клиент с "нормальным" кол-вом модов и высококачественными текстурами. Маппинг текстур был в итоге пофикшен (вроде б в TextureMap), говнокодом, т.к. из-за общей нестабильности не было смысла заморачиваться с качеством, но со временем этот фикс был где-то когда-то потерян.

    Шестой черт: выдержка временем. Переход на нестабильную ветку, конечно, чреват потерей качества, но взамен мы получаем изрядно больше возможностей для развития геймплея. Постепенно добавлялись различные аддоны, какие-то моды отсеивались из-за порчи геймплея, какие-то приобретали новые черты путем махинации с конфигами. Все это можно видеть в обилии мусора под директорией config текущей версии сборки.
    Однажды наступил роковой день: был обнаружен на просторах minecraftforum, откуда я всегда качал моды, крайне сырой More Minerals Mod. Настолько сырой, что версия для 1.5.2 никак не хотела запускаться. Я видел, да и по сей день вижу, этот мод в качестве "хорошего дополнения для Metallurgy", а потому меня это не остановило, я принялся его декомпилировать. Не могу сказать, что он хоть немного ушел от того уровня вонизма, какого был изначально, но на протяжении довольно продолжительного времени я то и дело вносил в этот мод изменения. Ныне имеем, что он вполне работает, угольные предметы наконец-то можно юзать как топливо (а не только в утильсырье переводить), но его влияние на Край крайне неприятно. Время шло, текли годы, а я время от времени вспоминал про сборку и что-либо с ней химичил.

    Седьмая Java: как она пропала. Не так уж относительно давно я сел на Void Linux, но не обычный, а с musl. До этого у меня стояла elementary OS, так как лень настраивать вид самостоятельно было (а в душе я дизайнер), которая и сейчас на ноуте по сей день стоит. Обилие пришедших проблем из-за musl так и веяло духом мазохисткой Gentoo, где возня с билдами пакетов и пересборка ядра была нормой, из-за чего загорелся интерес проверить что да как будет под musl работать. Мой любимый Firefox выдал ошибку сегментации — пришлось какое-то время юзать links, а затем таки решиться установить Chromium. Редактор Code из elementary OS тоже не захотел работать, привычный аудиоплеер из той же оперы. Постепенно организовал из-за возникающих проблем довольно непривычный зоопарк софта, но к которому в итоге нормально адаптировался (благо от lxtask отказываться не пришлось). LXQt + тема Flat Remix Green, кастомная цветовая палитра и прочие дизайнерские примочки сделало все приятным. Настолько, что и Manjaro Architect, который стоит рядом с Void-musl, имеет копипасту его настроек. Все было норм, а я обнаружил, что Java конкретно под версию с musl в репозиториях нет. Быстрый гуглинг дал информацию, что это прям тяжелый случай у Void, а нормального решения нет: "чтобы скомпилировать OpenJDK, надо уже иметь хоть какую-то JDK". Долгие поиски в итоге свелись к тому, что я стырил бинарники JDK 11-EA по ссылке из бренча какого-то проекта на гитхабе про докер. В надежности работы этих бинарников я не был уверен, поэтому пришлось компилировать посредством этой JDK свежую OpenJDK 12 в виде проекта Portola. После долгой компиляции, которая почти полностью состояла из подбора "а каких ошибок игнор радо врубить gcc, чтоб оно вообще скомпилировалось", возымел вполне работоспособную OpenJDK, но 12 версии, а не традиционно используемой 8 (стоит, в общем-то, заметить, что дефолтно сборка почти всегда запускалась через 7, а неспешный переход на 8 возник по смутным причинам в достаточно поздний период). Почти сразу же одолел интерес "а запустится ли сборка". Звонок 1: бинарная несовместимость с нативщиной OpenAL. Окей, заменил на системные .so. Звонок 2: Лаунчер запустился, но почти сразу же после запуска прилетело исключение про ошибку кастования в URLClassLoader. Погуглив, понял, что до этой проблемы никому нет никакого дела, а ее наличие обосновывается как "Forge не поддерживает Java >8". Мне стало обидно за жаба-девелоперов, нацеленных на майн, особенно на фоне того, какой хлам представляют из себя исходники современных модов. Это ж как так можно, имея путь откуда прилетело исключение, подробности на всяких ресурсах вроде StackOverflow, не исправлять это годами, лишь бы не заморачиваться? В итоге, не считая модов, все решилось изменением ровно 2 классов Forge, в одном из которых ровно 1 (2) строки. Обсуждение процесса в моей секте в итоге вылилось в то, что моя сборка с этими фиксами оказалась тут, хоть я и не надумывал ее когда-либо куда-либо, кроме как своей секты, выкладывать.
     
    Последнее редактирование: 4 май 2019
  10. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Цена поддержки Java 9.
    Если вы не пожалели времени и сил на прочтение предыдущей главы, то, надеюсь, что вы поняли почему поддержка Java 9 и выше для этой сборки второстепенная.
    Также упомяну, что отсутствие этих фиксов как отдельного патча проблемно по следующим причинам:
    1) Сборка содержит отчасти поломанный русификатор, который вы можете найти на этом же сайте, а один из файлов, подлежащих изменению, им затрагивается;
    2) Говнокод в силу нестабильности сборки в целом. Увы, но нацел фиксов был на то, чтоб оно заработало, а не чтоб гарантированно работало корректно.
    Специально для тех, кому нет дела до сборки, а нужны лишь фиксы, приведу подробности этих изменений, чтоб вы сами смогли свои сборки какой-либо версии адаптировать в случае необходимости.

    Инструментарий Java-ассемблерщика.

    Мною использовался преимущественно древний Minecraft Coder Pack с Forge, который у меня каким-то чудом сохранился на протяжении долгих лет, как и Libigot. Эта тварь юзает wine, когда Artistic Style и под *nix есть, и некорректно парсит его выхлоп, но в целом, если немного подправить змеиные скрипты, работает по сей день без проблем.
    Для редактирования MCPC+ я юзал fernflower для декомпиляции (взять можно в том же MCP), bytecodeviewer (когда fernflower не справлялся), а reJ для изменения собранного класса. Видите ли, начиная с Java 1.4 нельзя импортировать классы из default package, что затрудняет редактирование тех классов, которые как-либо юзают всякую ересь, расположенную напрямую в джарнике без сабдиректорий. Поэтому я делал хитро: перетаскивал исходник на уровень default package, компилил через javac (-source 1.6 -target 1.6), а затем слегка менял через reJ: заходим в список констант и меняем константу типа UTF-8, содержащую имя класса, на путь/до/класса/ИмяКласса. Работает прекрасно, но почему-то об этом даже на StackOverflow нет в виде готового решения.

    Ниже расположены подробности по изменениям, достаточных для поддержки Java 9 и выше. Редактируются как в клиенте, так и в сервере, если не указано иное.


    cpw.mods.fml.relauncher.FMLRelauncher.

    Сама проблема, которая возникает при попытке запуска Forge под Java 9 и выше, заключается в том, что разрабы Forge ну очень некрасиво поступили при написании инициализации FMLRelauncher. Если вы загляните в исходник, то увидите, что конструктор создает новый RelaunchClassLoader, передавая в качестве аргумента массив URL'ов. Казус в том, как они получаются.
    Получение мест, откуда классы можно грузить, в таком виде, как оно там, конечно, является привычным трюком: считаем, что ClassLoader, получаемый через reflection, является типичным URLClassLoader да приводим его к этому типу. Подобные вещи вида "приведение общего к частному" в Java, увы, привычная практика (в C++, например, подобная вещь тоже есть, но там она вроде б не так яро юзается). Стандартом не гарантируется, что ClassLoader, получаемый таким способом, будет именно экземпляром класса URLClassLoader или его потомка. В Java 9 "отражения" подверглись изменениям, особенно в связи с введением модульности, отчего этот старый способ перестал работать.

    Фикс довольно прост: гуглим нечто в духе "как в java 9 получить список путей для классов" и натыкаемся на тему StackOverflow . Поскольку нас интересует минимальное внесение изменений, копипастим второе решение. Меняем реализацию взятия полного пути через Paths на реализацию через File (это довольно просто сделать), если хотим поддерживать Java 6 (т.к. Paths, как и практически весь New I/O, доступен лишь начиная с Java 7).

    Под свежие версии мы можем не обнаружить FMLRelauncher, но исключение будет все равно прилетать — ныряйте в launchwrapper. Там та же ситуация.
    Кажется, даже есть старый форк, но с замудренным фиксом, а не простенький форик.

    net.minecraftforge.common.EnumHelper.
    Майн уже (во всяком случае, под 1.5.2), будет нормально запускаться, хоть мы и изменили буквально 1 строку, не считая передачу аргументом.
    Проблема начнется, когда мы попробуем запустить с определенными модами. Не при всех валится: в моей сборке модов, у которых прилетает исключение от EnumHelper, оказалось не более пары десятков.

    Во-первых, в Java 9 из-за модульности урезали возможности отражений и unsafe.
    Во-вторых, в Java 12 теперь нельзя химичить через отражения с модификатором final.

    Первое можно решить написанием изменения Enum другими средствами, которые вполне нормально гуглятся (даже статья на хабре имеется).
    Второе гарантирует жопоболь.

    Лично мною был класс изменен говнокодом в стиле соответствующей теме статьи и навешиванием try-catch на метод, редактирующий final. Этот наклепанный на коленке говнокод неизвестно каким чудом работает, его можно легко намеренно повалить, но в условиях моей сборки он адекватно отрабатывает.

    Моды.

    Matmos и Audiotori: синглтона хуже для прода не придумаешь. Там через отражения обращение к final модификатору.
    Оборачиваем в try-catch и все работает, а на разраба мы ищем психопата, который будет знать, где он живет.

    CodeChickerCore: сертификаты классов? Кидаем сверхинформативное исключение "qw" в случае, если эта сомнительная штукенция повалилась?
    Убираем из catch выброс нового исключения и молимся, чтоб в прод такое не пускали.

    Классы серверной части.

    Если вы наклепали абы как работающий говнокод, вам будет необходимо изменить и некоторые классы. В частности классы CraftBukkit. В частности Material.
     
    Последнее редактирование: 4 май 2019
  11. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    А можно ли проще, да чтоб под 1.12.2?
    https://github.com/ie900/UnLoki — готовая реализация работы с reflection, способная работать под Java 6 — 13.
    https://pastebin.com/srNx1Afv — бинд для EnumHelper.

    net.minecraft.launchwrapper.Launch.
    Это первая преграда к нашему счастью под Java >=9.
    А решается просто: изменяем первые две строки конструктора согласно ответу из StackOverflow (см. предыдущие заметки).
    Не забываем и про импортирование URL.

    net.minecraftforge.registries.ObjectHolderRef.
    Это следующий проблемный класс.
    Спрашивается: а зачем там тоже отдельно юзается sun.reflect.*?
    Так или иначе, места в незере хватит на всех причастных к этому безобразию.

    1. Если вы успешно собрали упомянутую выше библиотеку, импортируем нужные нам классы:
    2. Идем в FinalFieldHelper. Удаляем все поля (private static Field, private static Method...) за ненадобностью.
    3. Добавляем такое:
    4. Заменяем реализацию makeWritable на такую:
    5. А setField на такую:
    6. Не забудьте удалить и указание выбрасываемого исключения, поскольку оно уже их не бросает.
    7. Радостно разворачиваем обертки try-catch где-то выше, иначе компилятор на нас обиженно орет "это исключение никогда не придет!".

    net.minecraftforge.common.util.EnumHelper.
    Клиент уже отлично запускается без модов. Но мы ж и моды хотим, да?

    1. Если вы не забыли про EnumUtil (второй ссылкой), импортируем:
    2. Делаем EnumHelper потомком EnumUtil:
    3. Удаляем все поля от reflectionFactory до isSetup за ненадобностью.
    4. Видим объявление списка классов? Превращаем в такую конструкцию:
    5. Опционально добавляем {EnumPlantType.class, String.class} (не забудьте дописать еще и import net.minecraftforge.common.EnumPlantType; ).
    6. Удаляем все методы начиная с setup (т.е. включая addEnum и т.д., но не включая addHorseArmor и подобное).

    Эпилог.
    Наш EnumHelper и все остальное отлично работает, но что может встать на нашем пути?
    Говнокод и, в частности, копипастеры.

    CodeChickenLib пытается работать с final-модификаторами через modifiers и радостно валит нас соответствующими исключениями.
    RailCraft зачем-то юзает sun.reflect.* и тоже спокойно все гнобит.
    Applied Energistics 2 — тоже modifiers.
    И т.д.
     
  12. Bars

    Bars Старожил Девелопер Пользователь

    Баллы:
    173
    В смысле Java 12? 8 последняя же. По крайней мере у Oracle, а Oracle - это официальная Java. Когда Oracle выпустит свою Java 9, то она будет другой по функционалу
     
  13. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
  14. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Для тех, кто думает, что ie900 тут хернёй страдает. Одно но: 42 мода, неплохое железо, 44 фпс... Стоит задуматься.
    https://prnt.sc/no4090
     
    Последнее редактирование: 13 май 2019
  15. alexandrage

    alexandrage Старожил Пользователь

    Баллы:
    173
    Не лезть куда не следует. Весь пакет sun не для юзеров.
     
  16. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    См. выше про net.minecraftforge.registries.ObjectHolderRef. Это как раз подобный класс.

    Мода на sun.reflect.* пошла у разрабов Forge после копипасты методов из этой статьи: https://www.niceideas.ch/roller2/badtrash/entry/java_create_enum_instances_dynamically
    И, вообще говоря, на самом деле sun.reflect.* не нужен. Все, для чего его используют, достигается и использованием обычных средств отражений. Более того, вариант с его использованием проигрывает по производительности.
    Единственная проблема, ради которой весь этот бедлам с отражениями, — редактирование static final полей. Причем именно только редактирование: для чтения значений особо никаких дополнительных действий и не надо.

    Вот пример того, в какой вид можно привести cpw.mods.fml.common.registry.ObjectHolderRef: https://pastebin.com/Da6Kzer0
     
  17. Автор темы
    CyberMan

    CyberMan Старожил Пользователь

    Баллы:
    173
    Skype:
    cyber4el
    Мною уже был сочинен ответ из 3 пунктов ("графические возможности моего проца мощнее многих бюджетных видюх", "майн — это в первую очередь проц", "1.5.2 vs 1.12.2"), но посчитал сомнительным поднимать эту тему.
     

Поделиться этой страницей