[GEN/SEC/ECON/TP/ADMN] Essentials - A collection of useful commands

Discussion in 'Archived: Plugin Releases' started by EssentialsTeam, Apr 30, 2011.

  1. That's what essentials is, its a collection of the basic functionality from plugins, so that server owners can have a simple easy to configure base, for which to run a server. If you want, its possible to completely remove essentials and replace it with 15 specialised plugins. Essentials tries to cover the core functionality of each server 'need' without getting too complicated. Most people will now never get a stand alone game mode switcher, because Essentials is enough, and for the other 2%, they can get a more specific plugin which handles the extra features.

    If Essentials WINS control over the command, Essentials checks to see if another plugin tried to bind it. If it finds that another plugin tried to register it, it will forward the command to the other plugin UNLESS it is listed in the 'override' list.

    override list = up to chance
    not in override list = priority always goes to the other plugin

    This applies to any 'command' registered in bukkit.

    Each plugin has a 'plugin.yml' inside the jar file. This file is readable/editable, you simply open the jar with winrar, and the file is in plain text in the root. This is the default way to handle command registration. It is fairly common procedure for server owners to edit this file to fix minor conflicts, or change things like the default help message.

    When bukkit finds a plugin conflict, it doesn't just discard the later plugin commands, it instead binds them as '<pluginname>:<command>'. The alias section of the bukkit.yml could be used to redefine a command as the definition you'd prefer:
      - version
      - Essentials:gamemode
  2. Offline


    Because Bukkit does not allow dynamic command or alias registrations. All commands and aliases have to be defined in plugin.yml.

    The problem with WorldModes is only the alias /gm. The command /gamemode is registered by Essentials first, but we can detect that the command exists in WorldModes too, so we call it. This does not work for the alias /gm, because again, Essentials registers it first, but when WorldModes wants to register it, Bukkit just discards it. This is a flaw in the Bukkit commands code.

    I just wrote a rather lengthy workaround for this problem: we read all plugin.yml files from all plugins, parse them, extract the aliases and use that for our decision on which command we should call. This workaround will be in the next release.
  3. Offline


    How can i get rid of that?
    I don't want my name to be [WorldOne][Owner]g0dlike97
  4. Offline


    First question :

    Can have a confirmation.

    To do an update 2.64--> 2.65

    Just replace the jar file? (i keep my config and have access all functionality of 2.6.5 essentials? )

    Second :

    Do you have a tool to convert pex permission file to group manager?
  5. The change refers to simply getting the right prefix, from the world the user is in.
  6. Offline


    I have no trouble understanding the use case and justification for a monolithic component, but I don't think that justification necessarily extends to the somewhat ideologically exclusionary practice of taking over the command aliases of other popular pre-existing plugins, which then results in a direct command conflict in the bukkit environment (but see below for an alternate solution). For example, in the case of WorldModes 2.x, it defines both /gamemode and /gm. The questions it brings to mind are:
    1. Were there other aliases essentials could have used?
    2. Why did the essentials team specifically choose the two that were already in use by WorldModes?

    At the surface, both /gm and /gamemode appear to be in conflict, as I mention above, and would seem to depend on plugin load order. Brute force solutions are sometimes necessary, and I'm glad to see that essentials is doing something to try to improve the manner in which it defers to other plugins to optimize compatibility. Thanks for doing that. Probably isn't too pretty. :)

    However, this whole system sounds architecturally broken and backwards to me, where the problems begin at the bukkit level, as you also state. In the long view, where plugins continue to increase in number and complexity as minecraft keeps changing/growing, bukkit should really be doing the work for command arbitration, conflict resolution, pass-through execution, and console/user notification at server boot time.

    For example:
    1. Command definitions in plugin.yml could (and should) include simple execution parameters such as:
    a. "canDefer" - boolean to indicate whether or not a command is willing to be deferred vs. other identical commands in other plugins
    b. "priority" - an execution priority - 1 to 10 (high to low) - whatever - which indicates the relative priority (translating to bukkit execution order) of a command vs. other similar commands
    c. "passThru" - boolean to indicate whether or not the command still wants to be called if another command of the same name executes first - where trailing executors can still apply custom or advanced features
    d. "dependency" - static plugin requirements list that could generate top-level compatibility/dep. screening errors by bukkit (missing plugs, wrong versions, etc.)

    2. With this small subset of params, bukkit could handle various conflict scenarios that might arise in an elegant manner and server admins would have greater control over execution via the plugin.yml interface
    a. plugins with canDefer=true will defer to plugins with canDefer=false in a simple replacement model such as the one we are discussing.
    b. a deferring plugin can still execute after a non-deferring one with passThru=true, where it could check environment and/or user state and potentially append its additional advanced features vs. more basic issues handled by upstream executers.
    c. all similar plugins can be good citizens and set defer=true and run based on priority level for a specific command. If there is a priority conflict, then passThru can be used to determine who really wants to be called. If there is a rare case of priority and passThru conflict, then bukkit will choose who owns the command and report to the console which plugin is the owner.
    d. bukkit would report all parsing conflicts to the console so that admins know that a potential conflict exists so that they can proactively prevent server issues
    e. similar plugins can use the same command and still execute and apply special features in a modular way
    f. bukkit would potentially maintain a queue of basic game state objects and executions so that downstream/passThru plugins could interrogate state changes and behave properly. Also, since they are passThru plugins, they have the opportunity to record their own state for custom things they care about on each call. Either or both ways work.
    g. a new breed of plugin could emerge where plugins intentionally gang on the same command alias, rather than competing for it, and just add incremental features - kind of an interesting model for developers and users - not having to reinvent the wheel every time or trying to own everything in a monolithic sense
    h. server admins could examine plugin.yml to determine how well-behaved a plugin might be in their current environment based on top-level arbitration by bukkit

    3. The entire model is backwards compatible because the absence of a parameter translates to false/high priority, etc.

    The working example in this case would be /gm calling essentials' basic mode switch then being passed through to worldmodes for additional manipulation of inventory, chest access, etc.

    As with any implementation/architecture, the above hypothetical model would not prevent poorly-coded plugins from breaking things, but would help reduce conflicts and provide an environment where plugins can have both common and unique features and still work in a collaborative context via chained execution under the top-level control of bukkit. It's not ideal for multiple (or any) plugins to use brute force methodology to solve problems at the bukkit level or have to engineer multiple solutions to solve common problems in a plugin ecosystem where there is bound to be duplication and crossover. When brute force solutions are required, there is typically a top-level architectural deficit that requires software review.

    OK - that explanation is helpful. I may need to edit plugin.yml's in the future. Also, I looked at essentials' plugin.yml on github, which was informative. However, the point I was trying to make was that the conflict could cause problems for admins and require troubleshooting time and is easily prevented with a simple command change. Also, there are thousands of servers and people managing them. What is the rationale for a single plugin such as essentials creating command chaos in all those environments vs. just avoiding the conflict? Also, I think I disagree with that statement that editing embedded plugin.yml settings is common practice for server admins who are not plugin developers. I haven't ever needed to do it, and I don't believe most others have either. I would guess that most don't know how and/or haven't tried.

    I see - thanks - that explanation helps. But, again, this is a user burden that should be handled automatically by bukkit in the ideal case, or that developers should seek to avoid in the first place.

    I look forward to the next essentials release. I like essentials and think it's a good plugin. I just wish there were fewer conflicts and a better way to address all these issues. Thanks for replying.
  7. Offline


    @GravelSocks This is not the right place for this, you might want to create a new thread, if you want your posting to be read by someone that can actually change bukkit.

    We do our work to prevent conflicts, but we can't change how bukkit works. We already have a lot of workarounds in our code, because bukkit is very slow to fix any flaws in the api.
  8. Offline


    All the commands and stuff work, but my console keeps getting spammed with this every time someones joins..

    04:43:19 [SEVERE] Could not pass event PLAYER_CHAT to Essentials
    java.lang.IllegalArgumentException: §7[§aDefault§7]  is already assigned as a player list name for someone
            at org.bukkit.craftbukkit.entity.CraftPlayer.setPlayerListName(CraftPlayer.java:155)
            at com.earth2me.essentials.PlayerExtension.setPlayerListName(PlayerExtension.java)
            at com.earth2me.essentials.User.setDisplayNick(User.java:287)
            at com.earth2me.essentials.EssentialsPlayerListener.onPlayerChat(EssentialsPlayerListener.java:79)
            at org.bukkit.plugin.java.JavaPluginLoader$6.execute(JavaPluginLoader.java:295)
            at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:58)
            at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:339)
            at net.minecraft.server.NetServerHandler.chat(NetServerHandler.java:727)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:715)
            at net.minecraft.server.Packet3Chat.a(Packet3Chat.java:33)
            at net.minecraft.server.NetworkManager.b(NetworkManager.java:226)
            at net.minecraft.server.NetServerHandler.a(NetServerHandler.java:92)
            at net.minecraft.server.NetworkListenThread.a(SourceFile:108)
            at net.minecraft.server.MinecraftServer.h(MinecraftServer.java:471)
            at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:374)
            at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)
  9. Offline


    Yep - I agree. I'll copy it to the bukkit feedback forum. The architecture is lacking, IMO and brute force solutions are not the answer.

    In terms of working to prevent conflict, what is the reason that essentials 2.6.5 needed to use the same command aliases as the pre-existing WorldModes? (unanswered from above 2 posts)
  10. Two reasons:
    • It's the most logical command for this purpose, we added the 4 aliases that seemed to make the most sense.
    • For consistency, for the most part, people who used worldmodes and other similar plugins in the past, will now be able to get away without it, by using the same command syntax, it means people can migrate away from it without having to teach users and mods new commands.
    I would suggest that there are virtually no conflicts, and we're doing more than any other plugin.
    If a plugin wants to ensure it wins over from Essentials, it just has to define a command the way Bukkit intends plugins do. Regardless of plugin load order, if another plugin has defined it as a command, Essentials will concede.

    Also, sk89q (worldedit/worldguard guy) recently tried to improve the command system, by allowing plugins to smartly register its commands, but his changes were reverted and he had his commit access removed.
  11. Offline


  12. Offline


    Updated essentials and GM recently and I had to redo all my permissions, but I'm getting the following error:

    2011-11-18 13:10:27 [SEVERE] Error occurred while enabling GroupManager v1.5 (Phoenix) (Is it up to date?): java.lang.Double cannot be cast to java.lang.String
    java.lang.ClassCastException: java.lang.Double cannot be cast to java.lang.String
    at org.anjocaido.groupmanager.dataholder.WorldDataHolder.loadUsers(WorldDataHolder.java:718)
    at org.anjocaido.groupmanager.dataholder.WorldDataHolder.load(WorldDataHolder.java:554)
    at org.anjocaido.groupmanager.dataholder.worlds.WorldsHolder.loadWorld(WorldsHolder.java:459)
    at org.anjocaido.groupmanager.dataholder.worlds.WorldsHolder.initialWorldLoading(WorldsHolder.java:75)
    at org.anjocaido.groupmanager.dataholder.worlds.WorldsHolder.initialLoad(WorldsHolder.java:66)
    at org.anjocaido.groupmanager.dataholder.worlds.WorldsHolder.<init>(WorldsHolder.java:58)
    at org.anjocaido.groupmanager.GroupManager.onEnable(GroupManager.java:123)
    at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:174)
    at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:957)
    at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:280)
    at org.bukkit.craftbukkit.CraftServer.loadPlugin(CraftServer.java:171)
    at org.bukkit.craftbukkit.CraftServer.enablePlugins(CraftServer.java:154)
    at net.minecraft.server.MinecraftServer.e(MinecraftServer.java:297)
    at net.minecraft.server.MinecraftServer.a(MinecraftServer.java:284)
    at net.minecraft.server.MinecraftServer.init(MinecraftServer.java:152)
    at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:348)
    at net.minecraft.server.ThreadServerApplication.run(SourceFile:417)

    (Assuming it has something to do with users.yml)
    My server's been running 8 months, and it's a pain in the ass to redo over a HUNDRED ranks and prefixes for each player, help would be appreciated.

    If you want to see my users.yml:
  13. delete use
    See if it then works.
    SK83RJOSH likes this.
  14. Offline


    Thank you so much, saved me a lot of trouble :)
    Too bad he won't have a rank anymore, in the meantime anyway. xD
  15. Offline


    I try to remove the worldname before my displayname in the chat.


    How i can do that ?

    I try :
    -comment group-formats
    -change format...

    (i use pex...)
  16. Could you make a copy of your permissions file available?
  17. Offline


  18. Offline


    I have the same issue since the last essenials update. I can't get rid of the worldnames in front of the player name in the chat. Is there any way to hide them?

    I use this code in config. There is no worldname included.

      # If set to the default chat format which "should" be compatible with ichat.
      format: '{DISPLAYNAME}: {MESSAGE}'
  19. Offline


    Need update for 1.0.0 :D
    This plugin is sooo fresh !
  20. Offline


  21. Offline


    The last stable version 1.16
  22. Offline


    @nicquehen @BehindTheMatrix Can't reproduce this. Works correctly for me. Please check the chat-format in config.

    Tested with PEX 1.16 and Essentials 2.6.5

    Do you have any other plugins installed that modify the chat messages?
  23. Offline


    Thx for this information so i will do some test tomorrow to detect which plugin.


    i have revverchat i think it's the only plugin can do that.

    I keep you advice when i will done my test.
  24. Offline


    Your plugin has made managing my server almost bearable :D
    Thanks For all the great work you put into it.
    And i look forward to all the many many update:D
  25. Offline


  26. Offline


    Hey, I'm really satisfied with this plugin, awesome work!
    Is there something like „me-distance“ available to script somehow? I mean the distance per blocks to see player's /me command? If it is, maybe you could think about inserting this, it would be very useful for RP and other servers!
  27. Offline


    I dont understand this:

    # Should drowning damage be disabled?
    # (Split into two behaviors; generally, you want both set to the same value)
    drown: true
    suffocate: true

    That means what? true = disabled or true = enabled (false = disabled) ? and its for all settings.. thanks
  28. Offline


    Essentials spawn mob can't spawn tamed wolfs and electric creeper.:'(
  29. Offline


    Hello everyone !

    I've need essentials 2.3.7 for a server under bukkit build #935 (1.6.6), but I don't find a link ...
    Can someone give me a link, please ? :)

    PS: sorry for my english, I'm french ...
  30. Offline


    I added the permission: "essentials.warp.[warpname]" to my permissions file, in this case "essentials.warp.SpawnShop" but when they type /warp spawnshop it still doesn't work for them. I even tried adding "essentials.warp.[SpawnShop]" as well and it still didn't work, any help?

Share This Page