hpl3:game:scripting:entity_components
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
hpl3:game:scripting:entity_components [2017/04/20 07:23] alexkalopsia [General] Fixed spelling and improved formatting |
hpl3:game:scripting:entity_components [2017/04/20 07:57] (current) alexkalopsia [General] Adapted to be consistent with other parts of the page |
||
|---|---|---|---|
| Line 61: | Line 61: | ||
| </code> | </code> | ||
| - | \\ | ||
| Note that you only have to define the actions that you want, so for instance a Stop state might only be something like: | Note that you only have to define the actions that you want, so for instance a Stop state might only be something like: | ||
| Line 73: | Line 72: | ||
| </code> | </code> | ||
| - | And skip Update, etc. (This is actually the best practice too!) | + | And skip Update, etc. (This is actually the best practice too!) |
| ==== Sub State ==== | ==== Sub State ==== | ||
| + | |||
| A sub state is just like a state that runs along side the normal state. What makes it different is that they only last as long as the state that started it. Also sub states cannot change the normal state, only what the next substate will be. It can be sort of seen a smaller state machine inside a state. The sub states are created just like normal states but using the ''AddSubState(tString, int)'' method instead. Also note that substates can be shared between all of the states. They only belong to the a state in the sense that a sub state started in state X will only run while state X is active. | A sub state is just like a state that runs along side the normal state. What makes it different is that they only last as long as the state that started it. Also sub states cannot change the normal state, only what the next substate will be. It can be sort of seen a smaller state machine inside a state. The sub states are created just like normal states but using the ''AddSubState(tString, int)'' method instead. Also note that substates can be shared between all of the states. They only belong to the a state in the sense that a sub state started in state X will only run while state X is active. | ||
| The function syntax for sub states is:\\ | The function syntax for sub states is:\\ | ||
| - | ''void SubState_[StateName]_[Action]'' | + | ''void SubState_[StateName]_[Action]'' For example: |
| - | For example: | + | <code c++> |
| - | <code c++>void SubState_ThrowObject_Enter()</code> | + | void SubState_ThrowObject_Enter() |
| + | </code> | ||
| When a sub state is over, the state that started it has the action ''SubStateOver(int alSubStateId)'' called, where ''alSubStateId'' contains the id of the sub state. | When a sub state is over, the state that started it has the action ''SubStateOver(int alSubStateId)'' called, where ''alSubStateId'' contains the id of the sub state. | ||
| - | Sub state as all the same actions as the normal state except for SubStateOver(int alSubStateId) | + | Sub state has all the same actions as the normal state except for SubStateOver(int alSubStateId) |
| + | |||
| + | Another important feature of sub states is that there does not have to be one set. So it is okay to do: | ||
| + | |||
| + | <code c++> | ||
| + | mpStateMachine.ChangeSubState(-1) | ||
| + | </code> | ||
| - | Another important feature of sub states is that there not has to be one set. So it is okay to do: | ||
| - | <code c++> mpStateMachine.ChangeSubState(-1)</code> | ||
| which set no state at all as sub state. This is actually the default setting when ever a new normal state is started. | which set no state at all as sub state. This is actually the default setting when ever a new normal state is started. | ||
| Line 162: | Line 167: | ||
| ==== General ==== | ==== General ==== | ||
| - | This will make the entitie's head follow a certain target. What is the head is set b setting up the bones that makes up the neck and how much influence each should have. This is done using Setup(...) or by using the variables in the .ent file (use LoadFromVariables from the script to load the variables). | + | |
| + | This will make the entity's head follow a certain target. The HeadTracker component needs to be setup loading up the bones that make up the neck and how much influence they have on each other. This can be done manually through the Setup() method, or by reading the variables in the .ent file using the LoadFromVariables() method. | ||
| ===== ForceEmitter ===== | ===== ForceEmitter ===== | ||
| Line 183: | Line 189: | ||
| ==== General ==== | ==== General ==== | ||
| - | When this is added, the backbone of the entity (as defined in the ent file) will be bent as the entity moves along. It is meant to be used by things like fishes, etc to get more natural like movement, but can of course be used for whatever. Note that all setup should be done in the ent file, and have the component load the type variables. | + | |
| + | When this is added, the backbone of the entity (as defined in the ent file) will be bent as the entity moves along. It is meant to be used by things like fishes, etc to get more natural like movement, but can of course be used for whatever. The BackboneTail component needs to be setup loading up the bones that make up the tail and how much influence they have on each other. This can be done manually through the Setup() method, or by reading the variables in the .ent file using the LoadFromVariables() method. | ||
hpl3/game/scripting/entity_components.1492672990.txt.gz · Last modified: 2017/04/20 07:23 by alexkalopsia
