custom commands and events
Custom commands and events
The features described on this page are only available in HSP 1.7 or later
So, you really like the idea of random spawns, but you don't really want it to be part of your existing event chains. What you want is a "/spawnrandom" command. But, the next server admin wants a special command "/spawnoriginal" to let people go to their saved original spawn. And some other guy wants "/spawnregion" to allow you to teleport to WorldGuard region spawns.
I don't really want to add all those commands to HSP, that's just confusing for new folks and who knows what other custom commands people will want. So as of HSP 1.7, you can now define custom commands and event chains. You can even use this new system to remap existing commands. Let's take a look at an example.
commands: spawnrandom: class: CustomEventCommand event: myrandomspawn aliases: [sr] events: myrandomspawn: - spawnLocalRandom
What did we just do? We defined a custom command /spawnrandom (with an alias /sr), that when run, invokes the HSP command class "CustomEventCommand". This special command was added in 1.7 and it will examine the "event" argument and run the event chain associated with it. In this case, we've set it to "myrandomspawn" event chain, which we then define to run the "spawnLocalRandom" strategy. And just like that, we have a new /spawnrandom command for our players to use. By default it is permission restricted to hsp.command.spawnrandom just like other HSP commands and you can also define cooldowns, warmups and costs for it, just like other HSP commands.
Remapping or disabling existing commands
What if you don't want to use some HSP commands and want to disable them or perhaps rename some or add aliases to others? Easy enough:
commands: # these commands won't be loaded at all and won't exist disabledCommands: - groupSpawn - homeInvite - homelist # add "sh" alias to /sethome command sethome: aliases: [sh] # we disabled "/homelist" above, so it won't exist. But instead we # want the command to be called "/homes", so we map that # command to HomeList homes: class: HomeList aliases: [homes]
These are just examples, you can do whatever you want with the custom commands. For a listing of existing command classes you can use, look at the commands package on github. All of them are valid classes that you can use.
HSP 1.7 has a new feature that keeps track of the last location a player was at when they leave each world. Lets say you wanted to use this feature to provide your players a "/lastloc" command. Here are a few different ways you could do it. (These examples actually require HSP 1.7.1 to work properly)
In this example we are providing players with the /lastloc command. CustomEventCommand will pass along any additional argument by default and the spawnLastLocation strategy will interpret that argument as the world. Thus, this example allows a player to type /lastloc world2 to be taken to their last location on world2. Typing /lastloc with no argument would take them to their last location on the current world.
commands: lastloc: class: CustomEventCommand event: lastloc aliases: [ll] events: lastloc: - spawnLastLocation
Well that's cool, but what if you only want your players to be able to go to their lastLocation on myworld and not any world they want?
commands: lastloc: class: CustomEventCommand event: lastloc noArg: true aliases: [ll] events: lastloc: - spawnLastLocation:myworld
Here we have set the parameter noArg to true, which tells CustomEventCommand to not pass along the player argument. This is important, because spawnLastLocation strategy will prefer a player argument over it's initialized argument. Then notice we set the argument for spawnLastLocation to myworld. So now typing /lastloc will always take you to your last location on myworld, even if you try to pass it an argument.
Just because we can, let's get fancy. Let's say we want players to go to their lastLocation on two different worlds, world1 and world2. However we don't want them to be able to use lastloc to go to any other world. Here we go:
commands: lastloc: class: CustomEventCommand event: lastloc noArg: true aliases: [ll] events: lastloc: - modeSourceWorld:world1 - spawnLastLocation:world2 - modeSourceWorld:world2 - spawnLastLocation:world1
So what did we do? First notice the noArg setting again - we don't let the player pass in an argument. Next, we're using modeSourceWorld to restrict the strategies to only running when the player is on a certain world. So when they are on world1, we use the strategy to send them to world2 and vice versa. If they're on some other world (such as world3), then nothing at all happens.