custom commands and events

Custom commands and events

The features described on this page are only available in HSP 1.7 or later

Custom Commands

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.

LastLoc example

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)

Example1

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

Example2

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.

Example3

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.


Comments

Posts Quoted:
Reply
Clear All Quotes