Its almost like your writing your script like a scriptObject. //move all boxes ? is your end goal to feed in multiple boxes that all do roughly the same thing?
Anyway i digress,
1) The space around the functions is what you could call a global area, hence anything set up in here is globaly available to all your functions. A better name maybe Namespace, if you were to look at the ID maps you will find their script are not actually in the maps folder but in the scripts folder and all their function are rapped in a Namespace( tag. e.g
Code:
namespace mynamespace{
float myglobalfloatvariable;
//globaly available to any functions within the enclosing namespace
void main(){
//blah
}
void myotherfunction(){
//blah
)
)
When you right your own map script and place it in the map folder (i presumming, needs tessting, that this namespace convention is defaulted to the name of the script, hence your map name.
For general script writing using namespacing allows you to have multiple functions with the same name, inside the same script file. e.g
Code:
namespace mynamespace1{
void myfunction(){
//blah
}
}
namespace mynamespace2{
void myfunction(){
//blah
}
}
To call either of these, say for example from a trigger, i think would be something like "call" "mynamespace::myfunction". I believe thats correct but i have never really had any call to use namespaces.
Quote:
(2) Is it possible to refer to a vector declared / assigned in a function that is called within another function?
Not without it first being decalred in the global area or passed along to a function call.
Another possability is to keep it on the entity as a k/v pair so you can recall it from where ever you like.
e.g
Code:
void main(){
$myentity.setKey("var1",$myentity.getWorldOrigin());
//write the kv to myentity
}
void myotherfunction(){
vector entitypos = $myentity.getVectorKey("var1");
//retrieve kv value into a variable from a different function
}
___________________________________
Getting back to my initial query about feeding in multiple entitys that do roughly the same thing,
THIS may be worth a read for reference (will also elude to why the word 'object' was causing you problems), maybe a little over the top for your needs? but shows a different route of making entitys that roughly do the same thing, all share a common script, yet run their own versions of it.