Hey Psychotechno,
Yes, exactly!
As I mentioned, the script is interacting with a live game, so every game interaction could fail. Therefore, if your script is entirely deterministic, the script will always be in a position to retry an action until it succeeds (which will cause the 'game state' to change, thereby allowing the script to progress).
The code that you have shared is not quite deterministic; we can prove this by simply looking at your banking statement:
if (!getBank().isOpen()) {
// ...
getBank().open();
log("Bank was opened");
getBank().depositAll();
log("Stuff was deposited");
// ...
}
Let's say that the game is in a state where the bank is not open, thus the above condition evaluates to true and the inner code block executes. First, the script will try to open the bank. This may succeed or fail (high probability of success, but non-zero probability of failure). In either case, the script will next try to deposit everything. This will fail and the script will crash if the bank failed to open initially - uh oh! If the bank opens successfully, then the depositAll may or may not succeed (again, high probability of success). So therefore, for our one input state, we have three potential output states: (1) The bank is not open; (2) The bank is open but your inventory is not empty; and (3) The bank is open and your inventory is empty. In this example, the fact that a single input game state maps to more than two potential output states means that the script is prone to failure. So - how do we prevent this? It's actually very simple:
if (!getBank().isOpen()) {
getBank().open();
} else {
getBank().depositAll();
}
If this was the sole contents of your onLoop, then a single game state maps to exactly two output game states: A success state and a failure state. If a failure state is reached, the game state should remain unchanged, thus the script will re-try the interaction automatically.
Naturally, this is only a simple example, but you can extend this paradigm to your use case. This kind of determinism is what separates low quality scripts, such as those typically written by beginners or found in the local scripts section, from the reliable, high quality scripts found on the SDN (for the most part ).
I hope that made sense, please let me know if anything is still unclear - always happy to help!
-Apa