Событие при экипировании брони

[DimasikBC]

Есть ли какое-то событие/вохможность добавить колбэк/переопределить метод экипирования брони?

 

[DimasikBC]

Решение:
Проблема, в общем, оказалась в том, что майнкрафт напрямую юзает метод сета брони только в случае, если эта броня надета через ЛКМ. Спрашивается WTF, но ладно.
В общем, добавил хук на onUpdate у EntityPlayer + заюзал previousArmor от EntityLivingBase.
Код скину в эту же тему завтра, вдруг кому-то надо будет

 

[tox1cozZ]

добавил хук на onUpdate у EntityPlayer

Есть LivingUpdateEvent.

 

[DimasikBC]

LivingUpdateEvent не распространяется на игрока (в 1.7.10 точно). Да и вызов евента довольно оверхедный из-за кучи лишних проверок каждый тик.

 

[hohserg]

Да и вызов евента довольно оверхедный из-за кучи лишних проверок каждый тик.

В общем, добавил хук на onUpdate у EntityPlayer

Какие у тебя там лишние проверки то? instanceof чтоли? Это уже овероптимизация

 

[DimasikBC]

Я согласен, что это овероптимизации (<1 мс за вызов), но всё же, с учётом того, что это частовызываемая, мне кажется, злоупотреблять операциями не стоит..

 

[DimasikBC]

Моё решение (используется [Гайд][Легко][1.6+] Модификация чужого кода при запуске (трансфомеры)):

@Hook
public static void onUpdate(EntityPlayer player) {
    ItemStack[] itemStacks = getPrevEquipment(player);
    for (int j = 0; j < 5; ++j) {
        ItemStack itemstack = itemStacks[j];
        ItemStack equipment = player.getEquipmentInSlot(j);
        if (!ItemStack.areItemStacksEqual(equipment, itemstack)) {
            itemStacks[j] = equipment == null ? null : equipment.copy();
            //YOUR CODE HERE
        }
    }
}

Небольшое пояснение: метод getPrevEquipment возвращает предыдущую броню игрока. Это поле в EntityLivingBase называется field_82180_bT. У меня она получается через трастед лукап и лямбдаметафактории. Вы же можете получать просто через рефлексию.

 

[tox1cozZ]

А можно просто хукнуться в EntityLivingBase#onUpdate после вызова func_151247_a. Через @LocalVariable в хуке взять нужные переменные и получить универсальный метод обновления экипировки вообще у всех мобов.
Для игрока же просто запилить проверку.


P.S Зная твою любовь к "оптимизациям", один instanceof будет работать в разы быстрее чем твой цикл, дополнительная проверка ItemStack.areItemStacksEqual и лукапы/рефлексии.

 

[DimasikBC]

Ещё раз повторю, что игрок переопределяет метод onUpdate и не вызывает родительский(

По поводу LocalVarible: я думал, что это локали внутри метода, а не поля класса

Для игрока же просто запилить проверку.

А какую проверку? Я не придумал более оптимального решения, чем это

P.S Зная твою любовь к "оптимизациям", один instanceof будет работать в разы быстрее чем твой цикл, дополнительная проверка ItemStack.areItemStacksEqual и лукапы/рефлексии.

Вызов скомпилированной лямбды занимает столько же, сколько и прямой вызов метода так-то...

 

[tox1cozZ]

Ещё раз повторю, что игрок переопределяет метод onUpdate и не вызывает родительский(

EntityPlayer, открываем глазоньки :3

По поводу LocalVarible: я думал, что это локали внутри метода, а не поля класса

Ну да, тебе же стаки нужно передать в хук (предыдущий и текущий, который обновился). А они идут как локальные переменные в методе (itemstack и itemstack1).

А какую проверку? Я не придумал более оптимального решения, чем это

instanceof в хуке, ну. Ты же хукаешься в EntityLivingBase, а нужно выполнять код для игрока.