[Removed] Granite. Враппер ванильного сервера 1.8.

UPD: Теперь это Sponge Vanilla.

Перспективное ядрышко на данный момент. Имеет вменяемое API, простое написание плагинов (объявление аннотациями, см. пример плагина), и не содержит кода ванильного кубача.
Имхо, одно из нормальных исполнений сервера.
Из минусов: Написано мало эвентов (почти их нету), использование рефлекций (изменённый minecraft_server.jar не пройдёт).

Спойлер: Пример плагина:

Код:

package me._Dereku.example;

import org.granitemc.granite.api.command.Command;
import org.granitemc.granite.api.command.CommandInfo;
import org.granitemc.granite.api.entity.player.Player;
import org.granitemc.granite.api.event.On;
import org.granitemc.granite.api.event.On.Priority;
import org.granitemc.granite.api.event.player.EventPlayerJoin;
import org.granitemc.granite.api.plugin.Plugin;
import org.granitemc.granite.utils.ChatFormatCodes;

/**
* @author Dereku
*/
//Регистрируем плагин
@Plugin(name = "Example Plugin", id = "example", version = "0.1")
public class Example{
    //Регистрируем команду
    @Command(name = "info", info = "Usage: /info", aliases = {})
    public void home(CommandInfo info) {
        if (info.getCommandSender().getName().equalsIgnoreCase("Server")) {
            info.getCommandSender().sendMessage("Command can be used only in-game.");
            return;
        }
        info.getCommandSender().sendMessage("Эта команда работает!");
    }
    //Регистрируем прослушиватель (Listener)
    @On(priority = Priority.NORMAL, event = EventPlayerJoin.class)
    public void epj(EventPlayerJoin event) {
        event.getPlayer().sendMessage(ChatFormatCodes.lightgreen + event.getPlayer().getName() + ", привет! ");
    }
}

Запустить сервер так же просто:
Качаем последнюю сборку Granite с Jenkins (или собираем с гитхаба, кому как приятнее), качаем ванильный сервер (линк для ленивых), переименовываем ванильный сервер вminecraft_server.jar, и запускаем Granite.

Спойлер: Пример файла start.bat:

Код:

@ECHO OFF
chcp 1251 > nul
java -jar Granite-v1.8-SNAPSHOT-*.jar
pause

Плагинов под ядро нету, т.к. ни форума, ни сайта, ни api, с которым можно работать нету.

Github
Jenkins

 

Так а в чем тогда "перспективность ядрышка"?

 

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

 

В том, что на него куда приятнее писать плагины.

В нём нету нормального API под пакеты. В нём нету API чата (приходится обрабатывать через пакеты, смотрим первое предложение).
Хотя да, со стороны простого серверодержателя радуга будет лучше, но со стороны пишущего плагины - радуга далеко не лучшая платформа, на которую нужно что либо писать.

 

Ну так пишешь разработчикам и они добавят API чата.[DOUBLEPOST=1412883701,1412883389][/DOUBLEPOST]что-то вроде этого

 

Против моста на ведро. Птому что он будет очень костыльный.

Там от меня будет большущая спискота. А я ленивый на текст.

 

Не. AuthMe пишется в течении 4 часов, AutoMessage за 15 минут. Не вижу причин, чтобы городить костыль в виде моста.

 

В Губке ведь тоже изначально закладывают какой-то репозиторий плагинов (а-ля DBO)?
Предлагаю сделать систему, похожую на управление линуксовыми пакетами.
Репозиторий содержит плагины, их разные версии. Каждый плагин указывает, с какими версиями ядра и других плагинов (зависимостей) он совместим — мета информация.
Ну а дальше, как админу удобно, что и когда обновлять, вручную или автоматически. Набор обычных команд. Могу помочь придумать для этого кусок API.

 

Эмм разве "это" приятнее, читается ужасно, куча ненужного мусора вида @Command() и после где то в недрах его реализации

Тот же функционал но для радуги ниже написал. Вот это вот приятно и понятно без кошмаров в виде "@on", все легко читается и понимается при том что функционал точно тоже что и в Вашем примере.

Код:

package plugintest;

import PluginReference.*;
/**
* @author Jamakasi
*/
public class MyPlugin extends PluginBase
{
    public static MC_Server server = null;
    public void onPlayerInput(MC_Player plr, String msg, MC_EventInfo ei){
        if(ei.isCancelled) return;
                //Регистрируем команду
        if(msg.equalsIgnoreCase("/info")){
            ei.isCancelled = true;
            plr.sendMessage(ChatColor.GREEN + "Эта команда работает!");           
            return;}
        }
        //Регистрируем прослушиватель (Listener)
    public void onPlayerJoin(MC_Player plr){
        plr.sendMessage(ChatColor.GREEN + "привет!");
    }
}

И теперь вывод: в граните практически нет вообще апи еще, при том что есть сейчас реализовано ужасно в стиле баккита, плагины никто еще вообще не пишет. У конкурентов уже наиприятнейший апи, львиная доля функционала уже в ядре(пермишены, приват, ве и т.д.), плагины писать одно удовольствие да и кроме того реализация в виде интеграции системы плагинов в ядро намного лучше в плане быстродействия чем обвеска куда хуками и т.д..[DOUBLEPOST=1412920710,1412920671][/DOUBLEPOST]Чуть не забыл, 22 строчки против 32.

 

Это в Радуге? Вовсе её не смотрел, но разумная идея. Я предлагал разрабам Sponge добавить в API высокоуровневые объекты (по типу как будто Vault всандалили бы внутрь Баккита), но sk89q вроде не поддержал, да и на текущем уровне реализации любого из всех заново стартанувших API это только отдалённое будущее, имхо. Пойду гляну Радугу, чтоле.

 

Даже радуга лучше этого, тут вообще апи нету (точнее пародия на апи).

 

Бгг. Что и требовалось доказать.

 

Идея регистрации плагинов через аннотации - полнейшее дерьмо.
Из-за этого ломается порядок загрузки классов, что приводит к невозможности использовать статическую и динамическую инициализацию. Также мешает делать плагин загружаемым под разные платформы в зависимости от точек входа.

 

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

 

Sponge это и делает.
Но есть одна проблема. Дело в том что сам по себе фордж почти неимеет ивентов и строится над ванильным майном из-за чего собственно и адово тормозит. В итоге проще напилить свою надстройку на ванилью чем ****ься с форджем. К тому же фордж выходит дай бог чтобы через 2 месяца после выхода официальной новой версии майнкрафта, это просто недопустимо для огромного количества серверов.