Player setLocation ... Player moved too fast! issues

Messing around with warp/home command tests - there are a plethora of WIPs out there by other players nicely serving as a guide. The effect I’ve seen is also seen in some other WIPs that i’ve tested out.

I see randomly that my teleporting wont work due to moved-too-quickly server cancellation.
The entries in the log make no sense to me either, two sets of coordinates, and signage differences in them (else its just displaing the absolute coordinates in brackets).

Yet 8 or 9 times out of 10, teleporting is fine, then nothing. then works, works, cancelled, works, cancelled…

If we’re setting the player location its instantaneously moving the player to that location, yeah, its gunna register as being a fast movement… How do we overcome that internal movement checker via this setting, or is it a job for the implimentation to fix something to prevent checking when set through the api methods?

[16:50:28] [Server thread/WARN]: BooMod moved too quickly! -605.0,-20.09800000190735,170.0 (605.0, 20.09800000190735, 170.0)
[16:50:40] [Server thread/WARN]: BooMod moved too quickly! -43.0,13.0,-259.0 (43.0, 13.0, 259.0)
[16:50:46] [Server thread/WARN]: BooMod moved too quickly! 43.0,-13.0,259.0 (43.0, 13.0, 259.0)
[16:51:01] [Server thread/INFO]: Unknown command. Try /help for a list of commands
[16:51:13] [Server thread/INFO]: Teleported BooMod to 43.5, 13.0, 259.5
[16:51:43] [Server thread/WARN]: BooMod moved too quickly! 86.5,71.0,-194.5 (86.5, 71.0, 194.5)

Code snip I use (I’m only doing tping within the same world right now with this test code, current players extent) and a x,y,z vector3d for “loc”
For the purposes of the problem at hand - blocking the movement - this shouldn’t be a factor, and isn’t the way a location destination will be specified in a final product

    if (src instanceof Player){
        final Player p = (Player)src;            
        final Location pLoc = new Location(p.getLocation().getExtent(), loc);
         plugin.scheduler.runTaskAfter(plugin,                     
                new Runnable() {                
                    public void run(){
                        p.setLocation(pLoc);
                    }
                }                    
                , 20L);
        
    }

Am I missing something else to do when reassigning player location? Or is it a system issue that needs to be fixed?

It might have to do with “final”, but I’m not sure.

Yeah, from what I can tell you don’t need the final.

final has nothing to do with it, it’s there because the variable is referenced in an anonymous inner class.

7 Likes

I can try to remove, I thought it was required to push the data into the runnable, and I know factually the IDE pushed me into making at least one of them finals

Any idea what the server log is trying to show? Target coords were 43.5, 13, 259.5 Yet the first cancel has two negative components, the next one negates a third component (y value at that!)

Errors if not final for either of those due to the scoping.

I think the problem is the implementation.

I have to agree here.

Looking over the server logs in more detail shows something a bit odd. From what it looks like, at certain times with either x y and/or z the server is having trouble with deciding if one of those is positive or negative. To point this out:

BooMod moved too quickly! -605.0,-20.09800000190735,170.0 (605.0, 20.09800000190735, 170.0)
[16:50:40] [Server thread/WARN]: BooMod moved too quickly! -43.0,13.0,-259.0 (43.0, 13.0, 259.0)
[16:50:46] [Server thread/WARN]: BooMod moved too quickly! 43.0,-13.0,259.0 (43.0, 13.0, 259.0)
[16:51:43] [Server thread/WARN]: BooMod moved too quickly! 86.5,71.0,-194.5 (86.5, 71.0, 194.5)

I’m not sure what is truly causing that, but it is most likely the implementation I believe.

Okay good, I’m not nuts, and the log really is off the wall too.

Is there a place to report this as an issue (since its something that is working, just not working right) without knowing the granularity of where to post it? Like a bug tracker system that doesnt count on my finding the lines of code in the server to flag a note on… or is that an all-internal bug tracking system currently due to the flood of ‘doesn’t work’ that would be reported for unimplimented things yet?

Github spongecommon

I can’t be totally sure if this is the implementation causing the problem or the API itself, so just to be safe I would recommend reporting the problem over at the implementation repo here.

This is an issue that will affect both Sponge and SpongeVanilla (more likely vanilla).

Hm. i posted in the repo link BitByte gave before seeing Zidane’s post. Zidane, does this mean that the spongecommon IS the best place to report it after all, or somewhere else still?

In all reality…

Location loco = p.getLocation();

what is that a response to, Lokio27?

Your main post. Just get the location instead of making a location.
Edit: nvm

If you are attempting to teleport the player safely, you can use the TeleportHelper SpongeAPI/TeleportHelper.java at e590f64a475ed65e742a9963e1c23fb4549683e0 · SpongePowered/SpongeAPI · GitHub to get a safe location btw.

But yes, unless a teleport method is intended to be added to the API, it seems setLocation shouldn’t be limited by the vanilla anti-cheat.

My suggestion would be to add a teleport method to the API, and use setLocation where modification of movement, or small changes are needed.

Using a teleport method could also allow anticheat programs to know when a plugin intends to move the player long distance, but an event of player move with cause of plugin could do that as well.

1 Like

Hardly… The API doesn’t deal with such values, only the implementation really has a chance to mess up.