| Только для Java Edition и Bedrock Edition |
Блок-сущность (англ. Block entity, ранее тайл-сущность) — блок, имеющий дополнительные данные, связанные с ним, помимо его ID.
Блоковые сущности имеют дополнительные данные об определённых блоках, типы которых варьируются в зависимости от блока. В некоторых случаях, эта информация служит для лучшего отображения модели, такие как книга на столе зачаровывания. В других случаях, она используется для хранения предметов внутри объекта. Блоки-сущности можно двигать поршнями. [ Только для Bedrock Edition ]
Этот список содержит блоки, имеющие такие данные.
Доброго времени суток, уважаемые модмейкеры. В данной статье я предоставляю свой перевод гайда с сайта shadowfacts по работе с TileEntity (1.12.2). Исходный туториал значительно доработан и кроме того адаптирован для версии 1.7.10. Исходники разобранного примера на GitHub: 1.7.10 и 1.12.2. Приятного чтения.
Изначально туториал содержал метку «Перевод», однако оригинальное содержимое сильно переработано, описана синхронизация и дополнительно добавлена информация для версии игры 1.7.10. Всвязи с этим я позволил себе убрать метку, однако ссылку на исходную статью оставляю.
Это первый туториал из серии статей о TileEntity.
В Майнкрафте класс Block используется для представления не просто единичного блока в мире, а блока как типа. Инстанс (экземпляр) Block содержит свойства для каждого экземпляра вашего блока, существующего в мире. Если мы хотим что бы наш блок содержал уникальные данные для каждого отдельно взятого экземпляра нам нужно использовать TileEntity.
Существует распространённый миф что TileEntity плохо влияет на производительность — это не так. Они могут негативно влиять на производительность если они реализованы не умело, как в прочем и любые другие объекты.
Тайлы бывают двух типов: обновляющиеся (ticking) и не обновляющиеся (non—ticking).
Обновляющиеся тайлы обновляются каждый игровой тик (обычно 20 раз в секунду). Они влияют на производительность интенсивнее и требуют аккуратной реализации. Не обновляющиеся тайлы существуют для простого хранения данных. Ну а теперь подробнее по реализации:
Все создаваемые тайлы обновляются автоматически, что значит метод updateEntity() вызывается каждый тик. Отключить обновление можно переопределив canUpdate() и вернув в нём false ( true по умолчанию).
Класс TileEntity лишён реализации автоматического обновления по умолчанию. Если обновление необходимо, то реализуйте интерфейс ITickable, который добавит метод update() .
Разделение: клиент и сервер
Сразу отмечу что изменение данных, хранимых в тайле должно происходить только на серверной стороне. Перед их изменением мы должны удостовериться, что действия происходят на сервере. Делаем мы это потому как в Майнкрафте клиент и сервер полностью разделены и некоторые методы вызываются для обеих сторон.
В многопользовательской игре множество клиентов подключены к одному серверу. В этом случае разделение между сторонами очевидно, но в одиночной игре всё немного сложнее. В многопользовательской игре сервер, к которому происходит подключение, отражает физический сервер и все отдельные подключенные клиенты являются физическими клиентами.
В одиночной игре клиент и сервер тоже разделены даже несмотря на то, что они исполняются на одном компьютере (на одной JVM, но в разных потоках). В одиночной игре клиент подключается к локальному, приватному серверу, функции которого схожи с физическим сервером. В этом случае серверный поток отражает логический сервер, а клиентский поток отражает логический клиент, так как обе логические стороны выполняются на одной физической стороне.
Поле World#isRemote используется для проверки стороны, на которой происходит выполнение (будь она логической или физической). Оно равно true для физического клиента в многопользовательской игре и для логического клиента в одиночной игре. Это поле равно false для физического сервера в многопользовательской игре и для логического сервера в одиночной.
Делая проверку в условии !World#isRemote , мы обеспечиваем уверенность что действия будут производится на сервере (физическом или логическом).
Хранение данных TileEntity между сессиями обеспечивается NBT. Данный формат используется для хранения данных в виде пар ключ-значение, которые легко сериализуется в байты и сохраняется на диск. Вы можете ознакомиться с классом NBTTagCompound для представления о типах данных, которые он может хранить. Ванильный код содержит множество хороших примеров по сохранению и чтению сложных структур данных.
В рамках статьи я покажу как создать простой тайл без обновления, предназначенный для простого хранения данных. В конце дополнительно описана организация синхронизации данных с клиентом при их изменении на сервере.
Прежде чем мы создадим тайл, мы добавим класс, который упростит их создание в будущем.
В первую очередь создадим класс BlockTileEntity:
Туда идут: сундуки,сейфы,шкафы,лампы,факела,поршни,плутоний,уран ну и т.д
0
| 0 |
| 0 |
| 0 |
| 0 |
|
Чего, я тебе не изменял. ;D xD Редактировалось 1 раз(а), последний 2016-03-07 22:23:36  (Пока оценок нет) Загрузка...detector |