Enum SceneTransferRefusalReason
Why the server declined to move a character to another scene instance.
public enum SceneTransferRefusalReason : byteFields
The character is already where it asked to go.
Reachable in ordinary play rather than only through a modified client: the channel picker's list is a snapshot, and a character can be moved between instances by the world server's routing between the list being drawn and the player clicking. This refusal used to be a bare
return, which — because the picker closes itself on send — the player experienced as the button doing nothing at all.The character is in a party and cannot join another group's instance without leaving it.
Joining somebody else's run also joins their party. Doing that silently would drop the character out of a group they are already in — and, if they led it, hand that group to somebody else without asking. So it is refused, and leaving is left as the player's own deliberate act.
The character's state changed and no longer permits the transfer (combat, death, mid-teleport).
The destination is full.
The destination no longer exists, or never did.
The instance the request named is not one the requester may join.
It closed, went private, filled, or was never joinable and the row ID was guessed. All four are reported the same way on purpose: a refusal that distinguished them would let an ID be probed to learn whether a particular instance exists.
The transfer is still on cooldown for this character.
The character, or its party, already has a different instance open.
A party may hold one instance at a time, not one per dungeon. Without that rule a party could open a live copy of every dungeon on the shard — enter one, walk out, enter the next — and each abandoned copy held a full physics scene and a scene row until its own idle timeout expired.
Distinct from DestinationFull: the instance they hold is not the one they asked for, so there is nothing to join. They have to finish it, close it, or wait for it to expire.
The character does not meet the difficulty's own entry requirements.
A dungeon declares its requirements per difficulty — a minimum level, a minimum party size — so the same character can be turned away from Hard and welcomed on Normal. Kept distinct from CharacterStateChanged because it is not transient: waiting will not fix it, and telling the player it might is worse than telling them nothing.
The server could not complete the request and the client should try again.
No specific reason available.
Remarks
Both voluntary scene-instance transfers — a channel switch and a dungeon entrance — finish their validation asynchronously, against the database, after the client has already committed to the action and closed its own UI. Every one of those checks could previously fail by simply returning, so a refused request was indistinguishable from a lost one: the player saw nothing at all and had no way to tell "the channel filled up" from "the game stopped responding". Naming the refusal is what makes the action answerable.