Difference between revisions of "Command Limitations"
| (4 intermediate revisions by the same user not shown) | |||
| Line 10: | Line 10: | ||
Currently, non-static members can only be made into commands if the defining class is a UnityEngine.Component or a class derived from it. Note: this includes any MonoBehaviour scripts you have created, so most of your game code will be able to use non-static members. | Currently, non-static members can only be made into commands if the defining class is a UnityEngine.Component or a class derived from it. Note: this includes any MonoBehaviour scripts you have created, so most of your game code will be able to use non-static members. | ||
| − | This is very useful if you wish to address in-game objects directly from the console. See [[ | + | This is very useful if you wish to address in-game objects directly from the console. See [[Supported Parameter Types/MonoBehaviour|MonoBehaviour Types]] for details. |
==Valid Method Commands== | ==Valid Method Commands== | ||
| − | For methods that are to be implemented, it is important that all parameters have a type that is supported by the console system (See [[Supported Types]]). Alternatively, you can provide custom <code>ParameterProcessor</code> | + | For methods that are to be implemented, it is important that all parameters have a type that is supported by the console system (See [[Supported Parameter Types]]). Alternatively, you can a provide custom <code>ParameterProcessor</code> for your custom Type (see [[Parameter Processors]]). |
===Parameters Marked <code>out</code> and <code>ref</code>=== | ===Parameters Marked <code>out</code> and <code>ref</code>=== | ||
| Line 25: | Line 25: | ||
==Valid Field Commands== | ==Valid Field Commands== | ||
| − | Fields must have a supported type, or be of a type with a custom <code>ParameterProcessor</code> (see [[Supported Types]] and [[Parameter Processors]]) | + | Fields must have a supported type, or be of a type with a custom <code>ParameterProcessor</code> (see [[Supported Parameter Types]] and [[Parameter Processors]]) in order to give then new values. |
| + | |||
| + | Fields marked with <code>const</code> or <code>readonly>/code> cannot be set via the console and therefore do not need to be of a supported type. | ||
==Valid Property Commands== | ==Valid Property Commands== | ||
Properties may implement get{}, set{} or both. | Properties may implement get{}, set{} or both. | ||
| − | If the property implements set{} then it must have a supported type, or be of a type with a custom <code>ParameterProcessor</code> (see [[Supported Types]] and [[Parameter Processors]]). | + | If the property implements set{} then it must have a supported type, or be of a type with a custom <code>ParameterProcessor</code> (see [[Supported Parameter Types]] and [[Parameter Processors]]). |
==Exceptions== | ==Exceptions== | ||
Commands backed by methods or properties may throw exceptions. These will be caught by the console and the exception error message will be displayed in the console output, in lieu of a return value. | Commands backed by methods or properties may throw exceptions. These will be caught by the console and the exception error message will be displayed in the console output, in lieu of a return value. | ||
Latest revision as of 08:16, 23 September 2017
Console commands can be made out of class-member methods, variables and properties, but there are some limitations on how they can be defined:
Contents
Access Level
Reflex Console Commands can be public, protected, or private: any access level is valid. This means you can keep debug commands hidden from your other game code, but still expose them to the Reflex Console
Static / Instance Members
A static member of any class or struct may be made into a command.
Currently, non-static members can only be made into commands if the defining class is a UnityEngine.Component or a class derived from it. Note: this includes any MonoBehaviour scripts you have created, so most of your game code will be able to use non-static members.
This is very useful if you wish to address in-game objects directly from the console. See MonoBehaviour Types for details.
Valid Method Commands
For methods that are to be implemented, it is important that all parameters have a type that is supported by the console system (See Supported Parameter Types). Alternatively, you can a provide custom ParameterProcessor for your custom Type (see Parameter Processors).
Parameters Marked out and ref
The console does not support out or ref parameters yet.
Optional Parameters
Optional parameters are supported and will use the default values from the method declaration if no value is supplied by the user.
Return types
All return types are valid. Any returned objects will be converted to string (using ToString()) and printed to the console output.
Valid Field Commands
Fields must have a supported type, or be of a type with a custom ParameterProcessor (see Supported Parameter Types and Parameter Processors) in order to give then new values.
Fields marked with const or readonly>/code> cannot be set via the console and therefore do not need to be of a supported type.
Valid Property Commands
Properties may implement get{}, set{} or both.
If the property implements set{} then it must have a supported type, or be of a type with a custom <code>ParameterProcessor (see Supported Parameter Types and Parameter Processors).
Exceptions
Commands backed by methods or properties may throw exceptions. These will be caught by the console and the exception error message will be displayed in the console output, in lieu of a return value.
