Tweaks to EnderIO travel + teleportation

[D-Cysteine]

This PR includes new, fully customizable controls for the Staff of Teleportation, as well as many fixes and tweaks.

New controls for the Staff of Teleportation

• Right-click now tries to teleport to an anchor, and teleports to player look if no anchor was found. This combines both modes of the original controls, which should hopefully be more fluid to use.
• Sneak right-click now teleports to player look, ignoring anchors. This was the original right-click behavior.
• While sneaking, travel anchors are now hidden, to avoid obstructing player vision.

New config options for the Staff of Teleportation

• teleportStaffOriginalControls (boolean): if true, restores the original controls
• teleportStaffAction (integer): sets the right-click action (overridden by teleportStaffOriginalControls)
• teleportStaffSneakAction (integer): sets the sneak right-click action (overridden by teleportStaffOriginalControls)

Action values:

• 0: Do nothing
• 1: Teleport to player look (same as original right-click action)
• 2: Teleport to anchor (same as original sneak right-click action)
• 3: Teleport to anchor, or to player look if no anchor

Tweaks and fixes

• Teleport through wall has been tweaked to be a bit more accurate. Trigger range increased from 3 to 4, and teleport distance increment changed from 2 to 0.5 (easier to teleport inside small spaces, like your EBF).
• Can now long-range teleport to anchors in unloaded chunks
  • I think the chunk needs to be loaded at least once per server restart, though
• Fixed blink placing player one block too high, causing suffocation sometimes
• Fixed weird bug where sometimes the wrong travel anchor would be selected. Anchor selection now uses a view angle check, just like long-range teleport
  • I think this bug was caused by a divide-by-zero here: https://github.com/GTNewHorizons/EnderCore/blob/8c0fc77c656ed5c0cd94c9f2653ba4b786194905/src/main/java/com/enderio/core/common/vecmath/Camera.java#L72
• Long-range teleport now checks for obstructed and inaccessible anchors

[github-actions]

Warning: 2 uncommitted changes
#159

[AbdielKavash]

I don't know how people use the staff, so please do complain here if these changes would make it harder to use.

R-click will try to teleport to an anchor (the current shift-R-click behavior), and teleport to look (the current R-click behavior) if no anchor was found.

This sounds like it would end up with accidental teleports to unwanted places if you just miss the anchor.

Additionally, anchors will now be hidden while sneaking, so that they don't obstruct your view.

This sounds backwards to me. I only want to see anchors when I actually want to teleport; a majority of time I would like them to stay hidden, so that they do not obstruct my view while working.

There is also a config option to restore the original controls.

This is maybe risking bloat a bit, but how about making two configs: one for right-click, and one for sneak-right-click; and allow the player to bind both to: "teleport to anchor", "teleport forward", "teleport to anchor if available, otherwise forward", or "none"?

[D-Cysteine]

I don't know how people use the staff, so please do complain here if these changes would make it harder to use.

R-click will try to teleport to an anchor (the current shift-R-click behavior), and teleport to look (the current R-click behavior) if no anchor was found.

This sounds like it would end up with accidental teleports to unwanted places if you just miss the anchor.

Yup, this is (IMHO) the potential problem with this change. I felt that the ease-of-use from being able to easily do both types of teleports without needing to hold shift offsets this, but if it doesn't, then this would be a bad change. That said, if you miss, you do end up teleporting where you are looking, which should in most cases be towards the anchor anyway, so you can just click again.

Additionally, anchors will now be hidden while sneaking, so that they don't obstruct your view.

This sounds backwards to me. I only want to see anchors when I actually want to teleport; a majority of time I would like them to stay hidden, so that they do not obstruct my view while working.

The current behavior is to always show anchors while holding the staff (active hotbar item), even though you can only teleport to them while holding shift. The new behavior will hide the anchors while holding shift (and holding the staff), because you can't teleport to them while holding shift. So we show the anchors less often with the new change.

There is also a config option to restore the original controls.

This is maybe risking bloat a bit, but how about making two configs: one for right-click, and one for sneak-right-click; and allow the player to bind both to: "teleport to anchor", "teleport forward", "teleport to anchor if available, otherwise forward", or "none"?

Good idea; added. I ended up keeping the original config too to make it easy to switch back, and also because having it on slightly changes how travel anchors are shown (they are always shown, regardless of holding shift).

---

As I was testing this, I kept finding more and more bugs, which I tried to fix, but this PR ended up growing a lot. I'll update the PR description with all of the stuff I changed.

[github-actions]

Warning: 2 uncommitted changes
#161

[AbdielKavash]

Extra comment:

Even though you can now teleport to unloaded anchors, they are not visible when holding the staff. This means that (a) if you actually want to use this feature, you have to remember where your anchor is, and blindly aim in the right direction; and (b) you can accidentally teleport to a far away anchor that you did not see when trying to use the forward teleport.

Unloaded anchors should therefore be made visible (this might require a more significant rework, as the client doesn't have the TE anymore), or this feature reconsidered.

[D-Cysteine]

Extra comment:

Even though you can now teleport to unloaded anchors, they are not visible when holding the staff. This means that (a) if you actually want to use this feature, you have to remember where your anchor is, and blindly aim in the right direction; and (b) you can accidentally teleport to a far away anchor that you did not see when trying to use the forward teleport.

Unloaded anchors should therefore be made visible (this might require a more significant rework, as the client doesn't have the TE anymore), or this feature reconsidered.

Thanks for all the comments!

Re: point (a): yes, it would be nice if we could render the anchors at long distance, but I couldn't get that to work; IIRC there is some hard-coded (or otherwise difficult to bypass) limit on Minecraft render range that prevents this from working. It probably wouldn't work well to render anchors at 2048 range anyway; I think they'd either be too small to click on, or large enough to obstruct vision.

The intended way to work around this is to mark travel anchors with JourneyMap waypoints. Also note that this behavior predates this PR; the staff of teleportation has always worked this way.

Point (b) is a good point; I feel that the convenience of being able to do both actions in one click outweighs it though, and it's also fairly unlikely that there would be a mystery travel anchor that close to a player's base. If it becomes a problem, it's always possible to change the action configs to only teleport to look, and ignore anchors.

[AbdielKavash]

Point (b) is a good point; I feel that the convenience of being able to do both actions in one click outweighs it though, and it's also fairly unlikely that there would be a mystery travel anchor that close to a player's base. If it becomes a problem, it's always possible to change the action configs to only teleport to look, and ignore anchors.

The setting I was imagining is a multiplayer server, where you try to teleport around in world, and the 10° cone eventually covers a huge area in the distance, and you accidentally teleport to someone else's base. But the 2048 blocks max range should to a degree prevent this too.

Let's leave it as it is/for future iteration. I would still like the renderer to be tweaked to show distant anchors; though if this is complicated then maybe for another time.

[AbdielKavash]

All looks good now. Nice work!