Создание копии стака? Зачем? Сохрани изначальный размер стака, а потом установи обратно.
Это можно, хорошая идея
Там до сих пор лежит выключение освещения.
Ты хочешь чтобы я его назад включал? Ну так строка перестает рендерится как мне надо. Если не включать - все норм.
При перезагрузке майн все равно создаст обычный PotionEffect, а не твой.
А вот я и удаляю тот самый обычный PotionEffect и заменяю его на свой в
EntityJoinWorldEvent
.
Кому как, конечно, но мне кажется лучше просто накладывать модификатор на скорость перемещения, а не использовать поушн.
Меня привлекает, то поушн уже умеет рендериться в привычном для игрока виде. А насчет модификаторов - просвяти, будь добр. Как они работают?
Про этот трэкер тебе уже сказали. Его лучше держать в IEEP/Cap
Ну хз... Хук в
PlayerInventory#setInventorySlotContent()
и дело с концом. И никакой капы не надо.
Исходя из этого мапа тебе не потребуется.
А вообще, даже если использовать мапу, то для игроков лучше использовать WeakHashMap. А то мало ли что может произойти.
По сути ты предлагаешь веса итемов хранить в капе игрока. Но нафига, если на всех игроков один вес итемов?
Что за костыль prevWeightClient? Даже в одиночной игре игре существуют два объекта одного и того же игрока (для клиента и сервера). Поэтому я вообще не понимаю зачем вообще вставлен этот костыль.
Потому что для трекера это не работает. Если запущен интегрированный сервер, то на клиентский и серверный поток один объект
PlayerWeightTracker
. Да, это костыль. Хук добавлю и уберу этот класс вообще.
Ивент хэндлеры в отдельный класс! И регать один раз, а не для каждого игрока!
Тут кода-то на 5 классов. Какой резон выносить хандеры в отдельный класс, если мод маленький? Я согласен, все должно быть на своем месте, но в меру. А для каждого игрока я их регал, т.к. привязывал поля
prevWeightClient
и
prevWeight
к конкретному игроку. Но опять же я выпилю это класс к чертовой бабушке.
Куча повторяющегося кода в ивент хэндлерах. Не красиво.
Только в трекере. Угадай что я с ним сделаю?
Типичный случай неумения работать с мапой. get вернет null, если ключ не найдет, поэтому не нужно доставать значение дважды.
Я выбрал такой способ потому что мне он кажется более удобочитаемым. Можно и проверкой на
null
, почему бы и нет.
И вообще должен быть метод getOrDefault
А вот это прикольно. Сделаем.
Не стоит все крашить, если в конфиге описан несуществующий айтем.
Можно и лог выводить, но мне больше нравится идея дать по шапке юзеру, чтобы заполнял конфиг нормально. Не маленький уже.
isOverloaded опять считает вес инвентаря. Зачем? Нужно доставать значение веса из трекера. getFreeSpace аналогично.
Мне ОЧЕНЬ не нравится идея обращаться к трекеру. Я думаю, что WeightProvider должен быть как можно более независим от других классов.
Ивенты в этих методах сомнительны. Не представляю жизнепригодного юзкейса. Только для костылей.
А вот мне видится один юзкейс: есть какой-то челик, у которого в сборке есть система веса и различные инвентари, поддерживающий этот апи. И все эти вещи с закрытым кодом. А ему нужно изменить малеха правила расчета перегруза (например). Так он запилит простенький модец, подпишится на
CalculateOverloadEvent
и сделает свое черное дело.
Я считаю, что мы не можем предусмотреть все юзкейсы. Но сделать хоть какую-то расширяемость мы можем. Вот затем тут и евенты.
Почему onMessage @SideOnly(Side.CLIENT)? У тебя класс не загрузится на выделенном сервере, потому что метод удалится.
А ты запусти. У меня все загружается как в IDE, так и в обфусцированном окружении. Да и этот метод вызовется только на клиенте, т.к. целевая сторона пакета
SyncMessage
- клиент. Такое у него предназначение - высылать таблицу весов, чтобы и на клиенте был аналогичный WeightProvider. Синхронизация эдакая.
Провайдеру не нужно поле config. Оно нужно только для инициализации. Зачем хранить постоянно?
Резонно
Почему пакет регистрирует систему веса? Пахнет костылем. Он должен пересылать данные системы и распаковывать их в существующую, а не создавать новую.
В данном случае WeightProvider инициализируется из конфига, который находится на сервере. А потом пересылает веса итемов на клиент (где кстати вместо системы веса -
шиш null). Ну на кой черт сперва создавать WeightProvider на клиенте, а потом ждать пока придет пакет с инфой? Почему бы не создавать провайдер, в момент когда пакет придет? Мой подход кажется мне более логичным.
И что опять за разделение на serverWeightProvider и clientWeightProvider? Зачем оно?
Потому что так меньше кода, чем создавать в SyncMessage поля с мапами весов. И более дешево.
Но мне не нравится в первую очередь само API.
Поделись что именно тебе не нравится. Я попытался свести конфликты к минимуму и сделать его как можно более расширяемым.
И спасибо за кодревью. Есть над чем поразмыслить.