world teleport and tppos failing over time when used with /execute in a command block

[kencinder]

I have been using world teleport and tppos in command blocks set up to create portals on my server.

After updating to 1.3.6 they no longer work, stating that the commands must be run as a player.

/execute @a[x=31,y=88,z=27,dy=1,dz=2] ~ ~ ~ world teleport creative @p for example works fine on 1.3.5 but does not on 1.3.6, and Nucleus says the command must be run as a player.

Nucleus Info Output (This shows version 1.3.5, which I went back to due to the issue)

[kencinder]

This is quite a strange issue, it appeared at first to be a problem with Nucleus given the command result stating it must be run as the player, but I'm having the same problem minus the "Must be run as a player", and it doesn't even happen right away. I spent almost a half hour standing in the chunk where functioning portals are (Tested them on startup) only to have them no longer work and throw the following error (I have to run it myself while standing in the portal, there's no result in the command block).

Failed to execute 'tppos @p world 29 88 19' as ken_cinder

Portals worked for days when I was on SF 2970...back to that I guess, I don't have a clue at this point.

[kencinder]

Definitely being caused by something introduced since SpongeForge 1.12.2-2611-7.1.0-BETA-2970.

I moved to 1.12.2-2611-7.1.0-BETA-3000 for the Negative Dimension ID fix, having to go back again for this, and I haven't the slightest clue how to diagnose the problem as there is ZERO feedback in the console/logs and command blocks aren't even showing "Last Result" with the failure, the only thing to go on is in my previous comment, when the command is issued by a player.

[dualspiral]

Keeping open so I remember to look, will move it if it's really a Sponge issue.

[kencinder]

Seems I was wrong about it being fine in 2970, it just took a lot longer to happen. Coincidence or not?

It's not command blocks breaking, I utilize 2 command blocks per portal, the other one is for generating particle effects and it continues to function.

[kencinder]

Ok played around with this some more recently, and I'm fairly certain at this point it is at least indirectly Nucleus' fault, as minecraft:teleport continues to function fine with the /execute command I'm using even after failure of the Nucleus commands.

I'll try to detail things better/as best I can below...

I am utilizing command blocks to teleport users to worlds, using the /execute command. It works fine for awhile before breaking, and even issuing the command myself in game or via the console fails.

An example of one such portal command block command is /execute @p[x=31,y=88,z=18,dy=1,dz=2] ~ ~ ~ world teleport TROPICS @p using an "Always Active" repeating command block.

This is using Nucleus' world teleport command, but altering it after failure to using /execute @p[x=31,y=88,z=18,dy=1,dz=2] ~ ~ ~ minecraft:teleport @p 24 88 24 for example, works perfectly fine even after failure of the Nucleus commands.

The command block Previous Output shows nothing(Shows nothing with successful vanilla teleport too), but issuing the command while standing in the portal, in-game or from the console results in Failed to execute 'world teleport TROPICS' as ken_cinder

This issue also happens using tppos, and using tpn instead of minecraft:teleport also fails, basically any Nucleus teleportation command fails after some time with repeated /execute use.

[kencinder]

Further update on this, I switched the command blocks responsible for the teleport to "Impulse" "Needs Redstone" and utilized pressure plates, since things weren't working anyway. Without even having to restart the server, once I got enough of them switched over, the command started to function again on it's own.

I think with 6 of these portals set up in the overworld, and 1 in each world they link to, the repeating commands may have been getting "overloaded" and ceasing to function.

[dualspiral]

@kencinder I reckon this issue was it and it's been fixed in the latest Sponge build. Care to give the latest SF a spin (if you can?)

[kencinder]

Looking at that commit, I doubt it has anything to do with the issue I've described...that's just a permission problem for accessing the command block after teleporting between worlds.

My problem is repeating command blocks that utilize /execute fail after awhile, almost like the command being repeated to much breaks it. Not the /execute command itself, but the commands of a plugin used by it. You can switch the command out from a Nucleus one to a Vanilla TP for instance, and the otherwise same /execute functions again.

[phit]

you mean? https://github.com/SpongePowered/SpongeCommon/issues/1815

[kencinder]

@phit That certainly looks more in line with the problem I'm having here. As even "Needs Redstone" doesn't function after a chunk is unloaded, which messes up my particle ones in certain worlds that refuse to keep spawn loaded no matter what the config says. I took to using "Needs Redstone" with pressure plates AND circuits with 2 redstone torches(One on, one off that alternate states when the switch is activated) to keep them functioning(2 torches so the effect isn't interrupted at that)

[kencinder]

You can put down for example 6 Always Active Repeating command blocks, and NEVER leave the chunk and after some time the command referenced in it breaks. As per the above...

/execute @p[x=31,y=88,z=18,dy=1,dz=2] ~ ~ ~ world teleport <worldname> @p in 6 command blocks work fine...until they don't. Once they stop working, you can stand in the same referenced coordinates and fire the command off yourself or from the console, and you get the Failed to execute 'world teleport <worldname>' as <username> error until you A: Restart the server, B: Change the command to something NOT provided by the same plugin(I've tried switching a /world teleport to /tppos after the failure, and it still fails...but a Vanilla TP to coords does not)

This issue is wacky and annoying...and I just don't know what I can do to describe it any better.

[dualspiral]

I haven't forgotten about this.

I've been testing and I can't get this to trigger. That's not to say that it's not an issue, it clearly is, but I'm unable to reproduce it.

I've set two command blocks on different parts of a redstone clock using the @p selectors, sending me messages back.

• execute @p[r=20] ~ ~ ~ m @p test
• execute @p[r=20] ~ ~ ~ m @p test2

It's ticking away nicely as it stands on the latest SF build. I'm actually still getting https://github.com/SpongePowered/SpongeCommon/issues/1718, funnily enough, but I'll look into that later.

[kencinder]

I have no problem with something set up on a clock, or triggered by pressure plates/buttons. The issue seems to stem from repeating command blocks.

[dualspiral]

Does https://github.com/SpongePowered/SpongeCommon/commit/400d9a58a5c2cb3755974988889393d431a201d7 (i.e. latest SF) fix it?

[kencinder]

I took steps to work around this awhile ago, I would have to change everything back to test it again, or set up my test server in a similar manner.

I seem to be the only one crazy enough to work with command blocks in this manner, or having had the problem. I will close this.

[dualspiral]

To bring some closure to this: https://github.com/SpongePowered/SpongeCommon/pull/2033

[kencinder]

The above PR certainly seems to have fixed the problem. We could get 30 minutes in or less on server start, and the command blocks using selectors would fail. Server has been up for 4+ hours now and they're still working.