When an entity on the Volity network gets an
RPC request that it doesn't understand or accept
at the RPC level, it replies with an RPC fault, sent back via the same
Jabber-RPC protocol that the request came in on, and re-using the request's
id attribute.
According to the XML-RPC spec, a fault consists of a numeric code and a simple text string. When generating faults, Volity implementations should use the text strings as written below, but implementors can adjust them to include more case-specific information if they see fit. On the other hand, implementations must use the numbers exactly as listed here, and (consequently) implementations that receive these RPC faults must parse them by their numeric codes, not by their text strings.
Volity's RPC faults
These faults can be used anywhere in Volity, in either the volity or game namespaces.
- 600: Network failure
- 601: XML syntax error
- 602: Jabber protocol error
- 603: Unknown methodName
- 604: Missing method parameter
- 605: Mismatched parameter type
- 606: Illegal parameter value
- 607: Identity rejected
- 608: Internal error
- 609: Call illegal in this game state
More details
- 604
- Also "too many method parameters", I guess
- 607
- Used by a referee to tell off someone who it doesn't recognize as a player of the current game, and yet seems to be sending game-specific requests.
- 608
- If referee code throws an uncaught exception, the Volity game class can return this.
- 609
- A generic game-level error message. While ruleset implementations should use the ruleset's defined error requests whenever possible, it can use this fault as a fallback for player-generated errors that the ruleset doesn't account for.
See Also
RPC replies