Terrain Script Custom states

[Ishad Nha]

The BoA Editor documentation says that you can create your own custom states in a terrain script, as long as you number them from 3 thru 99 inclusive.

 

I tried a state 3 and I got nowhere. Then I put the same code in the Step Into State and there was no problem. Seems the problem was the "State 3" not the code.

 

Has anyone ever gotten a custom state to work in a terrain script?

[Lilith]

Er, how exactly were you calling the custom state? It won't do anything unless you actually call it, usually from one of the standard states in the same script. Does putting set_state_continue(3) in the STEP_INTO_STATE of a terrain script work correctly?

 

Also, state 3 is the START_STATE for most kinds of script, so if you already had a START_STATE defined for the script and it was empty, that would be your problem.

[Ishad Nha]

I was using

"set_state(3);"

Start state is supposed to be 2 for terrain scripts.

Set_state_continue is the only way to make it work, set_state won't work.

[Lilith]

Is there ever actually a good reason to use set_state instead of set_state_continue?

[Niemand]

set_state() is only meaningful in creature scripts, which remember which state they were executing, and will start from there the next time the game calls them. The game will only ever call the named states in a terrain script, so to ever actually run a custom state you need to use set_state_continue().

[Enraged Slith]

What kind of practical application would setting a state in a terrain script have?

[*i]

Every script in BoA has a state that it runs every turn (call it the active state). The default is START_STATE. If you use set_state(n) in the script for the current active state, it switches the active state to be run every turn to state n. I tested this and it does work on the scenario script. I presume the same behavior works on terrain scripts as well.

 

To answer Enraged Slith's question, I suppose you could have some terrain type that acts differently every turn after an event specific to that script has occurred. For instance, a mine could use this. The default START_STATE checks to see if the player is close to initiate the trigger and sets a new state (call it 3) that acts as a timer. After a certain number of ticks, the mine explodes and a new state (4) is set that essentially does nothing. Of course, there are other ways to do this, but this is one possibility where you could use it.

 

EDIT: I should add that if you just want to run a snippet of code and not switch the state that is called every turn, you should use set_state_continue(n) for that. It is confusing, but the two calls are entirely different. I would prefer if Jeff called set_state something else like set_active_state or something to make the difference more clear.

 

[Kelandon]

In other words, you'd only ever use a set_state_continue in a terrain script for the same reasons you'd use set_state_continue in a town script.

[Ishad Nha]

In theory you could save space in a town script by shunting stuff off to a terrain script. Especially repetitious things along the lines of the messages from doorwheel.txt, "This is a large wooden wheel. A chain is wrapped around it several times and then ... "

 

In practice, I don't think anyone has large enough town scripts to require this.

[Dahak]

A point:

 

While you can only trigger states 3-99 by advancing the game a tick, you CAN call states above 99 by calling them from within another state.