Результаты поиска

Ещё раз повторю, что игрок переопределяет метод onUpdate и не вызывает родительский( По поводу LocalVarible: я думал, что это локали внутри метода, а не поля класса А какую проверку? Я не придумал более оптимального решения, чем это Вызов скомпилированной лямбды занимает столько же, сколько и...

Моё решение (используется [Гайд][Легко][1.6+] Модификация чужого кода при запуске (трансфомеры)): @Hook public static void onUpdate(EntityPlayer player) { ItemStack[] itemStacks = getPrevEquipment(player); for (int j = 0; j < 5; ++j) { ItemStack itemstack = itemStacks[j]...

Это не новость. Тут вопрос в том, что если реворкать чужой код, то от лишних кастов стоит избавиться... тем более идея сама подсказывает, что это хорошо бы сделать...

Мы с победителем всероса по информатике дебажили полчаса A*, чтобы что-то путное в интеллекте получить... и эта штука очень помогла. Сомневаюсь, что у него недостаточно знаний и практики...

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

Кстати про C и C++.. нативки подкрались незаметно..

Реворк АПИ Библиотека для красивых диалогов! Понадобилось самому, но в апи были сильные проблемы с ООП. Реворкнул, вроде, стало удобнее. Ещё убрал линию отделения, которая в моём кейсе была не нужна. После реворка остался только один старый метод (отрисовки гуи)... К примерам...

DimasikBC добавил(а) новый ресурс: Библиотека для красивых диалогов! (Rework) - Небольшой рекодинг апи для диалогов. Узнать больше об этом ресурсе...

Тогда ручной (???) апкаст просто ничем не обоснован)

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

Не, я про каст объекта созданного через конструктор. Так делать нельзя (причина очевидна). Если TextComponentTranslation является наследником ITextComponent, то каст просто необоснованный. Если это не так, то каст приведет к вылету исключения.

Щас бы делать прямой каст создаваемого объекта

Щас бы не юзать isEmpty

Лог, пожалуйста. И ещё было бы неплохо поглядеть на весь код, а не на фрагмент

Для сравнения типов instanceof действительно эффективен (по сравнению с другими методами). Но в моём кейсе от проверок можно избавится вовсе.

А в чем удобство? Даже тестить удобнее с кодом патхфайндера, который ты можешь изменить в рантайме. Единственный недостаток, который приходит на ум -- невозможность использовать скриптовые классы для расширений твоего плагина/мода в компилируемом коде

Ну...тут я не согласен. Есть моменты, которые стоит продумывать сразу, если отношение перфоманса к затраченному на разработку времени позволяет. В том кейсе, чтобы избежать нескольких проверок (втч instanceof) понадобилось... 2 минуты. По поводу "миллионов вызовов инструкции" не соглашусь...

Почему хреновый подход? Возьмем какой-то простой пример: Нужно сделать AI мобу для поиска лучшего пути. Есть, например, алгоритмы дейкстра и А*. Они оба основаны на графе, который нужно будет строить. Мы создаем абстрактный класс, например, GraphBasedPathfinder, в котором есть метод генерации...

Ну... Каст и инстансоф явно не являются "быстрыми" инструкциями. Так что, мне кажется, избегать их вполне норм)

Так вещи маленькие же только в примере. На деле из таких файликов можно даже неплохую архитектуры мутить. А если будет много скриптов, то скрипт-менеджер и JS вообще станут максимально неудобными.