Scope of states and variables?
| Author | Topic: Scope of states and variables? |
|---|---|
|
Apprentice
Member # 3084
|
written Sunday, August 15 2004 08:30
Profile
Wow: long time, no post. Between getting married, moving into a new place, starting a new job, and — most importantly — trying to master the BoA editor and Avernumscript :) , there hasn’t been much time for anything else. I’ve spent as much time as I could spare with the BoA editor and manual, but right now I think I’m missing something: namely, a way to simulate user-defined functions as they behave in other programming languages. First off (to avoid “RTFM” responses) I realize several things: 1. Certain script states can be called from multiple places to do things. 2. SDFs can be used to simulate integer arguments to “function” states. 3. ...Just as they can be used to hold integer values “returned” from “function” states. I’m unclear on the scope of states and variables, however. For instance: 1. STATES: The appendix states that you can use run_scenario_state(short which_node) to call scenario states — presumably anywhere. Likewise, it states that you can use run_town_script(short which_node) from dialogue, creature, or terrain scripts. My question is this: is the reverse possible? That is, 1.a. Can scenario scripts call town script states? If so, I imagine that only the current town’s states can be called because no other towns’ scripts are in memory. (Correct?) 1.b. Can town scripts invoke other towns’ script states? (I’m guessing not, for the same not-in-memory reason.) 1.c. Can scenario or town scripts call states in terrain and creature scripts? I imagine that all of the above can be accomplished indirectly with a combination of SDFs and messaging, but I wanted to know if I’m on the right track. 2. VARIABLES: I declared and set a variable in a scenario script, but when I tried to use that value in the code block of a town’s dialogue node, it was unrecognized. 2.a. Are SDFs the only “global variables” available for use? 2.b. If so, how can we fake passing string “arguments” to and from “function” states? I imagine that the string buffer could be used for this purpose, but does the buffer retain its contents between states and scripts? E.g., say a town state begins to populate the buffer with “Churl ”, and then calls a scenario script state which appends “is confused” to the buffer before return. What string would be assigned by get_buffer_text when called by the town script after all of that? Despite my best efforts toward due diligence, I’m sure that some (if not all) of my questions deserve “RTFM” responses. If so, please be gentle, and please simply point me to where I can R it in T Fing M. :) [ Sunday, August 15, 2004 14:16: Message edited by: Churl ] Posts: 37 | Registered: Monday, June 9 2003 07:00 |
|
Agent
Member # 2820
|
written Monday, August 16 2004 18:40
Profile
Remember that the system is very simple. The states are not functions (more like labels). Creature and terrain scripts are finite state machines that are contained within themselves. Certain triggers will activate some of their states, but otherwise there is no direct way of interacting with them in particular. Broadcasted messages might work if you are skilled. A variable's scope is the script that it was declared in. It is necessary to realize that each script loaded in memory is a separate entity from each other; mainly because they are not 'linked' together if you know what I mean. :) No script is a subset of another one. No inheritance. You cannot use variables in a dialogue script because it is supposed to be a static script, like the objects script. You must call a state in the town to access the town's variables, or use an SDF. A note about SDFs: Each one is an unsigned integer byte. Variables are remembered for as long as the script is *supposed* to be in memory. Memory Cells are reset every time you reenter a town UNLESS the character has joined your party and is following you. I suppose it is possible to call a town state from the scenario script, but you cannot access variables from each other. You cannot call the states of another script unless it is the state of the current town or scenario. The buffer that Avernum maintains is really just that. There is a single 254 (or 5, I can't remember if string constants are delimited by a quote AND a null) stetch of char bytes for you to stick text into. It is always remembered, even with saves. There are only 2 data types you should need to worry about in Avernumscript; short and string. ALL functions (not procedures) return shorts, never strings. Probably didn't want to have to deal with pointing to arbitrary strings and such. The buffer calls are pretty sufficient for now, I think. You will have to manually use the code to stick specific strings into arguments. You may only DECLARE a variable once because there is only a single scope in a script, and that is iteself. I'm afraid you can't do something like this: [ Monday, August 16, 2004 18:45: Message edited by: Garrison ] -------------------- Thuryl: I mean, most of us don't go around consuming our own bodily fluids, no matter how delicious they are. ==== Alorael: War and violence would end if we all had each other's babies! ==== Drakefyre: Those are hideous mangos. Posts: 1415 | Registered: Thursday, March 27 2003 08:00 |
|
Off With Their Heads
Member # 4045
|
written Monday, August 16 2004 20:07
Profile
Homepage
As a much shorter but essentially identical answer: 1. a. Correct. This can be done. b. Correct, again. This cannot be done. c. No. Yes, with states and SDFs, you can muck around with this a great deal. START_STATEs are useful for this sort of thing, for instance. 2. a. Yes. That is, unless you feel like calling the scenario script to use one of its states and have access to its variables, which you can do at any time. b. The buffer stays as the buffer in memory. It is global. In your example, you would end up with "Churl is confused" in the text buffer. [ Monday, August 16, 2004 20:08: Message edited by: Kelandon ] -------------------- Arancaytar: Every time you ask people to compare TM and Kel, you endanger the poor, fluffy kittens. Smoo: Get ready to face the walls! Ephesos: In conclusion, yarr. Kelandon's Pink and Pretty Page!!: the authorized location for all things by me The Archive of all released BoE scenarios ever Posts: 7968 | Registered: Saturday, February 28 2004 08:00 |
|
Warrior
Member # 4202
|
written Tuesday, August 17 2004 02:50
Profile
Homepage
quote:It's wrong. You can't use that call in a scenario script. -------------------- Creator of the 3D Blades of Avernum Editor for Mac. Get it at Ingenious Isaac's Illusion, my web page. Better yet, get Battle for Wesnoth, a wonderful free TBS game. Posts: 192 | Registered: Sunday, April 4 2004 08:00 |
|
Off With Their Heads
Member # 4045
|
written Tuesday, August 17 2004 06:10
Profile
Homepage
Erm, but you would just use set_state_continue for the same purpose. -------------------- Arancaytar: Every time you ask people to compare TM and Kel, you endanger the poor, fluffy kittens. Smoo: Get ready to face the walls! Ephesos: In conclusion, yarr. Kelandon's Pink and Pretty Page!!: the authorized location for all things by me The Archive of all released BoE scenarios ever Posts: 7968 | Registered: Saturday, February 28 2004 08:00 |
|
Apprentice
Member # 3084
|
written Wednesday, August 18 2004 08:16
Profile
Thanks to everyone who has replied so far. I've found that the first step in learning a programming language is to find out what it can and can't do. (…Followed, of course, by finding out how to make it do what it can do.) Posts: 37 | Registered: Monday, June 9 2003 07:00 |