Bukkit

@keytastic

Turn on core.verboseStrategyLogging. What happens when HSP processes events will be verbosely printed out to the server log and you can figure out what's happening.

Some possibilities:

• If you've upgraded from 1.7 to 2.0, you might still have your old config.yml in place, yet you're modifying the 2.0 config files. HSP will prefer the 1.7 config if it finds it, so make sure you move it out of the way.
• It's not uncommon for other plugins to also try to control login events. HSP will print warnings to your server logs if you tell HSP to do one thing and it notices another plugin did something else, so look at your log files.

I'm sure there are lots of other possibilities, but best thing is to look at verboseStrategyLogging output and if you can't figure it out from there, zip up your HomeSpawnPlus plugin directory and pastebin your server log entries into a ticket and I'll try to help.

@RedJon28

Latest dev builds are at Jenkins. Old Bukkit rules prohibited a direct link without some special wording, I'm not sure if that applies anymore, so just look up on this main project page under 'Versions' for the Jenkins link.

For your second request:

commands:
  hub:
    class: CustomEventCommand
    event: hubevent

events:
  hubevent:
    - spawnDefaultWorld

Or if you had a specific spawn in mind instead of the default one, just use spawnNamedSpawn:spawnName. Don't forget each of those config sections go in their respective config files in HSP 2.0 config/ directory

@RedJon28

The "missing write method" should be fixed in the latest build (#586). The rest of that message is normal and completely benign. I have no control over it, the ebeans server built into Bukkit spits out those messages when it starts up. Despite the spam and the ominous sounding "ERROR ebean.properties not found", everything is fine and will work normally.

@RedJon28

Yes, HSP can do that. You need to decide what you want to have happen and then you can shape HSP event/strategies to do that.

For example, if they die on the kitpvp world, should they go to a home on that world first if they have it set, and if no home then to the local spawn? Or should homes be ignored for that world entirely? Do you want them to respawn at the same spawn every time or one of several, or possibly at a completely random location?

And then what do you want to have happen outside of kitpvp, on other worlds? Give it some thought, write down what you want to have happen and then dive into HSP examples and strategy/events that can help you achieve your desired state.

@dunkeroni

Thanks for the report. While I did do a lot of optimization and code refactoring for 2.0, I don't recall any specific thing done that would cause such a drastic difference just by switching versions, not changing config options. There are some new options that can be enabled such as core.inMemoryCache that were built specifically to improve performance in certain situations, but you didn't mention using anything like that.

The two things I know of that can cause lag, specifically on teleport, are: 1) using recordLastLocation with YAML files on a large server. Every time the player teleports, HSP records the location and writes it to disk, which for a larger servers with several hundred or thousand users, eventually will be large enough to cause lag. The core.inMemoryCache option can be used to address this issue.

2) safeTeleport (on by default) on a slow server. Bukkit has done a lot of non-main-thread tuning regarding the loading of chunks, so when a teleport happens, the player is teleported before all chunks around him/her have been loaded and Bukkit continues on serving other players while the chunks around the teleported person load in an async thread.

If using safeTeleport, HSP does an evaluation of the targeted teleport location PRIOR to the teleport, so Bukkit cannot "fire and forget" the teleport, it has to load enough chunks right away to serve HSP's interrogation of the blocks. In most situations, especially with the majority of teleports being "safe", this results in a single chunk being loaded and the player being teleported, which on fast servers with SSD disk, is a non-event.

In other circumstances, perhaps where the targeted location is NOT safe and just so happens to fall on the border of 4 chunks, safeTeleport might require Bukkit to load 4 chunks in order to do processing. On a slower server that is loading chunks off a 5400 rpm disk, for example, this can result in noticeable lag since the server has to stop and wait for those chunks to be loaded before processing other events.

The fix here is obvious: turn off core.safeTeleport. I leave it on by default because it seems to be a useful feature that most people enjoy and most MC servers are either small enough that it doesn't matter or big enough that they run on dedicated hardware, so it's a very rare case where this actually causes an issue.

Outside of those two scenarios, for which the defaults remain the same between 1.7 and 2.0, I'm not sure of what could have caused such a drastic difference between the two versions. But, as I said, HSP 2.0 did include a major refactor and some intentional performance improvements and was developed over a period of 2 years, so it's entirely possible I fixed something and just don't remember it. In any case, I'm glad 2.0 performs much better - I just wish I knew why. :)

@TomXPro

There is no direct integration with Lifestones, so you cannot use HSP to setup rules on death that check for lifestones and then do something else if they don't exist.

If you prefer to have Lifestones controlling your onDeath sequences and don't want to do anything different, then just set your HSP onDeath event to default and HSP will do nothing, ensuring Lifestones gets the event and has control.

If your goal is to have Lifestones do something if set and then have HSP do something else if there is no Lifestone, that would require an integration with HSP, much like I've done with plugins like Multiverse or Worldguard, where HSP can do special things since it has knowledge of how those plugins work.

Example 2 goes into events.yml, yes. The examples were all written for pre-2.0 and while they work fine in 2.0, the configs in 2.0 are broken out so as to be more approachable to new folks and not have a single monstrous config.yml file. The individual configs maintain the exact same syntax so all examples work the same, you just have to put them in the appropriate config file.

@andune

Though @ThisUsernameIsMine linked to an example, just to explicitly cover the first situation, you would setup a custom homeLimit permission in homeLimits.yml as I mentioned, like so:

homeLimits:
  permission:
    permissions: [donator.worldXYZ]
    perWorld: 5

In this example, anybody with permission "donator.worldXYZ" would have a perWorld limit of 5 homes. As I explained, you would use your permission plugin to assign this permission to your donators only on the world you wanted them to have 5 homes instead of the default.

@H1DD3NxN1NJA

Thanks to @ThisUsernameIsMine for the helpful reply.

Regarding donators homes, yes, use the perPermission settings and give your donators a permission that only they have in the world you want (you need to use your Permissions plugin to do this - all of them that I know of support per-world permission). You can make up your own permissions. For example, you might choose "donator.worldXYZ" and assign it to your donators only on world XYZ. Then in HSP, use the homeLimits config to give "donator.worldXYZ" some higher limits, which of course will only take effect on that world since that's the only world you've assigned that permission on. Make sense?

Regarding disabling spawn, the easiest way to is to disable any HSP processing on spawn events, most notable is "onJoin", ie:

events:
  onJoin:
    - default

In this configuration, HSP won't do anything onJoin, so whatever other plugin you have running will control the on-join spawn behavior. For commands, HSP is fairly unique in that you can explicitly disable commands and it won't process them at all, so the other plugin is guaranteed to get the /spawn command instead. Here's an example for commands.yml:

commands:
  disabledCommands:
    - spawn

With this set, HSP won't even register the /spawn command at all, so some other plugin will get it. If you have multiple other plugins that register /spawn commands, you will have to deal with their system for disabling the ones you don't want, which usually involves cracking open the JAR and editing the plugin.yml.

@ThisUsernameIsMine

I suppose that could make sense, if the auth plugin you were using were constantly trying to teleport the player to some location every time they moved at all. Those events are coming pretty fast, multiple per second. The crossworld teleport doesn't make sense, unless they are logging in on a default world and that plugin is trying to send them somewhere else, and the teleport is failing for some reason. Then HSP would see that plugin trying to teleport them crossworld repeatedly and the logs you showed make sense in that scenario.