Плагин [GEN] rscPermissions v0.10.x — идеальный менеджер прав для мультисерверных сред [1.2.5 - 1.10.x]

Код:

INSERT INTO `rscp_permissions`
   (`entity`, `entity_type`, `permission`, `value`)
VALUES
   ('vip',    b'0', 'essentials.time.set', b'1'),
   ('helper', b'0', 'essentials.time.set', b'1');

Значения первичного ключа id выставит сервер, остальные будут NULL или 0, по умолчанию.
Имхо, незачем ради одного пермишена делать ещё одну группу =\

 

Не хочет добавлять, потому что уже есть в столбце permission значение "essentials.time.set", а на столбце permission стоит ключ 'PRIMARY' (основной), и еще одно значение essentials.time.set не хочет добавлять
Замучил вас и себя

 

Не страшно, это моя обязанность, как автора

Давайте вместе посмотрим на структуру ключей таблицы permissions:

Спойлер: На всякий случай привожу код Deployment.sqlt

Код:

CREATE TABLE IF NOT EXISTS `{DATABASE}`.`{PREFIX}entities` (
   `id`          INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
   `entity`      VARCHAR(64)      NOT NULL,
   `entity_type` TINYINT(1)       NOT NULL,
   `prefix`      VARCHAR(48)               DEFAULT NULL,
   `suffix`      VARCHAR(48)               DEFAULT NULL,
   `lifetime`    TIMESTAMP            NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `id_UNIQUE` (`id`),
    UNIQUE KEY `entity_UNIQUE` (`entity`, `entity_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET='utf8' COLLATE 'utf8_general_ci';

CREATE TABLE IF NOT EXISTS `{DATABASE}`.`{PREFIX}permissions` (
    `id`           INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `entity`       VARCHAR(64)      NOT NULL,
    `entity_type`  TINYINT(1)       NOT NULL,
    `permission`   VARCHAR(255)     NOT NULL,
    `value`        BIT(1)           NOT NULL DEFAULT b'1',
    `destination`  VARCHAR(255)     NOT NULL DEFAULT '',
    `expirience`   SMALLINT(6)      NOT NULL DEFAULT 0,
    `lifetime`     TIMESTAMP            NULL DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `id_UNIQUE` (`id`),
    UNIQUE KEY `permission_UNIQUE` (`entity`, `entity_type`, `permission`, `destination`, `expirience`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET='utf8' COLLATE 'utf8_general_ci';

CREATE TABLE IF NOT EXISTS `{DATABASE}`.`{PREFIX}inheritance` (
    `id`                   INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
    `entity`               VARCHAR(64)      NOT NULL,
    `parent`               VARCHAR(64)      NOT NULL,
    `inheritance_type`     TINYINT(1)       NOT NULL,
    `inheritance_priority` SMALLINT(6)      NOT NULL DEFAULT '20',
    `destination`          VARCHAR(255)     NOT NULL DEFAULT '',
    `expirience`           SMALLINT(6)      NOT NULL DEFAULT 0,
    `lifetime`             TIMESTAMP            NULL DEFAULT NULL,
    PRIMARY KEY (`id`, `entity`),
    UNIQUE KEY `id_UNIQUE` (`id`),
    UNIQUE KEY `inheritance_UNIQUE` (`entity`, `parent`, `inheritance_type`, `destination`, `expirience`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET='utf8' COLLATE 'utf8_general_ci';

Ключ PRIMARY относится только к колонке id. Если бы мы имели проблему с колонкой permission, проблема была бы в ключе permission_UNIQUE, и то только в том случае, если все остальные колонки (entity, entity_type, destination и expirience) были бы заполнены аналогично уже имеющейся в БД строке.

Я попробовал приведённый мной выше код у себя, всё нормально!

Может быть Вы случайно поставили сами ключ PRIMARY на колонку permission, сняв его с id?
Если хотите, дайте мне доступ к БД в ЛС, я попробую самостоятельно посмотреть, что у Вас происходит.

 

Еще бы знать, как это сделать. Я новичок в настройках серверов, а внешнего доступа к sql сервер не настроил.
Дамп таблицы _permissions. Таблица сгенерирована командой /rscp examplerow

Код:

CREATE TABLE IF NOT EXISTS `rscp_permissions` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `entity` varchar(64) NOT NULL,
  `entity_type` tinyint(1) NOT NULL,
  `permission` varchar(255) NOT NULL,
  `value` bit(1) NOT NULL DEFAULT b'1',
  `destination` varchar(255) NOT NULL DEFAULT '',
  `expirience` smallint(6) NOT NULL DEFAULT '0',
  `lifetime` timestamp NULL DEFAULT NULL,
  UNIQUE KEY `id_UNIQUE` (`id`),
  PRIMARY KEY (`permission`),
  UNIQUE KEY `permission_UNIQUE` (`entity`,`entity_type`,`permission`,`destination`,`expirience`),
  KEY `permission` (`permission`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=671 ;

Я снял ключи со столбца permissions и все права записались

 

Хм, а вот тут как раз и имеются проблемы поменяйте ключ PRIMARY KEY на колонку id.
И удалите совсем ключ permission.

/rscp examplerows не создаёт таблицы, а только делает вставку. Попытка создания происходит каждый раз при включении плагина и присоединении к БД.
Если есть желание, давайте посмотрим на дампы двух других таблиц. А чем Вы пользуетесь для работы с БД?
Я и @chief провели некоторые исследования, и сделали вывод:
phpMyAdmin — е*у*ая *у*ня. Не используйте его, лучше HeidiSQL или MySQL Workbench.
Ну, либо же вы сами ответственны за его и свои косяки

 

Это делает как раз таки Essentials

 

Пользуемся тем, что есть)

Tssentials берет валюту только за пользование своих команд. Проблема в том, что на сервере стоит не один essentials

 

@MySt1k @chief @Morok @maximcs1
Ребят, я хочу разобраться с Essentials, почему в нём нету префиксов, но я никогда с ним не имел ничего общего. Не могли бы Вы мне немного помочь?

У меня есть чистая сборка последнего Spigot 1.8, ничего лишнего. Скиньте мне мне архив, в котором будет настроенный как Вам надо Essentials и, если есть, плагин чата: только 1-2 папки конфигов и 1-2 конкретных .jar.
Я вставлю это в ./plugins/ и буду гонять в дебаге.

 

EssentialsChat не может брать префиксы, только названия групп. В настройках чата можно задать префикс для некоторых групп. Простите, что не сказал раньше. Есть Essentials Pre для версии 1.7.10 и на этом он скончался . Еще есть SpigotEssentials но он находится в стадии разработки. Я посмотрю, как там дела с префиксами и отпишусь.
https://hub.spigotmc.org/jenkins/job/Spigot-Essentials/lastBuild/

Код:

  group-formats:
   Admins: '&c[{GROUP}]&r {DISPLAYNAME}&7:&c {MESSAGE}'

Admins - Название группы в плагине суперправ
{WORLDNAME} - Мир, из которого сообщение отправилось
{GROUP} - Отображение группы суперправ
{DISPLAYNAME} - Никнейм игрока
{MESSAGE} - Сообщение
Префиксы не берет с суперправ
Столкнулся с такой ошибкой

Код:

[18:21:08] [Server thread/INFO]: chief[/xxx.xxx.xxx.xxx:23413] logged in with entity id 168 at ([Pixel] 124.5, 66.0, -141.5)
[18:21:11] [rscp:RegionUpdateObserver/WARN]: Exception in thread "rscp:RegionUpdateObserver"
[18:21:11] [rscp:RegionUpdateObserver/WARN]: java.lang.IncompatibleClassChangeError: Found class com.sk89q.worldguard.protection.ApplicableRegionSet, but interface was expected
[18:21:11] [rscp:RegionUpdateObserver/WARN]:     at ru.simsonic.rscPermissions.Bukkit.BukkitRegionProviders.isRegionListChanged(BukkitRegionProviders.java:89)
[18:21:11] [rscp:RegionUpdateObserver/WARN]:     at ru.simsonic.rscPermissions.Bukkit.RegionUpdateObserver.run(RegionUpdateObserver.java:35)
[18:21:11] [rscp:RegionUpdateObserver/WARN]:     at java.lang.Thread.run(Thread.java:745)

Стоит WorldGuard 5.9 (Нагрузка на сервер ниже)
Такое происходит при подключении к серверу

 

Ну, да, я под WG 6 компилирую. Ничего страшного, просто отключается поддержка прав и наследований в зависимости от названия региона.

 

Ага, помню такое в описании. Спасибо.

 

Вышла версия v0.9.13b:

• Отладочная информация в консоли при вводе оттуда /rscp debug:
  Спойлер: Скриншот

  
  Вполне надеюсь, что это поможет найти, почему в Essentials нет префиксов. Хотя они могут появится в этой версии, проверьте пжлст.
• Чуть более адекватно предоставляет другим плагинам названия имеющихся групп и информацию о них.
• Корректно распознаёт устаревший WG (5.9 и ранние), сообщая об этом в консоль.
• Другие вообще прям мелкие мелочи.

 

Надо скрыть эту информацию

Код:

[22:03:50 INFO]: [rscp] integration.worldguard-old
[22:03:51 INFO]: [rscp] integration.worldguard-old
[22:03:52 INFO]: [rscp] integration.worldguard-old
[22:03:53 INFO]: [rscp] integration.worldguard-old
[22:03:54 INFO]: [rscp] integration.worldguard-old
[22:03:55 INFO]: [rscp] integration.worldguard-old
[22:03:56 INFO]: [rscp] integration.worldguard-old
[22:03:57 INFO]: [rscp] integration.worldguard-old
[22:03:58 INFO]: [rscp] integration.worldguard-old
[22:03:59 INFO]: [rscp] integration.worldguard-old

Лучше уберите вообще эту проверку. Если worldguard 5.9 и ниже, то пусть вообще отключается проверка регионов.

 

Она и должна была быть показана один раз, пофикшено. Версия называется также, сборка #183.
P.S. Странно, вроде строка переведена должна быть Удалите russian.yml/english.yml, может он их почему-то заменить не может

 

С языковыми файлами я сам нахимичил. Поставил запрет на перезапись. Еще толком не розибрася с Linux, но смог ускорить запустите сервера на 50 секунд, tps вырос на 2% и стал стабильнее. Жаль, что больше 10 игроков на нем не будут играть
После автоматического обновления прав с бд, права оператора автоматически аннулируются. С одной стороны это очень полезно но с другой очень не удобно.

 

В конфиге есть настройка:

Если она включена (по умолчанию), плагин выдаёт Статус оператора сервера всем, кто имеет пермишен *, и забирает у остальных. Если отключена, то плагин никак не влияет на то, кто является оператором, а кто нет.

Смысл в том, что а зачем операторство игроку без * (в её понимании, которое привил всем PEx), и, наоборот. Мой плагин не делает инъекций как делал когда-то PEx, и статус оператора — вполне себе аналог пексовской звёздочки.

 

Сделайте возможность отключения автоматического обновления данных с бд. Эта функция полезная но не всегда нужная.

 

Работа только с json? Зачем?! Я-то сделаю, это не сложно, но какова цель?

Держи: https://ci.methuselah.ru/job/rscPermissions/186/
Нужно выставить в конфиге задержку перечитывания меньшую или равную нулю.

 

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

 

Обновление прав (в том числе и сам запрос к удалённому MySQL серверу) всё равно происходит в параллельном потоке, и оно никак не влияет на игровой цикл.

В любом случае, фишка уже закоммичена в исходники.