Мережа

Мережа в Minecraft використовується для того, щоб клієнт і сервер могли спілкуватися один з одним. Мережа — це широка тема, тому ця сторінка поділена на кілька категорій.

Чому мережа важлива?

Пакети — це основна концепція мережі в Minecraft. Пакети складаються з довільних даних, які можуть надсилатися від сервера до клієнта і навпаки. Ознайомтеся з наведеною нижче схемою, яка наочно демонструє мережеву архітектуру в Fabric:

Зверніть увагу, що пакети є мостом між сервером і клієнтом; це тому, що майже все, що ви робите в грі, певним чином включає мережу, знаєте ви це чи ні. Наприклад, коли ви надсилаєте повідомлення чату, на сервер надсилається пакет із вмістом. Потім сервер надсилає ще один пакет усім іншим клієнтам із вашим повідомленням.

Пам’ятайте про одну важливу річ: сервер завжди працює, навіть у грі наодинці та LAN. Пакети все ще використовуються для обміну даними клієнту і сервера, навіть якщо ніхто інший не грає з вами. Коли говорять про сторони в мережі, використовуються терміни «логічний клієнт» і «логічний сервер». Інтегрований сервер для гри наодинці/LAN та виділений сервер є логічними серверами, але лише виділений сервер можна вважати фізичним сервером.

Коли стан між клієнтом і сервером не синхронізовано, ви можете зіткнутися з проблемами, через які сервер або інші клієнти не погоджуються з тим, що робить інший клієнт. Це часто називають «десинхронізацією». Під час написання власного мода вам може знадобитися надіслати пакет даних, щоб синхронізувати стан сервера та всіх клієнтів.

Вступ до мережі

Визначення корисного навантаження

INFO

Корисне навантаження — це дані, які надсилаються в пакеті.

Це можна зробити, створивши Java Record з параметром BlockPos, який реалізує CustomPacketPayload.

public record ClientboundSummonLightningPayload(BlockPos pos) implements CustomPacketPayload {
	public static final Identifier SUMMON_LIGHTNING_PAYLOAD_ID = Identifier.fromNamespaceAndPath(ExampleMod.MOD_ID, "summon_lightning");
	public static final CustomPacketPayload.Type<ClientboundSummonLightningPayload> TYPE = new CustomPacketPayload.Type<>(SUMMON_LIGHTNING_PAYLOAD_ID);
	public static final StreamCodec<RegistryFriendlyByteBuf, ClientboundSummonLightningPayload> CODEC = StreamCodec.composite(BlockPos.STREAM_CODEC, ClientboundSummonLightningPayload::pos, ClientboundSummonLightningPayload::new);

	@Override
	public Type<? extends CustomPacketPayload> type() {
		return TYPE;
	}
}

Водночас ми визначили:

• Identifier, який використовується для ідентифікації корисного навантаження нашого пакета. Для цього прикладу нашим ідентифікатором буде example-mod:summon_lightning.

public static final Identifier SUMMON_LIGHTNING_PAYLOAD_ID = Identifier.fromNamespaceAndPath(ExampleMod.MOD_ID, "summon_lightning");

• Загальнодоступний статичний екземпляр CustomPayload.Type для унікальної ідентифікації цього спеціального корисного навантаження. Ми будемо посилатися на цей ID як у нашому загальному, так і в клієнтському коді.

public static final CustomPacketPayload.Type<ClientboundSummonLightningPayload> TYPE = new CustomPacketPayload.Type<>(SUMMON_LIGHTNING_PAYLOAD_ID);

• Загальнодоступний статичний екземпляр PacketCodec, щоб гра знала, як серіалізувати/десеріалізувати вміст пакета.

public static final StreamCodec<RegistryFriendlyByteBuf, ClientboundSummonLightningPayload> CODEC = StreamCodec.composite(BlockPos.STREAM_CODEC, ClientboundSummonLightningPayload::pos, ClientboundSummonLightningPayload::new);

Ми також замінили type, щоб повернути наш ідентифікатор корисного навантаження.

@Override
public Type<? extends CustomPacketPayload> type() {
	return TYPE;
}

Реєстрація корисного навантаження

Перш ніж ми надішлемо пакет із нашим власним корисним навантаженням, нам потрібно зареєструвати його на обох фізичних сторонах.

Це можна зробити в нашому загальному ініціалізаторі за допомогою PayloadTypeRegistry.clientboundPlay().register, який приймає CustomPayload.Type і StreamCodec.

PayloadTypeRegistry.clientboundPlay().register(ClientboundSummonLightningPayload.TYPE, ClientboundSummonLightningPayload.CODEC);

Подібний метод існує для реєстрації корисних даних з клієнта до сервера: PayloadTypeRegistry.clientboundPlay().register.

Надсилання пакета до клієнта

Щоб надіслати пакет із нашим власним корисним навантаженням, ми можемо використати ServerPlayNetworking.send, який приймає ServerPlayer і CustomPayload.

Почнемо зі створення нашого предмета, Lightning Tater. Ви можете замінити use, щоб активувати дію під час використання предмета. У цьому випадку надішлімо пакети гравцям у рівень (світ) сервера.

public class LightningTaterItem extends Item {
	public LightningTaterItem(Properties properties) {
		super(properties);
	}

	@Override
	public InteractionResult use(Level level, Player user, InteractionHand hand) {
		if (level.isClientSide()) {
			return InteractionResult.PASS;
		}

		ClientboundSummonLightningPayload payload = new ClientboundSummonLightningPayload(user.blockPosition());

		for (ServerPlayer player : PlayerLookup.level((ServerLevel) level)) {
			ServerPlayNetworking.send(player, payload);
		}

		return InteractionResult.SUCCESS;
	}
}

Розгляньмо код вище.

Ми надсилаємо пакети лише тоді, коли дію розпочато на сервері, повертаючись раніше з перевіркою isClientSide():

if (level.isClientSide()) {
	return InteractionResult.PASS;
}

Ми створюємо екземпляр корисного навантаження з позицією користувача:

ClientboundSummonLightningPayload payload = new ClientboundSummonLightningPayload(user.blockPosition());

Нарешті, ми отримуємо гравців у рівні (світі) сервера через PlayerLookup і надсилаємо пакет кожному гравцеві.

for (ServerPlayer player : PlayerLookup.level((ServerLevel) level)) {
	ServerPlayNetworking.send(player, payload);
}

INFO

API Fabric надає PlayerLookup, набір допоміжних функцій, які шукатимуть гравців на сервері.

Для опису функціональності цих методів часто використовується термін «відстеження». Це означає, що сутність або чанк на сервері відомі клієнту гравця (в межах їх видимості), і сутність або блок-сутність повинні повідомити відстеження змін клієнтів.

Відстеження є важливою концепцією для ефективної роботи в мережі, щоб лише необхідні гравці отримували повідомлення про зміни шляхом надсилання пакетів.

Отримання пакета на клієнті

Щоб отримати пакет, надісланий із сервера до клієнта, вам потрібно вказати, як ви будете обробляти вхідний пакет.

Це можна зробити в ініціалізаторі клієнта, викликавши ClientPlayNetworking.registerGlobalReceiver і передавши CustomPayload.Type і PlayPayloadHandler, який є функціональним інтерфейсом.

У цьому випадку ми визначимо дію, яка буде запускатися в реалізації PlayPayloadHandler (як лямбда-вираз).

ClientPlayNetworking.registerGlobalReceiver(ClientboundSummonLightningPayload.TYPE, (payload, context) -> {
	ClientLevel level = context.client().level;

	if (level == null) {
		return;
	}

	BlockPos lightningPos = payload.pos();
	LightningBolt entity = EntityType.LIGHTNING_BOLT.create(level, EntitySpawnReason.TRIGGERED);

	if (entity != null) {
		entity.setPos(lightningPos.getX(), lightningPos.getY(), lightningPos.getZ());
		level.addEntity(entity);
	}
});

Розгляньмо код вище.

Ми можемо отримати доступ до даних із нашого корисного навантаження, викликавши методи отримання запису. У цьому випадку payload.pos(). Який потім можна використовувати для отримання позицій x, y і z.

BlockPos lightningPos = payload.pos();

Нарешті ми створюємо LightningBolt і додаємо його до рівня (світу).

LightningBolt entity = EntityType.LIGHTNING_BOLT.create(level, EntitySpawnReason.TRIGGERED);

if (entity != null) {
	entity.setPos(lightningPos.getX(), lightningPos.getY(), lightningPos.getZ());
	level.addEntity(entity);
}

Тепер, якщо ви додасте цей мод на сервер і коли гравець використовує наш Lightning Tater, кожен гравець побачить блискавку вражаючи позицію користувача.

Надсилання пакета до сервера

Подібно до надсилання пакета клієнту, ми починаємо зі створення спеціального корисного навантаження. Цього разу, коли гравець використовує отруйну картоплю на живій істоті, ми просимо сервер застосувати до неї ефект світіння.

public record GiveGlowingEffectServerboundPayload(int entityId) implements CustomPacketPayload {
	public static final Identifier GIVE_GLOWING_EFFECT_PAYLOAD_ID = Identifier.fromNamespaceAndPath(ExampleMod.MOD_ID, "give_glowing_effect");
	public static final CustomPacketPayload.Type<GiveGlowingEffectServerboundPayload> TYPE = new CustomPacketPayload.Type<>(GIVE_GLOWING_EFFECT_PAYLOAD_ID);
	public static final StreamCodec<RegistryFriendlyByteBuf, GiveGlowingEffectServerboundPayload> CODEC = StreamCodec.composite(ByteBufCodecs.INT, GiveGlowingEffectServerboundPayload::entityId, GiveGlowingEffectServerboundPayload::new);

	@Override
	public Type<? extends CustomPacketPayload> type() {
		return TYPE;
	}
}

Ми передаємо відповідний кодек разом із посиланням на метод, щоб отримати значення із запису для створення цього кодека.

Потім ми реєструємо наше корисне навантаження в нашому загальному ініціалізаторі. Однак цього разу як корисне навантаження з клієнта до сервера за допомогою PayloadTypeRegistry.serverboundPlay().register.

PayloadTypeRegistry.serverboundPlay().register(GiveGlowingEffectServerboundPayload.TYPE, GiveGlowingEffectServerboundPayload.CODEC);

Щоб надіслати пакет, додаймо дію, коли гравець використовує отруйну картоплю. Ми будемо використовувати подію UseEntityCallback, щоб зберігати речі стисло.

Ми реєструємо подію в нашому ініціалізаторі клієнта та використаємо isClientSide(), щоб гарантувати, що дія лише запускається на логічному клієнті.

UseEntityCallback.EVENT.register((player, level, hand, entity, hitResult) -> {
	if (!level.isClientSide()) {
		return InteractionResult.PASS;
	}

	ItemStack usedItemStack = player.getItemInHand(hand);

	if (entity instanceof LivingEntity && usedItemStack.is(Items.POISONOUS_POTATO) && hand == InteractionHand.MAIN_HAND) {
		GiveGlowingEffectServerboundPayload payload = new GiveGlowingEffectServerboundPayload(hitResult.getEntity().getId());
		ClientPlayNetworking.send(payload);

		return InteractionResult.SUCCESS;
	}

	return InteractionResult.PASS;
});

Ми створимо екземпляр нашого GiveGlowingEffectServerboundPayload з необхідними аргументами. У цьому випадку ID мережі цільової сутності.

GiveGlowingEffectServerboundPayload payload = new GiveGlowingEffectServerboundPayload(hitResult.getEntity().getId());

Нарешті, ми надсилаємо пакет на сервер, викликаючи ClientPlayNetworking.send з екземпляром нашого ``GiveGlowingEffectServerboundPayload`.

ClientPlayNetworking.send(payload);

Отримання пакета на сервері

Це можна зробити в загальному ініціалізаторі, викликавши ServerPlayNetworking.registerGlobalReceiver і передавши CustomPayload.Type і PlayPayloadHandler.

ServerPlayNetworking.registerGlobalReceiver(GiveGlowingEffectServerboundPayload.TYPE, (payload, context) -> {
	Entity entity = context.player().level().getEntity(payload.entityId());

	if (entity instanceof LivingEntity livingEntity && livingEntity.closerThan(context.player(), 5)) {
		livingEntity.addEffect(new MobEffectInstance(MobEffects.GLOWING, 100));
	}
});

INFO

Важливо, щоб ви перевірили вміст пакета на стороні сервера.

У цьому випадку ми перевіряємо, чи існує сутність, на основі її ID мережі.

No lines matched.

Крім того, цільова сутність має бути живою сутністю, і ми обмежуємо діапазон цільової сутності від гравця до 5.

No lines matched.

Тепер, коли будь-який гравець намагатиметься використати отруйну картоплю на живій істоті, до нього буде застосовано ефект світіння.