Difference between revisions of "Command Limitations"

From ReflexCLI
Jump to: navigation, search
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 [[Monobhaviour Types]] for details.
+
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==

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:

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 [[Supported Parameter Types/MonoBehaviour]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.