-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tweaks to EnderIO travel + teleportation #158
Conversation
Warning: 2 uncommitted changes |
This sounds like it would end up with accidental teleports to unwanted places if you just miss the anchor.
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.
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"? |
Co-authored-by: GitHub GTNH Actions <>
* Allow TP to unloaded anchor * Improve TP through wall by checking every 0.5 instead of 2 distance * Fix blink placing player one block too high * Fix anchor being incorrectly selected sometimes by constraining to visual angle
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.
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.
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. |
Warning: 2 uncommitted changes |
Co-authored-by: GitHub GTNH Actions <>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/main/java/crazypants/enderio/teleport/TravelController.java
Outdated
Show resolved
Hide resolved
src/main/java/crazypants/enderio/teleport/packet/PacketLongDistanceTravelEvent.java
Show resolved
Hide resolved
src/main/java/crazypants/enderio/teleport/TravelController.java
Outdated
Show resolved
Hide resolved
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. |
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. |
All looks good now. Nice work! |
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
New config options for the Staff of Teleportation
teleportStaffOriginalControls
(boolean): iftrue
, restores the original controlsteleportStaffAction
(integer): sets the right-click action (overridden byteleportStaffOriginalControls
)teleportStaffSneakAction
(integer): sets the sneak right-click action (overridden byteleportStaffOriginalControls
)Action values:
Tweaks and fixes