At a glance
Quick facts
- Protection source
- A tile or zone flag, not the visual appearance of a room
- Combat effect
- Aggressive combat is rejected in protected contexts
- Combat lock
- Can prevent entry, logout, travel, or selected interactions
- Temple rule
- A temple is commonly protected, but the map flags determine actual behavior
A protection zone is map state
Players recognize depots, temples, houses, and safe rooms visually, but the server decides protection from tile and zone state. Decorative stone, depot lockers, a temple altar, or a teleport effect does not make a tile safe by itself. Map flags and server callbacks do.
Combat state and movement restrictions
- 01
Aggression begins
An aggressive action may add an in-fight condition, a protection-zone lock, and a skull state depending on world type and target relationship.
- 02
Entry is evaluated
When a player attempts to move into a protected tile, the engine checks the current zone, destination flags, and combat lock.
- 03
Travel systems check state
Boats, NPC travel, scripted teleports, logout, beds, and event portals may add their own combat or protection checks.
- 04
Timers expire
The in-fight icon, protection-zone lock, and skull are related but not interchangeable. Their configured durations can differ.
The stock TFS 1.6 configuration sets pzLocked to 60,000 milliseconds and whiteSkullTime to 15 minutes. These are defaults, not guaranteed values on a listed server. A server can also keep the visible in-fight state longer than the short entry lock or add scripts that block teleports after recent damage.
Temple and return-position behavior
A character return position is normally stored independently from the protection flag. Death, first login, town changes, citizenship, or account-manager flows can update that position. A correct temple setup therefore needs a valid destination coordinate, walkable floor, protected tile flags, enough free placement space, and a town or return-position mapping that references the intended location.
- Confirm the destination exists on the deployed map and on the correct floor.
- Confirm the exact arrival tile and nearby fallback tiles are walkable.
- Confirm temple tiles are protected and do not contain unintended floor-change or damage fields.
- Confirm each town identifier maps to the correct temple position.
- Test first login, ordinary death, red/black-skull death rules, and relocation after a map update.
Teleports cross two independent locations
A teleport has an origin interaction and a destination. The origin can be inside a protection zone while the destination is unsafe, or the reverse. Event scripts may also bypass ordinary walking checks. A proper audit records both tile states, destination walkability, return path, level and storage requirements, combat-lock behavior, and what happens when the destination is occupied.
| Case | Origin | Destination | Expected check |
|---|---|---|---|
| Depot exit | Protected | Unprotected | Combat lock normally irrelevant until leaving; destination must be safe to place |
| Arena entrance | Unprotected | Combat area | Entry storage, party, cooldown, and occupied tile handling |
| Escape portal | Combat area | Protected | Recent-combat policy must be explicit |
| Death return | Any | temple | Town mapping, placement fallback, and protection flag |
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.