Possible problem with teleport function
WolferAlpha opened this issue ยท 15 comments
I have had problem when any player on the server (being affected by the teleport delay) when using any warp or even / tpa, I was told that it is not teleported, counts the time and does not teleport, the console does not show any error nor " without permission", returns to normal when I restart the server and it happens again. (EssentialsX is the only plugin that handles these commands on the server)
I've also encountered this, but I have yet to figure out a reliable way to replicate it.
Could you post the output of /ess version? In addition, could you post your config.yml and latest.log on Gist?
output "/ess version"
{Server version: 1.14.3-SNAPSHOT git-Spigot-4d2f30f-f1f3355 (MC: 1.14.3)
EssentialsX version: 2.17.0.0
PermissionsEx version: 1.23.4
Vault version: 1.7.2-b107
EssentialsXChat version:2.17.0.0
EssentialsXSpawn version: 2.17.0.0
You are running unsupported plugins!
You are running as unsupported server version!}
EssentialsX config: https://gist.github.com/WolferAlpha/57f5316a5382a273f81c7feaf634ee06
Latest log: https://gist.github.com/WolferAlpha/57de97b8917914fcd828a0781f8022fb
Also having this issue
Server version: 1.14.3-R0.1-SNAPSHOT git-Paper-131 (MC: 1.14.3)
EssentialsX version: 2.17.0.0
LuckPerms version: 4.4.27
Vault version: 1.7.2-b107
EssentialsXGeoIP version: 2.17.0.0
EssentialsXChat version: 2.17.0.0
EssentialsXSpawn version: 2.17.0.0
Config: https://gist.github.com/CJOS100/41807a6a2ac053fa71b73fdf575fc4b4
Latest Log: https://gist.github.com/CJOS100/9273b49206bb386ccd815a85ab56ef00
Server version: 1.14.4-R0.1-SNAPSHOT git-Paper-167 (MC: 1.14.4)
EssentialsX version: 2.17.1.15
LuckPerms version: 4.4.1
PlaceholderAPI version: 2.10.3
Vault version: 1.7.3-b${env.TRAVIS_BUILD_NUMBER}
EssentialsXSpawn version: 2.17.1.15
Config: https://hasteb.in/oqunixiq.yaml
Latest Log: https://hasteb.in/izujuwir.md
From troubleshooting the issue with a player not being able to do /home Example1.
The player were able to do /home Example2 successfully, but /home Example1 were according to EssentialsX "Successful", but nothing happend.
The issue seems to only affect certain areas/locations.
Also have this issue. The teleport commands function properly as soon as the delay is disabled..
Rarely, the teleport will work as intended, but extremely high rate of nothing happening.
Admins who have the delay bypass permissions can also use teleports properly with delay enabled.
EssentialsX version: 2.17.1.0
LuckPerms version: 4.4.30
Vault version: 1.7.2-b107
EssentialsXGeoIP version: 2.17.1.0
EssentialsXChat version: 2.17.1.0
EssentialsXSpawn version: 2.17.1.0
Paper build 186
The problem seemed to have started after we did:
Added Plan
Added spark
Added Tablist
Added PlaceholderAPI
Removed GroupManager after migrating to luckperms
If you need more information I'd be glad to help.
So, for non-op players that have the delay, from time to time, it will just simply do the countdown and then not teleport, yet it said it did it successfully? And this is all completely random?
Correct, it will put the "Teleporting in 5 seconds. Teleporting to home" immediately like usual.
But then nothing will happen, if you move it also doesn't give a cancelled teleport message.
You can also use the command rapidly with nothing but the "teleporting in 5 seconds" message happening.
We have a 5 minute cooldown on teleports set as well, which isn't activated by said failed teleport either.
Can you throw your config and latest log here where the issue is occurring with the homes? Thanks.
Sadly there's no feedback in any way, would love it if it would just spit out an error.
Config currently has teleport delay set to 0 as temporary measure.
Config
Latest log snippet
Ingame footage
Edit: Also running paper build 186.
Adding GroupManager back, while keeping Luckperms, seems to fix the issue.
Will need to leave the server going for longer, but this seems rather strange.
Would be interesting if others with this issue could confirm.
We also recently discovered some /r weren't actually arriving at the recipient, this also seems fixed now.
Edit: It looked fixed at first, but one user reported to have the issue again.
Didn't seem like it would make sense groupmanager would fix it I guess.
Duplicate of #2287