• Using book to activate sender doesn't consume book.
• Renaming attuned scroll at anvil renders scroll non-functional.
• Breaking and rebuilding receiver causes message on first use of existing sender or attuned scroll that receiver "has been damaged or destroyed", but teleport succeeds anyway.

1. The books were never meant to be consumed, but that can probably go in as a configurable feature.
2. This is an interesting test! I pack the database data into the scroll, and modifying it with an anvil probably overwrites what I've done. I'll have to think about how scrolls can be named, or maybe provide a way to name the waypoint itself, and make that show up on the scroll after attuning it.
3. That one's definitely a bug, I'll look into it. Thanks. I think the "correct" behavior is that breaking a block will require the waypoint to be re-activated, however there is an optimization problem involved here. I currently perform the "has the waypoint been damaged" right before teleportation for efficiency reasons. If I try to detect a waypoint being broken in real-time then I will have to run some code every time any player breaks a block, which I worried will create too much lag. I will think about whether or not this is feasible, but for now the intended behavior will be that waypoints don't actually "break" until someone tries to use them. Or perhaps we invent a bit of lore and say "the magical connection persisted after the waypoint was removed, but now that connection is broken since the magic is all used up" (allowing the bug to be canon)

Adding to (players have been finding things and letting me know)...

• Attuned scrolls can be re-attuned to another waypoint. Intended? Option not to?
• User appears one block above pad on arrival before dropping to pad. Doesn't matter if pad is buried or not. Intended?
• Sender pad generates cancelling messages continuously up to seven blocks above pad if standing above the south or southwest corner.
• Mob teleports with player if on leash, but does not visually appear with player from player's perspective, leash is stretched into the distance (relogging fixes issue). Mob is present to other players though. This may be a client bug perhaps.
• Sender pad sometimes activates when standing near the south west corner of the pad (may be related to the same bug above). Having trouble reproducing this consistently.

1. Re-attuning is intended, but could be an option as well
2. The 1-block drop was due to the player get stuck in the floor. It could probably be a 0.1 drop instead.
3. This is a real bug, I'll have to dig into it.
4. Leash teleportation mechanics may have changed with newer versions of MC; I'll have to look into that as well.
5. I think this (and maybe he above bug) are related to distance calculations being performed from the corner of a block, rather than the center. I use offsets to make everything center-relative, but may have missed some.

Breaking and rebuilding receiver causes message on first use of existing sender or attuned scroll that receiver "has been damaged or destroyed", but teleport succeeds anyway.

3. That one's definitely a bug, I'll look into it. Thanks. I think the "correct" behavior is that breaking a block will require the waypoint to be re-activated...

I think I need to clarify this one a bit better. Steps to reproduce and what occurs...

1. build a sender
2. build a receiver and activate it
3. now destroy receiver and rebuild it elsewhere and activate that one
4. go to sender to start teleport
5. particle effect charge up
6. error about waypoint being damaged or destroyed
7. particle effect charge up (again)
8. teleport succeeds!

** Each time you repeat step 3, you'll end up repeating steps 6 and 7 again until it finds a functional receiver. I've gone up to four so far.

Given the reproducible steps above, I'm assuming the current order or ops goes something like this (skipping a few in-between details)...

• player is on sender (how do you even detect this?) > query db for receiver coords > show cost and do effects > check coords for intact receiver > warn player of dmg'd receiver > delete old record and continue with next matching db record > show cost and do effects > check coords for intact receiver > complete teleport

To make this a bit smoother, I'm guessing you just need to make a few changes in the processing order...

• player is on sender > query db for receiver coords > check coords for intact receiver > warn player receiver has been moved (or don't!!) > repeat with next matching db record > check coords for intact receiver > show cost and do effects > complete teleport

If you complete the checks first then you can display the warning sooner (before showing cost and effects) or even warn that it was moved vs destroyed. Rather than 'fixing' a possible 'duplicate receiver' bug, we instead have a way to create 'backup' receivers in case something breaks the primary (ie: an unfortunate creeper accident or enemy player).

Alternatively (and maybe optionally), when activating a new receiver, check for a matching existing receiver in the db and validate it in the world, denying the activation of another with the same address if a functional one already exists.

Optional bonus! If more than one record is returned for a given address, pick one at random! Complete the teleport if the receiver is intact, otherwise delete it and pick another one. ... ,,, ,,, Ooooo, and perhaps designate a block as a wildcard block so when on a sender constructed with those wildcards, you'll get back a larger list of possible receivers to randomly end up at (wheeeee)! Teleporter roulette anyone?

New beta build incoming! Here are the big changes:

1. options in config.yml <-- see for details
   • databaseBackend
   • consumeBook
   • numScrollsCrafted
   • allowReattune
   • Added custom (shapeless only) recipes for the Book and Scroll
   • configurable lightning, and an alternative enderman-like effect
   • lots of teleport animation settings
2. Added /tr convert command to convert between database formats
3. Exposed existing /tr mirage feature and added documentation
4. fixed player appearing 1 block above waypoint
5. Updated some internal material logic to use newer API methods

https://github.com/BLuFeNiX/TeleportationRunes/releases/tag/v2.1.0-beta
https://github.com/BLuFeNiX/TeleportationRunes/releases/tag/v2.1.0-beta-2

As for the remaining issues in the above comments, as well as from #8, I think I'll need to break them into separate issues and get to them once I have more time.

Also, I was going to include cross-world teleportation, but I am not sure how to deal with the cost. Since there is no calculable distance, it could be a flat fee, but that effectively caps the max teleport cost to double that fee. A player can hop worlds, walk over to another teleporter, and hop back to the original world, effectively teleporting any arbitrary distance for a flat fee.

Maybe that's OK though?

Also, I was going to include cross-world teleportation, but I am not sure how to deal with the cost. Since there is no calculable distance, it could be a flat fee, but that effectively caps the max teleport cost to double that fee. A player can hop worlds, walk over to another teleporter, and hop back to the original world, effectively teleporting any arbitrary distance for a flat fee.

I'd say you base the 'distance' on the distance between the two coords as if they were in the same world as the waypoint, then add an additional (configurable) fee on top of that for crossing the dimensional divide.

@zaphiredfox That could work. I'll think about it some more.

Also, I just fixed a bug real quick, so grab this build if you already got the other one:

https://github.com/BLuFeNiX/TeleportationRunes/releases/tag/v2.1.0-beta-2

As for this:

Given the reproducible steps above, I'm assuming the current order or ops goes something like this (skipping a few in-between details)...

* player is on sender (how do you even detect this?) > query db for receiver coords > show cost and do effects > check coords for intact receiver > warn player of dmg'd receiver > delete old record and continue with next matching db record > show cost and do effects > check coords for intact receiver > complete teleport

I detect it with this task which checks every player every 20 ticks (1 second), and uses a fail-fast approach to do as little logic as possible if there is not a valid teleporter under the player.

That being said, all this code could do with a refactor, since I wrote most of the core logic several years ago and I could probably streamline a lot of this.

To make this a bit smoother, I'm guessing you just need to make a few changes in the processing order...

* player is on sender > query db for receiver coords > check coords for intact receiver > warn player receiver has been moved (or don't!!) > repeat with next matching db record > check coords for intact receiver > show cost and do effects > complete teleport

If you complete the checks first then you can display the warning sooner (before showing cost and effects) or even warn that it was moved vs destroyed. Rather than 'fixing' a possible 'duplicate receiver' bug, we instead have a way to create 'backup' receivers in case something breaks the primary (ie: an unfortunate creeper accident or enemy player).

Alternatively (and maybe optionally), when activating a new receiver, check for a matching existing receiver in the db and validate it in the world, denying the activation of another with the same address if a functional one already exists.

Optional bonus! If more than one record is returned for a given address, pick one at random! Complete the teleport if the receiver is intact, otherwise delete it and pick another one. ... ,,, ,,, Ooooo, and perhaps designate a block as a wildcard block so when on a sender constructed with those wildcards, you'll get back a larger list of possible receivers to randomly end up at (wheeeee)! Teleporter roulette anyone?

I'll have to dig aback into my own logic and see what can be shuffled around. The reasoning for the animation occurring first was that the plugin initially required right-clicking a block to teleport, so I got rid of that and "bolted on" the auto detection and animation. I do think the logic can be adjusted, but it might require a more significant refactor. Not sure yet.

Closing this, since I've opened other issues for the remaining items here.