Annotation Interface CmdCD
@CmdMapping method as subject to a per-player cooldown.
Enforcement requires a CooldownValidator in the executor's
ValidatorChain. The default chain
built by BaseCommandExecutor.createDefaultValidatorChain()
supplies one. A custom chain that omits CooldownValidator while a mapping -- or the
executor class itself -- declares this annotation is refused at plugin load, naming the
offending class and, when known, the offending mapping method (SILENT-11 / D-01, D-04). No
opt-out exists for this refusal: Phase 3 D-08's module-granularity isolation is the accepted
escape hatch -- the offending module alone fails to load, every other module still starts.
As of 6.3.0 this annotation may also be applied at the class level. CooldownValidator
resolves it most-derived-wins: a mapping method's own @CmdCD first, then a class-level
one on the concrete executor class, then one on the method's declaring class. A class-level
annotation therefore cools down every mapping that does not declare its own.
Binding the cooldown to a config key (6.3.0)
Instead ofvalue(), key() can name a @ConfigEntry path on the module's
own config entity, given by config(); the value is in seconds, like value():
@CmdCD(config = EssentialsConfig.class, key = "features.wild.cooldown")
- The default lives only in the config field. Leave
value()unset; setting both refuses the module at load. - Checked at load, refusing the module alone and naming the key and the value, when
the config class is not registered exactly once for the module, the key matches no
@ConfigEntrypath, the field is not anint,long,IntegerorLong, or the value is negative,nullor aboveInteger.MAX_VALUE. A bound value of0means "no cooldown", the same asvalue = 0. - Applied at
/ul reload. The resolved seconds are cached per executor and refreshed only after a successful configuration reload, so a panel edit takes effect at the next/ul reloadand a refused reload never takes effect. An invalid value on reload keeps the running one and logs a WARNING. A cooldown already running keeps the end time it was stamped with, whatever the new value is: a reload to0stamps no new cooldown, and the running ones expire on their own. Executors sharing one validator chain keep all their bindings. - Panel edits are range-checked. A panel write that sets a bound key outside this
range (a negative value, for example) is refused like a
@Rangeviolation, and nothing is written. - No
@Rangeon a bound field. The binding's range above is the field's range. A module@Rangeon the same field would make an out-of-range reload throw from the config reload itself, which aborts the rest of that module's reload (issue #509) instead of keeping the running value. - Modules only. A binding in an External Plugin API executor is refused.
- Declare
api-version: 630in the module'splugin.yml: an older framework silently ignores these elements and would enforce no cooldown at all. 6.3.0 refuses a module that uses a binding while declaring a lowerapi-version.
- See Also:
-
Optional Element Summary
Optional Elements
-
Element Details
-
value
int value- Returns:
- cooldown time in seconds; a value of 0 or less disables the cooldown for this
mapping. Leave unset when
key()is set.
- Default:
0
-
config
Class<? extends AbstractConfigEntity> configConfig entity class whose@ConfigEntrykeykey()names; it must be registered exactly once for the module. Default:AbstractConfigEntityitself, meaning unbound. See "Binding the cooldown to a config key" above.- Returns:
- the bound config entity class
- Since:
- 6.3.0
- Default:
com.ultikits.ultitools.abstracts.AbstractConfigEntity.class
-
key
String key@ConfigEntrypath whose value, in seconds (0 for no cooldown), is the cooldown. Matched as@ConfigEntry(path = ...)declares it, or the field name when the path is empty. Requiresconfig(); excludesvalue(). Default: unbound.- Returns:
- the bound cooldown key
- Since:
- 6.3.0
- Default:
""
-