Bukkit

@Unpluggeddk

thanks for letting me know

@UnpleasantPL

i guess i could listen for ChunkUnloadEvent and cancel it if there's a VirutalPlayer at that location... And also add a config option to toggle this feature on/off.

https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/event/world/ChunkUnloadEvent.html

@Dysthymical

I read the PVPManager code... In order to fix this, VirtualPlayers would have to inject itself into the CraftServer's playerList field and construct a playerConnection also. I doubt this is going to happen.

Another option would be for PVPManager to add support for VirtualPlayers in one of three ways:

1. For me.NoChance.PvPManager.Managers.PlayerHandler.add()... remove the first conditional statement:

  private PvPlayer add(Player player)
  {
    if (this.plugin.getServer()
            .getPlayer(player.getUniqueId()) == null) {
      return null;
    }
    PvPlayer pvPlayer = new PvPlayer(player, this.plugin);
    this.players.put(player.getUniqueId(), pvPlayer);
    pvPlayer.loadPvPState();
    return pvPlayer;
  }

2. Obviously, they do not want to un-necessarily populate their players HashMap, and that is the primary objective of the conditional check. But they don't have to return null... They could still return the created object without saving it to the HashMap. This is probably the best option because it's a more general solution to a variety of problems that arise when you return null.

The code would look something like this

  private PvPlayer add(Player player)
  {
    PvPlayer pvPlayer = new PvPlayer(player, this.plugin);
    pvPlayer.loadPvPState();
    return save(pvPlayer);
  }

private PvPlayer save(PvPlayer pvplayer) {
    if (this.plugin.getServer()
            .getPlayer(player.getUniqueId()) != null) {
      this.players.put(player.getUniqueId(), pvPlayer);
    }
    return pvplayer;
}

Now it doesn't return null.

3. The third option would be to change the implementation details for the conditional-saving check to account for the existence of VirtualPlayers by hooking into the VirtualPlayers API.

  private PvPlayer add(Player player)
  {
    PvPlayer pvPlayer = new PvPlayer(player, this.plugin);
    pvPlayer.loadPvPState();
    return save(pvPlayer);
  }

private PvPlayer save(PvPlayer pvplayer) {
    if (VirtualPlayers.getPlayer(player.getUniqueId()) != null) {
      this.players.put(player.getUniqueId(), pvPlayer);
    }
    return pvplayer;
}

Obviously, you wouldn't directly call VirtualPlayers.getPlayer() because it might not be installed on the server... But that's just an example. They would have hide the call via a Wrapper, Interface, or Utility to protect against ClassNotFoundException.

https://github.com/NoChanceSD/PvPManager/issues/41

https://github.com/NoChanceSD/PvPManager/pull/42

As far as Skript goes... That error is caused by PVPManager, not Skript. But if you have any other problems, lemme know and i'll take a look.

@fr233

These builds have not been approved by the BukkitDev staff. Use them at your own risk.

http://rainbowcraft.sytes.net/download/plugins/WorldEdit/v6.1.1-SNAPSHOT/

If anyone wants to use VirtualPlayers to execute WorldEdit & WorldGuard commands, then you can download the above WorldEdit. Or you can use any v5.x version.

Here is the source code (& changes) if you wish to compile it yourself:

https://github.com/Europia79/WorldEdit/tree/vpcmdfix

https://github.com/Europia79/WorldEdit/commits/vpcmdfix

https://github.com/Europia79/WorldEdit/commit/eb43018ae2211b4257e418209fef1b922a03cf91

@LaughNgamez

Yeah, VirtualPlayers v1.6.5 for 1.8.7 needs approval from BukkitDev.

Development builds of this project can be acquired at the provided web-server.

These builds have not been approved by the BukkitDev staff. Use them at your own risk.

http://rainbowcraft.sytes.net/download/plugins/VirtualPlayers2/v1.6.5/

@jaime29010

v1.6.5 is updated for 1.8.7

@Jeffrey09

The code is pretty insane: https://github.com/Europia79/VirtualPlayers/tree/worldedit

That's the worldedit branch for VirtualPlayers (in case you wanted to find a developer to finish it). You would have to fix all the errors associated with the fake PlayerConnection. Then after that, you'd have to accommodate for VirtualPlayer being a real Player (the easy part).

@jaime29010

There shouldn't be any stacktrace... VirtualPlayers disables itself on server startup for unsupported servers... to prevent spamming the console with errors. Instead, you'll get a msg explaining that your server is un-supported.

I'm in the middle of updating BattleTracker right now... Hopefully, I can get to VirtualPlayers soon tho.

@amli2011

LaughNgamez reported the same problem... I believe this feature works if you use WorldEdit v5.x... it just doesn't work if you use WorldEdit v6.0.0

WorldEdit has changed something in the code to break this feature. So either WorldEdit would have to change to allow fake players to run commands... Or else VirtualPlayers will have to somehow change to better simulate a real player... but HOW exactly, i do not know.