[GEN] HomeSpawnPlus v1.1 - Multiworld Home/Spawn [BukkitDev]

Discussion in 'Archived: Plugin Releases' started by andune, Jul 1, 2011.

  1. Offline


    tombik likes this.
  2. Offline


    It's simple, just don't give them permission.

    The only permission you will give them is "hsp.command.groupspawn". Then configure your groupspawns the way you want. Then when they type "/groupspawn" they will go to their groupSpawn. Except for the "onGroupSpawn" event, just set all your other event chains to "default" (or delete them, same effect).
  3. Offline


    Thanks!... oh wait I won't even give them that. I don't want any tping at all.
  4. Offline


    Before I got permissions my set up for HomeSpawnPlus worked fine, but once I had PermissionsEX set up whenever I try to use it, like /sethome, it tells me that I don't have permission. Any suggestions on how to correct this problem? Thanks.
  5. Offline


  6. Offline


    v1.7 is released! Changelog

    I've put in some time to get the Strategy doc updated with lots of new info regarding new v1.7 features.

    I've taken to tagging new features with the version they were introduced, so if you're interested in just reviewing new events & modes available to you in 1.7, you can use your browser to just search the page for v1.7 to skim through new features.

    I also have examples of new multiverse/worldguard integrations as well as the new custom commands feature.

    There are some early reports of some commands no longer working after people upgrade to v1.7, but no one has yet given me details such as what plugins they are running, their config.yml or verboseStrategyLog details. If you have upgraded to 1.7 and are having issues, I would appreciate this detail. If you've upgraded to 1.7 and are not having issues, that would be a good data point as well.

    If you are someone having issues, you could try downloading 1.7.1 dev release, which is a stable (but not-yet-released) version of 1.7 with some bug fixes. See the Changelog for details and download link.
  7. Offline


    First, thank you for your time and work on this plugin! Due to the recent updates to bukkit for 1.7 I am having to get rid of the AdminCmd which is handling my homes. I have essentials, but using essentials homes when you give multiple homes is about as pleasant as hitting your head against a stone wall repeatedly. All other homes plugins I've looked at, including the one I'm using has quirks like /home in the nether giving an error msg while you die in lava. This plugin has everything. Every quirk, oddity, or just plain preference of mine is configurable here. Truly amazing work!

    Now my problem. The config_defaults.yml reverts itself each time I start the server.
    I am have set 'storage: YAML' in both the config.yml and config_defaults.yml. It reverts the config_defaults.yml setting back to EBEANS and appears to be using that system as it is not making yml files to store player homes. I need it to use YAML so it will make files I can read with notepad++.

    My second issue might be fixable if config_defaults.yml wasn't reverting itself, but I'm not sure. I created permissions for 3,6,9, and 12 homes. Guests have the perm for 3 and players have the perm for 6. When I promote an account to player, it inherits the guest perms. This means it now has the perms for both 3 and 6 homes. This stops the player at 3 despite having the perms for 6.
    *Update* This second problem I have found the solution to. I null perm the previous and it allows the new perm to work. I left this paragraph here in case anyone else runs into this.
  8. Offline


  9. Offline


    The first problem, config_defaults is easy; these comments are in the top few lines of that file:

    # This config_defaults.yml is NOT USED by HSP in any way and is
    # overwritten everytime HSP starts up. It is simply here for reference
    # to the full set of options available in HSP as well as their
    # default values. Copy any sections you want here into your config.yml
    # to make changes.
    The reason config_defaults.yml exists is because HSP has so many features, just loading them all into the config.yml seemed overwhelming for new people just getting started. So the initial config.yml is a stripped down version and the full set of options is available in config_defaults.yml, which can be copied over to config.yml and edited as you please. config_default.yml is not used in any way by HSP other than being overwritten every startup with the latest full set of default options.

    Despite the comment at the top, as your post suggests, this has proven confusing for new people many times in the past even though it's intent was actually to make it easier. In an attempt to improve on this situation, in HSP 2.0 the config_defaults.yml is gone and the config is actually broken up into several smaller files. This allows new and veteran users of HSP to simply focus on the config they want to change without having to hunt through a single large massive config.yml.

    For your second issue, you already found one solution to the problem, which is a fine way to do it. The other method is just to invert your HSP config so the highest permission appears first. When HSP processes "per-permission" settings, it moves sequentially through the config in the order defined, so if you put your highest permission first, it will work as you expect. This is documented here if you want to read more about it:


    Last, glad you like HSP. It was written for exactly the reasons you mention; I was originally frustrated by not having a plugin that did exactly what I wanted. HSP's start in life was as a plugin that did exactly I wanted on my server, hard coded. Over time, I made it more generic and flexible so other people could use it to do different things without having to write their own plugin too and thus it's current concept of events and strategies was born. Enjoy!

Share This Page