ошибка при отправке пакета

[qweqweqweqwe]

крашлог прикрепил, код пакета:

public class MyPacket extends Packet {
    public MyPacket() {}
    @Override
    public void server(EntityPlayerMP p) {
        // my code
    }
}

networkhandler

public class NetworkHandler {
    private short id = 0;
    public static final SimpleNetworkWrapper NETWORK = NetworkRegistry.INSTANCE.newSimpleChannel("mymod");
    public NetworkHandler() {
        register(MyPacket.class, Side.SERVER);
    }
    public static void sendToAllAround(Packet packet, World world, double x, double y, double z, double distance) {
        NETWORK.sendToAllAround(packet, new NetworkRegistry.TargetPoint(world.provider.dimensionId, x, y, z, distance));
    }
    private void register(Class<? extends Packet> packet, Side side) {
        try {
            NETWORK.registerMessage(packet.newInstance(), packet, id++, side);
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }
    }
}

packet:

public class Packet implements IMessage, IMessageHandler<Packet, Packet> {
    private ByteBuf buf;
    @Override
    public Packet onMessage(Packet sp, MessageContext ctx) {
        if (ctx.side.isServer())
            sp.server(ctx.getServerHandler().playerEntity);
        else
            sp.client(clientPlayer());
        return null;
    }
    protected ByteBuf buf() {
        return buf != null ? buf : (buf = Unpooled.buffer());
    }
    public void client(EntityPlayer player) {}
    public void server(EntityPlayerMP player) {}
    @Override
    public final void fromBytes(ByteBuf buf) {
        this.buf = buf;
    }
    @Override
    public final void toBytes(ByteBuf buf) {
        if (buf != null)
            buf.writeBytes(this.buf);
    }
    @SideOnly(Side.CLIENT)
    private EntityPlayer clientPlayer() {
        return Minecraft.getMinecraft().thePlayer;
    }
}

new NetworkHandler() делаю в postInit
читал что проблема в том что сторона куда пакет отправляю не зарегистрирована но не заметил где ошибся, прошу помощи
upd: другие пакеты как side.server так и side.client исправно воркают

 

[MJaroslav]

buf.writeBytes(this.buf);

Это че?

Делаешь в пакете поля, которые ты будешь передавать. Добавляешь еще один конструктор, где ты эти поля задаешь перед отправкой пакета. В read/write читаешь и пишешь поля по аналогии с read/write в NBT, в server/client добавь параметр с пришедшим пакетом (у тебя он там, откуда ты вызываешь эти методы), и из него дергай значения пришедшие.

И пере-/почитай этот гайд:

[1.7-1.13.2] Пакетная система

Предисловие: Данный ресурс научит вас, как надо правильно создавать, отправлять и регистрировать пакеты. Тема со временем будет наполнятся различными статьями, которые помогут вам решить ту или иную проблему. Так же убедительная просьба обратить...

forum.mcmodding.ru

 

[TheAndrey]

Жостко...

 private void register(Class<? extends Packet> packet, Side side) {
        try {
            NETWORK.registerMessage(packet.newInstance(), packet, id++, side);
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }
    }

Убирайте эту гадость. Оно никогда исключениям не бросается, только если творить лютую дичь.

Чтобы не было соблазна читать данные полученного пакета через this (это не работает, но IDE может дать вредный совет), IMessageHandler лучше повесить на статический класс внутри пакета и указывать его вместе с пакетом при регистрации.

 

[hohserg]

Можно использовать ElegantNetworking, код становится сильно проще и можно забыть о русной сериализации:

public class MyPacket implements ClientToServerPacket {
   //my data
   String value;

   public void onReceive(EntityPlayerMP sender){
      //my code
}
}

 

[qweqweqweqwe]

Жостко...

 private void register(Class<? extends Packet> packet, Side side) {
        try {
            NETWORK.registerMessage(packet.newInstance(), packet, id++, side);
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        }
    }

Убирайте эту гадость. Оно никогда исключениям не бросается, только если творить лютую дичь.

Чтобы не было соблазна читать данные полученного пакета через this (это не работает, но IDE может дать вредный совет), IMessageHandler лучше повесить на статический класс внутри пакета и указывать его вместе с пакетом при регистрации.

ide ругается

 

[qweqweqweqwe]

Это че?

Делаешь в пакете поля, которые ты будешь передавать. Добавляешь еще один конструктор, где ты эти поля задаешь перед отправкой пакета. В read/write читаешь и пишешь поля по аналогии с read/write в NBT, в server/client добавь параметр с пришедшим пакетом (у тебя он там, откуда ты вызываешь эти методы), и из него дергай значения пришедшие.

И пере-/почитай этот гайд:

[1.7-1.13.2] Пакетная система

Предисловие: Данный ресурс научит вас, как надо правильно создавать, отправлять и регистрировать пакеты. Тема со временем будет наполнятся различными статьями, которые помогут вам решить ту или иную проблему. Так же убедительная просьба обратить...

forum.mcmodding.ru

да я вот открыл гайд прочитал и ctrl+c ctrl+v, почему крашит игру так и не понял :|

 

[TheAndrey]

да я вот открыл гайд прочитал и ctrl+c ctrl+v

Гайд не из самых качественных. Учат плохому. Пакеты в большинстве случае имеют только одну сторону назначения, клиен-серверная мешанина совершенно ни к чему.

 

[qweqweqweqwe]

ноо почему то остальные пакеты работают :/ вообще не понимаю в чём дело

 

[TheAndrey]

Ничего сложного. Правильный пример.

// Заменить 12345 на ID пакета
network.registerMessage(ExampleMessage.Handler.class, ExampleMessage.class, 12345, Side.SERVER);

public final class ExampleMessage implements IMessage {

    // Данные нашего пакета. Делаем столько полей, сколько требуется
    public int buttonId;

    public ExampleMessage() {
    }

    @Override
    public void fromBytes(ByteBuf buf) {
        // Считываем данные при получении
        buttonId = buf.readByte();
    }

    @Override
    public void toBytes(ByteBuf buf) {
        // Записываем данные для отправки
        buf.writeByte(buttonId);
    }

    public static class Handler implements IMessageHandler<ExampleMessage, IMessage> {

        @Override
        public IMessage onMessage(ExampleMessage message, MessageContext ctx) {
            EntityPlayerMP player = ctx.getServerHandler().playerEntity;

            // тут наш код

            return null;
        }

    }
}

 

[qweqweqweqwe]

:| лол, записал рандомное значение в bytebuf и ошибка пропала, видимо проверка buf != null не так работает как должна.

 

[hohserg]

А можно было бы юзать EN и не париться

 

[TheAndrey]

А можно было бы юзать EN и не париться

Зато париться придётся с граблями

 

[Netrus]

А можно было бы юзать EN и не париться

Ненавижу….

 

[xmafee]

Ненавижу….

Самая удобная система пакетов из всех, которые я видел

 

[hohserg]

Ненавижу….

Если считаешь, что говно, то аргументируй

 

[qweqweqweqwe]

каждому своё :| бывают и любители говна

 

[hohserg]

Так ведь стандартный подход, который ты начал использовать, именно он говно
Потому что:

• Много шаблонного кода
• Отвлекает на постороннюю чушь, не имеющую отношения к бизнес-логике(это как раз про что этот вопрос)
  • ручная регистрация
  • ручная сериализация

Единственный плюс - отсутствие зависимостей

 

[TheAndrey]

Так ведь стандартный подход, который ты начал использовать, именно он говно

Каждому своё. Пакеты, это такая вещь где нужно всё тщательно контролировать.

• Шаблонный код? Копипаст решает.
• Ручная регистрация? Ничего сложного нет, если вы только не умудрились запилить сотню пакетов. Регистрация каждого в одну строчку, вообще ничего сложного.
• Чтение/запись данных да, может быть сложно, но теперь явно куда лучше чем в старых версиях. Всё разложено по полочкам, логика сериализации спрятана в IMessage, а сам мод работает с пакетами как объектами.

Библиотеку свою яро имеет смысл продвигать ленивым задницам, которые опустились до использования ObjectInputStream ...

 

[hohserg]

Шаблонный код плох сам по себе, если с ним работает программист, по двум причинам:

• трата времени
• люди легко ошибаются

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

На левой картинке - пакет стандартным способом. Бизнес-логика, то ради чего ваще пишется пакет, выделена зеленым. Шум выделен красным.
На правой картинке - элегантный пакет. Шума заметно меньше.

Библиотеку свою яро имеет смысл продвигать ленивым задницам, которые опустились до использования ObjectInputStream ...

EN использует не ObjectInputStream, фреймворк генерирует логику сериализации во время компиляции, тот же самый код, который вы могли бы писать сами. Могли бы, но теперь это не нужно: ваши руки и разум освобождены для более интересных и полезных задач. Это актуально для любого проекта и любого разработчика, а не только для ленивых задниц.

 

[TheAndrey]

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

Меня неправильно поняли. Речь о людях, которым реально лень писать свою сериализацию/десериализацию, они находят ObjectInputStream как решение это задачи, тем самым делая огромную дыру в безопасности. Им EN даже в его текущем виде - это Must have.

Почему хейтят EN? Да потому что он не такой простой, как кажется на первый взгляд. Интеграция в сборку проекта - это зло. Чем больше «магии» в сборке проекта, тем выше вероятность что сборка проекта сломается к чертям при обновлении Gradle и починить это будет непросто. Я не раз видел жалобы людей на то что у них что-то там не работает после добавления EN.

Хорошая библиотека должна быть простой как швейцарский нож: подключил в classpath и работаешь. Может тогда моё отношение к EN изменится.