Плагин меняющий прочность всех предметов на 1

Предлагаемое название: ZeroDurability

Версия сервера: Надо чтобы работало на 1.18.1

Что я хочу: Мне бы хотелось увидеть плагин(он очень простой), который менял бы прочность всех инструментов, брони и тп на 1(чтобы предметы ломались после первого использования).

Идеи для команд: Этому плагину команды не нужны

Когда мне это нужно? В течении недели, готов заплатить, если нужно(но в разумных пределах, мне уже делали подобный)

мой вк: https://vk.com/haidzzz

 

А зачем еще одних плагин если он у вас уже есть?

 

он не доработан, там ломаются только инструменты, а доработать самому или связаться с тем человеком у меня нет возможности.

 

https://drive.google.com/file/d/1UyLBBhemWoJ7tIRvMQB-Th-FIlkpWLQ0/view?usp=sharing

 

Не реализован ивент поломки при перемещении в инвентаре,
при ударе мечом об Entity он не становится поломанным,
прочность статична (10000) и выдаётся всем предметам с которыми взаимодействует игрок;
и если верить декодеру, то ещё и шедушер по какой-то чёрт.
Мой вариант:
http://plugins.moda84team.ru/ZeroDurability_1.0.3.jar
Плюсы:
Предмет будет поломанным сразу после крафта;
При ударе об Entity у него останется 1 удар до поломки;
Прочность зависит от предмета;
Имеется конфиг, который позволяет настроить нужные предметы, чтобы в случае чего можно было убрать (например, удочку);
Прочность выставляется не всем действующим предметам, а только из конфига;
Минусы:
Используется for для получения, а затем сравнения предмета для изменения его прочности;
Не реализован момент, что броня меняет прочность, если по ней ударить (но компенсируется это тем, что после крафта она будет уже поломана, а значит игрок без креатива/оператора не сможет выдать себе её)

 

• В конструкторе main() происходит попытка загрузить конфиг config.yml, но только в onEnable() проверяется его существования. Для справки: конструктор будет выполняться ДО onEnable(). Как следствие "Привет FileNotFoundException"
• Зачем делать `Logger log = Logger.getLogger("Minecraft");` если JavaPlugin уже имеет метод getLogger() ?? Или, если глобально смотреть, Bukkit.getServer().getLogger()
• Зачем нам в классе main `pm.registerEvents(this, this);`, если этот класс не предоставляет никакие EventHandler методы?
• Зачем List<String> переделывать в String[]? Про оптимизацию использования памяти не "кукарекать", т.к. в данном случае это "экономия на спичках".
  
• Что в классе craft, что в классе creative, используется for без break. Список состоит из 63 предметов. Если нужный предмет будет вторым в списке, цикл продолжит выполняться и дальше. Спрашивается Зачем, если мы уже нашли нужный тип предмета и совершили над ним необходимые операции??
• В дополнение к пред. двум пунктам: чем вам `for(String materialStr : plugin.Items)` не угодил?

Про остальные косяки я молчу, т.к. они не критичны, хоть и "воняют"

 

• 
  
  Вы плагин установить пробовали? Нету там "Привет FileNotFoundException", так как при проверки в Enable он его делает.

 

В чём здесь критичная ошибка? Используется отдельно просто и всё.

 

На случай если мне понадобиться доработать плагин и не забыть включить ивенты в main классе

 

Так как мне удобней работать с массивом ¯\_(ツ)_/¯

 

Согласен, вот тут косяк

 

Не сильно разбираюсь в for, поэтому использовал так, как умел.

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

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

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

Спасибо

 

То есть, чтобы критиковать, нужно непременно написать свою версию?
Вы зря обиделись, человек Вам указал на ошибки и предложил варианты замены.
Да, он сделал это грубовато, но верно. Если Вы к нему прислушаетесь, Ваш код будет более красивым. Разве это плохо?

 

<<
В конструкторе main() происходит попытка загрузить конфиг config.yml, но только в onEnable() проверяется его существования. Для справки: конструктор будет выполняться ДО onEnable(). Как следствие "Привет FileNotFoundException" >>
<<
Зачем List<String> переделывать в String[]? Про оптимизацию использования памяти не "кукарекать", т.к. в данном случае это "экономия на спичках". >>
<< Про остальные косяки я молчу, т.к. они не критичны, хоть и "воняют" >>

В этих "предложениях" я увидел просто, что человек хочет докопаться, как я и говорил выше:
всё это малозначительно, кроме:
<< Что в классе craft, что в классе creative, используется for без break. Список состоит из 63 предметов. Если нужный предмет будет вторым в списке, цикл продолжит выполняться и дальше. Спрашивается Зачем, если мы уже нашли нужный тип предмета и совершили над ним необходимые операции?? >>
А что я и ответил:
- "Согласен, вот тут косяк"

Остальное не так критично, просто у меня свой подход был в написании, так как я делал его в силу своих знаний вот и всё.
P.S (И по поводу того, что я раскритиковал первый предложенный вариант я могу сказать, что я предложил своё исправление, а не просто указал на ошибки)

 

Я не увидел там попытки докопаться. Он указал Вам на Ваши "детские" косяки, не более.
Я верю, что Вам удобнее работать с примитивными массивами String[]. Но почему бы не изучить List? Если следовать Вашей логике, то можно и в строку всё заджойнить. И да, это тоже будет работать.

Верю. Для примера "своего подхода" рекомендую поискать на Github "Мой первый калькулятор". Там тоже свой подход, безусловно. И нет сомнений в работоспособности этого калькулятора. Но реализация там просто огонь, да.

 

Действительно, его там нет. Но не из-за вашей "гениальности" в onEnable(), а из-за вашей же глупости. Скажите, а вы сами смотрели что у вас в коде происходит при выполнении? Вот вы создали <FileConfiguration configfile>, а где-нибудь используете? Нет. У вас везде
getConfig(). Зачем создавали <configfile> абсолютно не понятно.

Критического нет. Но вот зачем создавать ещё один логгер, когда разработчики Bukkit/Spigot уже предоставили вам логгер - совершенно не ясно. Это не критическая ошибка. Это глупость.

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

А что я по вашему был не прав и не справедлив к вашему коду? Вы опубликовали свою работу. Значит вы должны быть готовы к критике. Какой бы она не была.

GigiGgJBIRE, это я ещё не обосрал ваш код. Только так, указал на очевидные и глупые ошибки.

Если так настаиваете - держите: ZeroDurabilityPlugin.java
Из плюсов - можно указывать предметы из модов.