Заинтересует ли кого-нибудь ядро 1.7.10 на основе Forge

@alexandrage, если вы так уверены в том, что проблема оптимизации В ОСНОВНОМ в модах, тогда почему бы вам хоть краем глаза глянуть на исходы 1.8/1.9, где почти в каждом классе на скорую руку навтыканы BlockPos'ы, которые создаются пачками каждую миллисекунду и вызывают нереальные утечки памяти. Эти классы используются даже там, где их, по мнению здравомыслящего человека, быть не должно, и это лишь малейший пример того говнища, в которое скатывается minecraft с каждой новой версией. Мое мнение таково, что обвинять разработчиков модов, не учитывая некомпетентность разработчиков самой игры является полным балабольством. Троллинг разработчика данного ядра тоже считаю необоснованным балабольством.[DOUBLEPOST=1469200789,1469200482][/DOUBLEPOST]ИМХО говорить о том, что Forge и Bukkit/Sponge являются идеалом для разработки, все-равно что считать, что их пишут знатоки java, которые знают толк в устройстве самой виртуальной машины и умеют писать правильный код. Такие люди (хотя есть и исключения) не занимаются подобными делами. Конкретно о самом Forge говорить не вижу смысла, так как уровень его говнокода понятен любому новичку в java.

 

Плохому танцору и яйца мешают)

100 игроков вполне возможно держать на каулдроне с 20-30 модами.

Тоже самое и относится к нытикам, которые хотят кубик на C++

 

Не пойму вашей позиции)

 

Хватит уже винить разработчиков во всём, Forge/Bukkit/Spigot используют все, он понятен любому и очень простой.

Sponge уже чистый энтузиазм, не каждому будет понятен и мало кому нужен из-за Bukkit/Spigot, моды только в СНГ популярны, никто для нас писать плагины не будет.

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

 

Я бы не заявлял, что фордж очень уж простой для понимания. Мод лоадер и то легче был.[DOUBLEPOST=1469206301,1469206271][/DOUBLEPOST]Тут чтобы добавить блок и привязать к нему модельку приходится попотеть.[DOUBLEPOST=1469206355][/DOUBLEPOST]Однако вы правы в том, что он лидер в своем деле, хоть уж и кривой донельзя.[DOUBLEPOST=1469206504][/DOUBLEPOST]

С этим не соглашусь, кто же, как не они виновны во всей этой кривоте? Чтобы портировать тот же мод с версии 1,6 на 1,7 придется хорошо так понервничать и повтыкать что к чему, а все потому, что API у Forge, как таковой - дерьмо. Ну, и не без моджангов тут обошлось.

 

У них не стоит задачи делать API для моддинга, поэтому изменения такие хаотичные.

С моделями в 1.8+ - да, бред полный, теперь рендер в зависимости от NBT будет сложновато сделать, но это делалось под нужды ваниллы.

У Bukkit хороший пример засунуть всю игру в свое API, и с другой же стороны - плохой, слишком геморойное портирование под новые версии.

А теперь представим если Forge будет таким же - мододелы используют половину игры под свои нужды, в том числе и извращаясь с рефлексией над ванильными классами, у каждого свои тараканы, получится игра в игре, такое API будут очень долго портировать под новые версии. Особенно учитывая, как сейчас Mojang выпускает каждый раз новые версии, мешая нормально доделать Forge под актуальную версию.

 

Вас никто не гонит обновляться. Юзайте стабильные билды или пишите и свои моды.
Кто то вон сидит на 1.5.2 и не дергается, галаксикрафт вообще не ушел дальше 1.8.1 бета.

 

С таким успехом можно было заморозить разработку форджа где-нибудь на уровне MC 1.2.5 и заставить всех играть на ней по сей день.

Не просто так игру же обновляют.

 

Ну да, заставь их заморозить. Да и моджанги не принесли в игру ничего интересного, да и то не сами придумали, а тупо скопитырили с модов. У них идеи кончились после бетки.[DOUBLEPOST=1469263221,1469263096][/DOUBLEPOST]Последняя их идея была поршни, остальное все скрысили. Ну или почти все.

 

Эх, всем привет в этом чате. Давайте что ль все точки над i расставлю напоследок.

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


По поводу проблем в модах, а не в ядре. Если проблема в моде, я могу написать автору, и он ее исправит. Никогда так не пробовали? Моды, в отличии от ядра, продолжают развиваться, и баги исправляются. Если кто-то считает максимальную высоту перебором, как кто-то выше указывал, то этот баг и исправляется за одну минуту. Ядро, в отличии от модов, очень технически сложный продукт, в нем не так много багов, которые одной строчкой исправляются. А любое крупное изменение месяцы инженеринга занимает. Любая оптимизация может наоборот регрессию производительности вызывать, всегда или при определенных условиях, может не работать вместе с определенным модов, или группой модов, или вызывать регрессию только с определенными модами, или вызывать какие-то странные необъяснимые баги при определенных модах, и так далее. Посмотрите вот доклад Шипилева, где он объясняет, почему простое, казалось бы, изменение класса String в Java 9 затягивается на годы разработки. Это по поводу сложности. Теперь по поводу эффективности. Именно ядро балансирует нагрузку между модами. Выбирает, какие обновлять чанки, Entity, TileEntity, с каким рейтом, как загружать/выгружать/отправлять игроку чанки, в каком порядке. Именно ядро дает абстракцию над игровым миром, и ее производительность определяет производительность всей системы. Если оптимизировать мод, то только этот мод начнет работать быстрее. Если оптимизировать ядро, быстрее начинают работать все моды. И наконец, Forge не занимается производительностью. Пофигу им на нее, у них другие цели - воткнуть API с как можно меньшим объемом патчей в майновский код, чтоб портировать было проще. Я даже не говорю о том, что разработка Forge 1.7.10 прекращена в декабре прошлого года.


А, и напоследок,

В BlockPos'ах нет ничего плохого, это как раз и есть нормальная абстракция над координатами вместо костыльных xyz-параметров. Граф вызовов инлайнится, escape analysis статически доказывеат, что BlockPos можно выделить на стеке. Все, никаких проблем. И уж точно это никак не связано с утечками памяти, термин неверный в данном случае.

 

Случаем не блоггер(не видео, а текстовый) ? Я что-то подобное читал. На LUA написан ?

 

Действительно, термин я подобрал неверный, однако проблема с ними все-же существует, и она довольно таки большая. В системе рендера чанков используется метод BlockPos.getAllInBox, который возвращает набор координат в листе, сгенерированных на основе начальной точки и конечной точки, но очень часто бывает что участок, который необходимо получить через эту функцию очень огромен и происходит это каждый раз при рендере каждого чанка, и лично я не вижу в этом никакого смысла, если можно сделать цикл тройной вложенности и пробежаться по полученным интеджерам, ведь это будет куда быстрее. Я не говорю, что эта абстракция не нужна, я лишь говорю о том, что она используется даже там, где ее быть не должно из соображений быстродействия.

 

Насколько я помню, не List он возвращает, а итератор, и новый BlockPos генерируется на каждый вызов Iterator.next() (а не сразу), после чего, процитирую.

JIT свернет это до цикла.

 

таки нет, возвращает он именно лист.[DOUBLEPOST=1469521115,1469521084][/DOUBLEPOST]http://prntscr.com/bxm9a2[DOUBLEPOST=1469521154][/DOUBLEPOST]В итоге получается двойная итерация. Сперва метод заполняет лист, затем вы итерируете этот лист.

 

Да етить-колотить

 

Можете уточнить, исходники какой версии у вас сейчас? Скорее всего это уже поправили.

 

1.8.0 Это были, кажется. Неужели они, кхм, наоборот, в последующих версиях в лист это превратили?

 

Таки нет, у вас 1,8,9 или выше. Ну, значит не так уж все и плохо.

 

А ещё выше появился MutableBlockPosition, и PooledBlockPosition, хоть что-то моджанги начали делать правильно. Правда самое старое говно так и не починили.

 

Может быть и до старого доберутся, будем надеяться)