2021-03-22 23:06:40 +01:00
|
|
|
/*
|
|
|
|
|
* This file is part of ViaVersion - https://github.com/ViaVersion/ViaVersion
|
|
|
|
|
* Copyright (C) 2016-2021 ViaVersion and contributors
|
|
|
|
|
*
|
|
|
|
|
* This program is free software: you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
*/
|
2021-04-26 20:52:34 +02:00
|
|
|
package com.viaversion.viaversion.protocols.protocol1_14to1_13_2.metadata;
|
2019-05-09 14:43:48 +02:00
|
|
|
|
2021-04-26 20:52:34 +02:00
|
|
|
import com.viaversion.viaversion.api.Via;
|
2021-04-26 21:35:29 +02:00
|
|
|
import com.viaversion.viaversion.api.connection.UserConnection;
|
2021-04-27 13:41:39 +02:00
|
|
|
import com.viaversion.viaversion.api.minecraft.VillagerData;
|
2021-04-26 21:16:10 +02:00
|
|
|
import com.viaversion.viaversion.api.minecraft.entities.Entity1_13Types;
|
|
|
|
|
import com.viaversion.viaversion.api.minecraft.entities.Entity1_14Types;
|
|
|
|
|
import com.viaversion.viaversion.api.minecraft.entities.EntityType;
|
2021-04-26 20:52:34 +02:00
|
|
|
import com.viaversion.viaversion.api.minecraft.item.Item;
|
|
|
|
|
import com.viaversion.viaversion.api.minecraft.metadata.Metadata;
|
|
|
|
|
import com.viaversion.viaversion.api.minecraft.metadata.types.MetaType1_14;
|
2021-04-27 13:41:39 +02:00
|
|
|
import com.viaversion.viaversion.api.protocol.packet.PacketWrapper;
|
2021-04-26 20:52:34 +02:00
|
|
|
import com.viaversion.viaversion.api.type.Type;
|
|
|
|
|
import com.viaversion.viaversion.api.type.types.Particle;
|
|
|
|
|
import com.viaversion.viaversion.protocols.protocol1_14to1_13_2.Protocol1_14To1_13_2;
|
|
|
|
|
import com.viaversion.viaversion.protocols.protocol1_14to1_13_2.packets.InventoryPackets;
|
|
|
|
|
import com.viaversion.viaversion.protocols.protocol1_14to1_13_2.storage.EntityTracker1_14;
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
import com.viaversion.viaversion.rewriter.EntityRewriter;
|
2019-05-09 14:43:48 +02:00
|
|
|
|
|
|
|
|
import java.util.List;
|
|
|
|
|
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
public class MetadataRewriter1_14To1_13_2 extends EntityRewriter<Protocol1_14To1_13_2> {
|
2019-09-27 20:25:18 +02:00
|
|
|
|
|
|
|
|
public MetadataRewriter1_14To1_13_2(Protocol1_14To1_13_2 protocol) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
super(protocol);
|
2021-02-14 14:22:30 +01:00
|
|
|
mapTypes(Entity1_13Types.EntityType.values(), Entity1_14Types.class);
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
mapEntityType(Entity1_13Types.EntityType.OCELOT, Entity1_14Types.CAT); //TODO remap untamed ocelots to ocelots?
|
2019-09-27 20:25:18 +02:00
|
|
|
}
|
2019-05-09 14:43:48 +02:00
|
|
|
|
|
|
|
|
@Override
|
2019-05-09 14:46:24 +02:00
|
|
|
protected void handleMetadata(int entityId, EntityType type, Metadata metadata, List<Metadata> metadatas, UserConnection connection) throws Exception {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
metadata.setMetaType(MetaType1_14.byId(metadata.metaType().typeId()));
|
2019-05-09 14:43:48 +02:00
|
|
|
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
EntityTracker1_14 tracker = tracker(connection);
|
2019-05-09 14:43:48 +02:00
|
|
|
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.metaType() == MetaType1_14.Slot) {
|
2019-05-09 14:43:48 +02:00
|
|
|
InventoryPackets.toClient((Item) metadata.getValue());
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
} else if (metadata.metaType() == MetaType1_14.BlockID) {
|
2019-05-09 14:43:48 +02:00
|
|
|
// Convert to new block id
|
|
|
|
|
int data = (int) metadata.getValue();
|
2020-08-16 16:24:06 +02:00
|
|
|
metadata.setValue(protocol.getMappingData().getNewBlockStateId(data));
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
} else if (metadata.metaType() == MetaType1_14.PARTICLE) {
|
2020-12-09 12:41:26 +01:00
|
|
|
rewriteParticle((Particle) metadata.getValue());
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (type == null) return;
|
|
|
|
|
|
|
|
|
|
//Metadata 6 added to abstract_entity
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() > 5) {
|
|
|
|
|
metadata.setId(metadata.id() + 1);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 8 && type.isOrHasParent(Entity1_14Types.LIVINGENTITY)) {
|
2019-10-02 09:50:51 +02:00
|
|
|
final float v = ((Number) metadata.getValue()).floatValue();
|
|
|
|
|
if (Float.isNaN(v) && Via.getConfig().is1_14HealthNaNFix()) {
|
|
|
|
|
metadata.setValue(1F);
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-05-09 14:43:48 +02:00
|
|
|
|
|
|
|
|
//Metadata 12 added to living_entity
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() > 11 && type.isOrHasParent(Entity1_14Types.LIVINGENTITY)) {
|
|
|
|
|
metadata.setId(metadata.id() + 1);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
|
|
|
|
|
2021-02-14 14:22:30 +01:00
|
|
|
if (type.isOrHasParent(Entity1_14Types.ABSTRACT_INSENTIENT)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 13) {
|
2019-05-09 14:43:48 +02:00
|
|
|
tracker.setInsentientData(entityId, (byte) ((((Number) metadata.getValue()).byteValue() & ~0x4)
|
2019-09-27 20:25:18 +02:00
|
|
|
| (tracker.getInsentientData(entityId) & 0x4))); // New attacking metadata
|
2019-05-09 14:43:48 +02:00
|
|
|
metadata.setValue(tracker.getInsentientData(entityId));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-14 14:22:30 +01:00
|
|
|
if (type.isOrHasParent(Entity1_14Types.PLAYER)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (entityId != tracker.clientEntityId()) {
|
|
|
|
|
if (metadata.id() == 0) {
|
2019-05-09 14:43:48 +02:00
|
|
|
byte flags = ((Number) metadata.getValue()).byteValue();
|
|
|
|
|
// Mojang overrides the client-side pose updater, see OtherPlayerEntity#updateSize
|
|
|
|
|
tracker.setEntityFlags(entityId, flags);
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
} else if (metadata.id() == 7) {
|
2019-05-09 14:43:48 +02:00
|
|
|
tracker.setRiptide(entityId, (((Number) metadata.getValue()).byteValue() & 0x4) != 0);
|
|
|
|
|
}
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 0 || metadata.id() == 7) {
|
2019-05-09 14:43:48 +02:00
|
|
|
metadatas.add(new Metadata(6, MetaType1_14.Pose, recalculatePlayerPose(entityId, tracker)));
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.isOrHasParent(Entity1_14Types.ZOMBIE)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 16) {
|
2019-05-09 14:43:48 +02:00
|
|
|
tracker.setInsentientData(entityId, (byte) ((tracker.getInsentientData(entityId) & ~0x4)
|
2019-09-27 20:25:18 +02:00
|
|
|
| ((boolean) metadata.getValue() ? 0x4 : 0))); // New attacking
|
2019-05-09 14:43:48 +02:00
|
|
|
metadatas.remove(metadata); // "Are hands held up"
|
|
|
|
|
metadatas.add(new Metadata(13, MetaType1_14.Byte, tracker.getInsentientData(entityId)));
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
} else if (metadata.id() > 16) {
|
|
|
|
|
metadata.setId(metadata.id() - 1);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-14 14:22:30 +01:00
|
|
|
if (type.isOrHasParent(Entity1_14Types.MINECART_ABSTRACT)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 10) {
|
2019-05-09 14:43:48 +02:00
|
|
|
// New block format
|
|
|
|
|
int data = (int) metadata.getValue();
|
2020-08-16 16:24:06 +02:00
|
|
|
metadata.setValue(protocol.getMappingData().getNewBlockStateId(data));
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.is(Entity1_14Types.HORSE)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 18) {
|
2019-05-09 14:43:48 +02:00
|
|
|
metadatas.remove(metadata);
|
|
|
|
|
|
|
|
|
|
int armorType = (int) metadata.getValue();
|
|
|
|
|
Item armorItem = null;
|
|
|
|
|
if (armorType == 1) { //iron armor
|
2020-08-16 16:24:06 +02:00
|
|
|
armorItem = new Item(protocol.getMappingData().getNewItemId(727), (byte) 1, (short) 0, null);
|
2019-05-09 14:43:48 +02:00
|
|
|
} else if (armorType == 2) { //gold armor
|
2020-08-16 16:24:06 +02:00
|
|
|
armorItem = new Item(protocol.getMappingData().getNewItemId(728), (byte) 1, (short) 0, null);
|
2019-05-09 14:43:48 +02:00
|
|
|
} else if (armorType == 3) { //diamond armor
|
2020-08-16 16:24:06 +02:00
|
|
|
armorItem = new Item(protocol.getMappingData().getNewItemId(729), (byte) 1, (short) 0, null);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
|
|
|
|
|
2021-04-26 22:54:43 +02:00
|
|
|
PacketWrapper equipmentPacket = PacketWrapper.create(0x46, null, connection);
|
2019-05-09 14:43:48 +02:00
|
|
|
equipmentPacket.write(Type.VAR_INT, entityId);
|
|
|
|
|
equipmentPacket.write(Type.VAR_INT, 4);
|
|
|
|
|
equipmentPacket.write(Type.FLAT_VAR_INT_ITEM, armorItem);
|
|
|
|
|
equipmentPacket.send(Protocol1_14To1_13_2.class);
|
|
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.is(Entity1_14Types.VILLAGER)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 15) {
|
2019-05-09 14:43:48 +02:00
|
|
|
// plains
|
|
|
|
|
metadata.setValue(new VillagerData(2, getNewProfessionId((int) metadata.getValue()), 0));
|
|
|
|
|
metadata.setMetaType(MetaType1_14.VillagerData);
|
|
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.is(Entity1_14Types.ZOMBIE_VILLAGER)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 18) {
|
2019-05-09 14:43:48 +02:00
|
|
|
// plains
|
|
|
|
|
metadata.setValue(new VillagerData(2, getNewProfessionId((int) metadata.getValue()), 0));
|
|
|
|
|
metadata.setMetaType(MetaType1_14.VillagerData);
|
|
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.isOrHasParent(Entity1_14Types.ABSTRACT_ARROW)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() >= 9) { // New piercing
|
|
|
|
|
metadata.setId(metadata.id() + 1);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.is(Entity1_14Types.FIREWORK_ROCKET)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 8) {
|
2019-05-09 14:43:48 +02:00
|
|
|
if (metadata.getValue().equals(0))
|
|
|
|
|
metadata.setValue(null); // https://bugs.mojang.com/browse/MC-111480
|
|
|
|
|
metadata.setMetaType(MetaType1_14.OptVarInt);
|
|
|
|
|
}
|
2021-02-14 14:22:30 +01:00
|
|
|
} else if (type.isOrHasParent(Entity1_14Types.ABSTRACT_SKELETON)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 14) {
|
2019-05-09 14:43:48 +02:00
|
|
|
tracker.setInsentientData(entityId, (byte) ((tracker.getInsentientData(entityId) & ~0x4)
|
2019-09-27 20:25:18 +02:00
|
|
|
| ((boolean) metadata.getValue() ? 0x4 : 0))); // New attacking
|
2019-05-09 14:43:48 +02:00
|
|
|
metadatas.remove(metadata); // "Is swinging arms"
|
|
|
|
|
metadatas.add(new Metadata(13, MetaType1_14.Byte, tracker.getInsentientData(entityId)));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-14 14:22:30 +01:00
|
|
|
if (type.isOrHasParent(Entity1_14Types.ABSTRACT_ILLAGER_BASE)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() == 14) {
|
2019-05-09 14:43:48 +02:00
|
|
|
tracker.setInsentientData(entityId, (byte) ((tracker.getInsentientData(entityId) & ~0x4)
|
2019-09-27 20:25:18 +02:00
|
|
|
| (((Number) metadata.getValue()).byteValue() != 0 ? 0x4 : 0))); // New attacking
|
2019-05-09 14:43:48 +02:00
|
|
|
metadatas.remove(metadata); // "Has target (aggressive state)"
|
|
|
|
|
metadatas.add(new Metadata(13, MetaType1_14.Byte, tracker.getInsentientData(entityId)));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// TODO Are witch and ravager also abstract illagers? They all inherit the new metadata 14 added in 19w13a
|
2021-02-14 14:22:30 +01:00
|
|
|
if (type.is(Entity1_14Types.WITCH) || type.is(Entity1_14Types.RAVAGER) || type.isOrHasParent(Entity1_14Types.ABSTRACT_ILLAGER_BASE)) {
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
if (metadata.id() >= 14) { // TODO 19w13 added a new boolean (raid participant - is celebrating) with id 14
|
|
|
|
|
metadata.setId(metadata.id() + 1);
|
2019-05-09 14:43:48 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-02 15:09:50 +02:00
|
|
|
@Override
|
Refactor entity tracking and meta handling
This essentially merges the two approaches to the metadata handling from ViaVersion and ViaBackwards and improves on both designs.
ViaVersion did not track every single entity, but only those needed (at least in theory) and can work with untracked entities' metadata. It had a very simple method overridden by metadata rewriter implementations, directly operating on the full metadata list and manually handling meta index changes as well as item/block/particle id changes.
ViaBackwards on the other hand had to track *every single* entity and threw warnings otherwise - while less prone to errors due to giving obvious warnings in the console, it unnecessarily tracks a lot of entities, and those warnings also annoys users when encountering virtual entity plugins (operating asynchronously and sending update packets while already untracked or not yet tracked). Dedicated MetaHandlers made id changes and filtering a lot easier to read and write. However, the actual metadata list handling and its distribution to handlers was not very well implemented and required a lot of list copying and creation as well as exception throws to cancel individual metadata entries.
This version has MetaFilters built with a Builder containing multiple helper functions, and the entity tracking is properly given its own map, hashed by a Protocol's class, to be easily and generically accessible from anywhere with only a Protocol class from the UserConnection, along with more optimized metadata list iteration. The entity tracking is largely unchanged, keeping ViaVersion's approach to not having to track *all* entities (and being able to handle null types in meta handlers).
All of this is by no means absolutely perfect, but is much less prone to errors than both previous systems and takes a lot less effort to actually write. A last possible change would be to use a primitive int to object map that is built to be concurrency save for the EntityTracker, tho that would have to be chosen carefully.
2021-05-24 23:24:50 +02:00
|
|
|
protected EntityType typeFromId(int type) {
|
2019-10-02 15:09:50 +02:00
|
|
|
return Entity1_14Types.getTypeFromId(type);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-09 14:43:48 +02:00
|
|
|
private static boolean isSneaking(byte flags) {
|
|
|
|
|
return (flags & 0x2) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static boolean isSwimming(byte flags) {
|
|
|
|
|
return (flags & 0x10) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static int getNewProfessionId(int old) {
|
|
|
|
|
// profession -> career
|
|
|
|
|
switch (old) {
|
|
|
|
|
case 0: // farmer
|
|
|
|
|
return 5;
|
|
|
|
|
case 1: // librarian
|
|
|
|
|
return 9;
|
|
|
|
|
case 2: // priest
|
|
|
|
|
return 4; // cleric
|
|
|
|
|
case 3: // blacksmith
|
|
|
|
|
return 1; // armorer
|
|
|
|
|
case 4: // butcher
|
|
|
|
|
return 2;
|
|
|
|
|
case 5: // nitwit
|
|
|
|
|
return 11;
|
|
|
|
|
default:
|
|
|
|
|
return 0; // none
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static boolean isFallFlying(int entityFlags) {
|
|
|
|
|
return (entityFlags & 0x80) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public static int recalculatePlayerPose(int entityId, EntityTracker1_14 tracker) {
|
|
|
|
|
byte flags = tracker.getEntityFlags(entityId);
|
|
|
|
|
// Mojang overrides the client-side pose updater, see OtherPlayerEntity#updateSize
|
|
|
|
|
int pose = 0; // standing
|
|
|
|
|
if (isFallFlying(flags)) {
|
|
|
|
|
pose = 1;
|
|
|
|
|
} else if (tracker.isSleeping(entityId)) {
|
|
|
|
|
pose = 2;
|
|
|
|
|
} else if (isSwimming(flags)) {
|
|
|
|
|
pose = 3;
|
|
|
|
|
} else if (tracker.isRiptide(entityId)) {
|
|
|
|
|
pose = 4;
|
|
|
|
|
} else if (isSneaking(flags)) {
|
|
|
|
|
pose = 5;
|
|
|
|
|
}
|
|
|
|
|
return pose;
|
|
|
|
|
}
|
|
|
|
|
}
|
