Changing `FabricDimensions#teleport` behavior
apple502j opened this issue ยท 0 comments
TL;DR: I'd like to change the behavior of FabricDimensions#teleport
for players, or introduce a new method with a different behavior.
Why?
The current code applies several Mixins to Entity#moveToWorld
and ServerPlayerEntity#moveToWorld
, which the API calls. The fact that there are 2 implementations, and that they both hardcode several vanilla dimension-specific behavior, makes it hard to maintain.
moveToWorld
is used by portals, and all logics normally triggered by a portal - like placement checks - are in this method. This is contrary to the API's specified behavior, that it "will circumvent Vanilla's portal placement code". While we could continue to patch every bit of vanilla-specific code, they have to be duplicated due to the overriding in ServerPlayerEntity, and it's very hard to keep track of the changes.
Plus, it's not always clear what behavior it should offer, and what not to.
Suggested Changes
Luckily, there is another method, for ServerPlayerEntity at least, that offers some solution: ServerPlayerEntity#teleport(World, double, double, double, float, float)
. This is used by /tp
while moveToWorld
is used by portals.
There are a few reasons for this change:
- The method name and javadoc says it will teleport. It makes sense to align the behavior with
/teleport
, which usesteleport
method for players. (Entities are simply re-created.) - It reduces the amount of mixins, as
teleport
method contains no dimension-specific code. - It defines the behavior more clearly.
A few potential downsides:
- It shifts responsibilities of certain stuff to mods.
- Player teleport behavior might be inconsistent with entities.
Behavior Changes
With this change, there are mostly 2 behavior changes:
ServerWorld#onPlayerChangeDimension
is no longer called, insteadonPlayerTeleport
is called. This affects mixins hooked on that method.- Portal sound no longer plays?
Questions
- Should we do this?
- If so, should we change the behavior of the existing method, or create a new method?
- If we make it a new method, what should we call it?