Невалидный MinecraftForge.EVENT_BUS.register(this) после hot swap

[DexNotVite6]

У меня имеется абстрактный класс, где есть метод, который регистрирует его самого для ивентов.
После каких-либо изменений в этом классе и последующем применении хот-свапа, у меня перестает работать MinecraftForge.EVENT_BUS.register(this).
Буквально, не вылезает никаких ошибок, но и ивент не работает.

Как пример:

public abstract class Example {

    public void execute(EntityPlayer player) {
        System.out.println("Hello, Hot Swap");
        MinecraftForge.EVENT_BUS.register(this);
    }

    @SubscribeEvent
    protected void onTick(TickEvent.ClientTickEvent event) {
          System.out.println("Bye, Hot Swap");
         //Любой код. После мы делаем вот это:
          MinecraftForge.EVENT_BUS.unregister(this);
    }
//Изменив что-нибудь в этом классе, далее применив хот свап и запустив execute от имени какого-либо наследника,
// мы(ну или я) увидим, что ивент то и не выполняется.
}

Ну и там конечно же его наследники.

 

[ZZZubec]

protected защищенный метод, к нему имеют доступ только он сам и его наследники.
А событие должно быть в публичном, я бы там оставлял.
Второй момент SubscribeEvent это типо анотация для трансформера, которая срабатывает когда мы начинаем запускать игру или вообще когда компилируем.
В момент обратки изначальной формы, мы привязались к этому методу
А во время hot swap, естественно, объект уже другой и трансформеры не обрабатывают его уже снова. (рефлексия).
Но я бы ещё попробовал поиграть с публичным типом.

Второй момент, особенность асбтрактных классов заключается в том, что мы не можем иметь объект этого типа, мы лишь можем наследоваться от него.

Так вот, абстрактный класс — это максимально абстрактная, о-о-о-чень приблизительная «заготовка» для группы будущих классов. Эту заготовку нельзя использовать в готовом виде — слишком «сырая». Но она описывает некое общее состояние и поведение, которым будут обладать будущие классы — наследники абстрактного класса.

Поэтому если у Вас нет объекта который от него наследуется и должен иметь ту же анатацию (она вряд ли переходит к наследнику сама, хотя чем чёрт не шутит).

У тя все вопросы с подвохом? Потому что я вообще удивлён что это хоть как то работает.

 

[DexNotVite6]

Второй момент, особенность асбтрактных классов заключается в том, что мы не можем иметь объект этого типа, мы лишь можем наследоваться от него.

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

 

[DexNotVite6]

Поиграюсь с этим, завтра повешу правильный ответ, если всё таки добьюсь его.

 

[ZZZubec]

Попробуй ещё такое провернуть с основным файлом мода, думаю ответ кроется именно в этом.

 

[DexNotVite6]

У тя все вопросы с подвохом? Потому что я вообще удивлён что это хоть как то работает.

Ох, если б ты еще видел полный код... Ты бы либо выпал, либо угарал. Могу завтра как раз запушить, в лс отправить, вместе поугараем) хаха

 

[ZZZubec]

Могу завтра как раз запушить, в лс отправить, вместе поугараем)

боюсь тогда тебе придётся переписывать не сходя с места до тех пор пока это меня не устроит))) Нам физик указкой по рукам бил за такие вольности рук))

 

[DexNotVite6]

боюсь тогда тебе придётся переписывать не сходя с места

Нечего бояться, я не против если все таки кто-то конкретно укажет на недостатки, тем самым я же и улучшу свой проект.

 

[TheAndrey]

Зачем усложнять самые простые задачи?

register()/unregister() - достаточно дорогие операции и не следует их вызывать лишний раз. При регистрации вашего обработчика Forge генерирует прокси-классы для вызова методов ивентов. Лучше зарегистрировать всего один раз и выключать свой обработчик, добавив проверку на свой-во enabled. А может просто нужно внедрить коллекцию для реализации очереди задач которые нужно выполнить один раз за тик...