If you put the variables in the onCommand(...) method, they'll expire as soon as the method returns, which renders them useless as a player can...
Not if you persist them. ;)
If multiple players run the command they'll all contribute to the creation of the same arena.
It's a stretch, and even in its best implementation will be inefficient and prone to malfunction. Why not just map the data to the appropriate...
Odds are you're successfully removing the inventory, but since the inventory won't be immediately updated client-side (a long-standing issue with...
A very good point, and one of the reasons I suggested incremental backups. The two techniques could be easily combined to optimize shutdown time...
Because the class implements CommandExecutor, this should never be the case. Rather, calling getCommand("define").setExecutor(new Define()) in...
When are values supposed to be reset? After a region has been completed?
Packet manipulation. The modded client displays the world from the perspective of the player being spectated, but sends the server the spectator's...
Changing visuals in any way requires a modification of the client. The Bukkit API adds nothing here; the effect in question could be achieved on...
You were correctly informed. Both techniques I suggested are ones I've used, and the first works fine for me because I perform my updates in such...
entity.getUniqueId()
Can you paste your CommandExecutor in its entirety?
Unfortunately, that won't solve the issue if the update task is to be async. It also doesn't cover other plugins stopping/reloading the server....
No need. Unless you absolutely need to save the variables listed above, limit their scope to the onCommand(...) method. And even if they are to...
Separate names with a comma.