At a glance
Quick facts
- Spell class
- House commands
- Words
- aleta som
- Minimum level
- Not defined
- Mana values
- Not defined
- Vocations
- No registry restriction
- Combat types
- Utility or script-defined
- Reference profile
- TFS 1.6
The rhythm of Invite Subowners
Every cast tells two stories: the effect that flashes on screen and the decision that follows. Invite Subowners asks for a cost not defined in this profile from no explicit vocation list, begins at no published minimum level, and leaves no published individual cooldown before the same action is ready again.
Invite Subowners belongs to the language of ownership rather than combat. Access rights, house state, command parsing, and the deployed server's housing rules give the words their authority.
Invite Subowners's bound source exposes 0 direct implementation signals across combat types, areas, conditions, and formula declarations. That is enough to trace the intended machinery, but callbacks and shared helpers can still hold decisive math outside the immediate script.
Invite Subowners requirements and spell words
Invite Subowners is represented by 1 player-facing TFS registry entry. Instant entries define spoken words and casting requirements; rune entries define use requirements, rune item ID, charges, target rules, and their own execution script. A conjuring entry and the resulting rune-use entry are separate mechanical actions even when they share the same public name.
| Registry type | Words or activation | Level | Magic level | Mana | Soul | Cooldown | Vocations |
|---|---|---|---|---|---|---|---|
| Instant | aleta som | Not defined | Not defined | Not defined | 0 | Not defined | No vocation restriction in registry entry |
Targeting, aggression, and execution
Registry flags determine whether Invite Subowners needs a target, uses the caster, follows direction, can cross distance, blocks on walls or solid objects, consumes charges, and counts as aggressive. The spell group also controls shared cooldown behavior. The execution script can add area geometry, combat types, conditions, callbacks, item creation, summons, or other effects that do not appear in the one-line registry entry.
| Variant | Group | Range | Targeting | Aggressive | Charges | Script |
|---|---|---|---|---|---|---|
| Instant | Not defined | Script-defined | Script-defined | No | Not applicable | house/invite_subowners.lua |
Damage, area, conditions, and formulas
The implementation signals below are extracted from pinned Lua scripts without guessing missing values. Combat tokens identify declared damage families, area constants identify reusable shapes, condition tokens identify status effects, and setFormula arguments expose formula declarations when the script uses the standard combat API. A callback can still calculate values elsewhere, so an empty formula cell means no direct declaration was detected rather than zero effect.
| Script | Combat type | Area | Conditions | Formula declaration |
|---|---|---|---|---|
| house/invite_subowners.lua | No direct combat type token | Target or script-defined | No condition token detected | No setFormula call detected |
Resource cost and cooldown economy
Evaluate Invite Subowners by both immediate cost and opportunity cost. Mana and soul are paid when the relevant variant succeeds under the active rules, while the individual cooldown and group cooldown determine what can be cast next. Rune charges move part of that cost into preparation and inventory capacity. Premium, learned-spell, weapon, vocation, level, magic-level, target, range, and protection-zone checks can reject a cast before the effect executes.
- Compare individual cooldown with the shared spell-group cooldown.
- Separate rune-conjuring cost from rune-use requirements and remaining charges.
- Verify whether failed casts consume resources or establish cooldowns on the deployed engine.
- Test PvP reduction, protection-zone restrictions, wall blocking, and target legality independently.
Vocation access and tactical use
Invite Subowners has no vocation child in its registry entry. This can indicate a house command, general utility action, rune-use definition, or another spell whose permission is controlled outside the vocation list. Verify account state, access, premium requirements, and script checks before describing it as universally available.
Verification checklist
- 01
Confirm the registry
Compare name, words, IDs, requirements, cooldowns, groups, target flags, and script binding with the deployed spells.xml.
- 02
Read every bound script
Trace combat objects, areas, formulas, callbacks, conditions, created items, and helper modules used by each variant.
- 03
Test boundary conditions
Check minimum level, magic level, mana, soul, vocation, premium, range, walls, target legality, protection zones, cooldown groups, and charges.
- 04
Record observable output
Measure results over controlled level, skill, equipment, resistance, and PvP cases before publishing calculated ranges.
Apply the guide
Find servers using this profile
Server names, protocol labels, and map labels do not guarantee matching mechanics. Use these filters to find candidates, then verify the listing, owner documentation, and deployed ruleset.
