@fromgate, можно как-то в GUI-меню предотвратить закрытие меню при клике на предмет? Вариант с вызовом того же меню при нажатии не найс, так как немного напрягает такое "мигание" ._.
Может, создать ещё один пункт в описании слота - close: deny\allow?
--------------------
Можно ли усовершенствовать описание предмета при его выдаче, добавив эффект, которым обладают зелья? То есть, хотелось бы создавать кастомные колбы с эффектами. Essentials так умеет только командой...
Ещё одна огроменная идея в плане реализации: составление Lore для предмета "на ходу".
Пример: есть три игрока с правами. У первого есть право "1", у второго - "1", "2" и у третьего - "1", "3"
Для, например, третьего игрока должно быть выведено меню с описанием прав на предмете, которыми он обладает в данный момент.
Как я представляю себе это:
Есть БД, в которой перечислены все права и их описания под номерами. Например:
LoreNumber1=perm:1 lore:{@Вы можете@использовать команду /1}
LoreNumber2=perm:2 lore:{@Вы можете@использовать команду /2}
LoreNumber3=perm:3 lore:{@Вы можете@использовать команду /3}
Заметьте, что перед началом каждого описания я написал символ переноса строки. Это по тому, что мы добавляем текст в Lore. Хотя, для удобства здесь можно было бы принять по-умолчанию, что добавляется именно новая строка.
Так же есть БД с предметами. Ну, например:
Начнём составление "динамичного lore". Для начала, нужно проверять игрока на предмет обладания правом. Это флаг. Значит, будет несколько активаторов в связке, которые на выходе формируют окончательное Lore. Но обо всём по порядку.
Итак, есть первый активатор Exec1, который добавляет к Lore "окончательного" предмета строку 1 при условии, что проверка на присутствие права "1" прошла успешно:
Код:
SetLore=item:ItemNumber1 lore:LoreNumber1
Этим действием мы добавили строку Lore из первой БД к "динамическому предмету". Думаю, его можно назвать так.
Во втором активаторе Exec2 идёт проверка на обладание правом "2", которая выдаёт false, а после третья проверка в активаторе Exec3 на присутствие права "3" соответственно. И, так как право "3" присутствует, выполняется действие:
Код:
SetLore=item:ItemNumber1 lore:LoreNumber3
Далее идёт четвёртый активатор, который запускает долгожданное меню с одним предметом. Будем использовать файл меню. В строке предмета напишем следующее:
И того, у нас получится предмет с Lore, которое полностью описывает права, которыми обладает игрок, запустивший эту цепочку.
Но, согласитесь, что не очень удобно проверять КАЖДОЕ право. Ведь, игроки и так обладают начальным набором прав? По этому, можно записать все стандартные права в другие предметы, а под новые отвести отдельный предмет. Ещё есть вариант совмещения обычного Lore и "динамического", которое создаём мы.
Делать это можно было бы в той же ITEM-БД. То есть, мы не просто создаём кастомный ID для использования его дальше. Мы можем задать и своё описание предмету в этой БД, к которой будет добавляться новое описание. Например:
Код:
ItemNumber1=item:Имя_Бумаги@Начальное_описание_бумаги$339*12
Интересно, а что же делать с "изменённым" "динамическим предметом"? Он же так и остаётся в памяти, с такими же параметрами. Можно создать отдельное действие, которое бы сбрасывало наше кастомное Lore. Или можно сразу сбрасывать до стандартного Lore, что есть в ITEM-БД
Но, второй способ будет лишним, если мы создаём эдакий квест, где от каждого шага зависит успех решения головоломки. Например, нужно ходить по разным местам, разгадывая загадки. За разгадку к "динамическому предмету" будет добавляться символ кода, который будет служить паролем, допустим, к какой-то двери, которая активируется командой с аргументом, который игрок "насобирал".
В общем, очень интересно было бы поиграться с "динамический описанием"
Теперь я окончательно зашел в тупик.
) и возможность использовать предметы в виде переменных (Тогда, к примеру, можно будет запоминать предмет в виде переменной, изымать его, а потом выдавать обратно 
с нетерпением, а по поводу "переименования" я имел ввиду, чтобы добавить возможность проверки только по ID, без названия и Lore...
