Fabric API

Fabric API

Mods
108M Downloads

Changing `FabricDimensions#teleport` behavior

apple502j opened this issue ยท 0 comments

commented

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 uses teleport 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, instead onPlayerTeleport 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?