i seem to misunderstand something basic about structs

[ollj]

this problem keeps following me.
i make a struct that has some parameters;

struct IStoreStuff{
int x;
ins y;
String s;
}

IStoreStuff IstoreStufInstance;

and that struct has one or more instances in a scripts header, and silly me expects that, if i read or write any value of any instance (of the very same label) of that struct from anywhere, that it addresses the very same instance. but somehow this is not the case.

simple question. why is my struct not global?
the "export" syntax also seems to do nothing, and is poorly documented.
managed structs in alpha versions? dont get me started, coded so much, just to notice all the limits on managed structs on runtime make them nearly useless.

specifically:
I write a value in the global-scripts-"on_game_start"-function , and silly me expects that any ROOM-script can read from it, addressing the same instance (of the same struct) by the same name, assuming it would get the same prefiously stored parameters.
but no, it reads only zeroes, or even null pointer crashes in array instances of structs as if the array-pointer for the structs instance is a null pointer. otherwise it reads "null/void" values where it clearly should either tell me that this instance is not the same, and just give me the same values i stored from somehwere else in my source code, or that this instance no longer exists. but instead it happily addresses the "shaddow of an instance", and it is possible to write and read from that, and later read from the other instance, both happily sharing the very same instance name of the very same struct (in source code), only being called from different locations/wscripts/functions in source code.
like painting an infinite amount of individual shadows instead of painting the object itself.

[ChamberOfFear]

Could you provide a minimum example of the issue in code?

[Crimson Wizard]

Well, when you first asked, I've  given a link to very similar discussion, where you could read the solution.


The concept is that the contents of the script header are plain copied to every following script module. This means that if you write

Code: ags

MyStruct variable;

in the GlobalScript.ash, then this variable will be defined in GlobalScript AND every room script as a variable local to that script.
Thus creating any number of individual variables, instead of only one variable. These variables will have same name but different memory address.



The solution is to declare the variable as "external", defined somewhere else. This is how it is done.
In the script header you put a declaration:

Code: ags

// MyScript.ash
import IStoreStuff IstoreStufInstance; // this tells the compiler this variable is allocated somewhere else,
                                       // no need to allocate it for every script that declare it

And in the script body - in the one and only script,

Code: ags

// MyScript.asc
IStoreStuff IstoreStufInstance; // this is a normal definition of the variable;
                                // it tells compiler that the variable need to be allocated on global memory
export IstoreStufInstance;      // here you tell the compiler that you export this variable for the use in other scripts;
                                // if you won't write this command, other scripts won't be able to properly address
                                // the variable in memory (and game will fail)

[Khris]

Searching this forum for threads with "export" in the title, the 5th result is "Importing / Exporting structs":
http://www.adventuregamestudio.co.uk/forums/index.php?topic=49706

Also, last time this came up, I wrote
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52399.msg636517166#msg636517166

[ollj]

i finall found the solution, ony my own, and youre all right.

[monkey0506]

This is not a totally uncommon or unheard of mistake, though it is interesting to me how often it is a mistake made by those using the more "advanced" script features like custom structs.

Linkage of variables (read as: "struct instances") works exactly* the same here as it does in, say, C/C++ (*different keywords, and variables must be explicitly exported). The idea that a variable may be intended for script-level scope but not intended for project-level scope is not inconceivable. Personally I like the import/export method as it makes it more explicit that you are referring to a variable defined by some other script and/or that you intend this variable to be used by other scripts.

Another difference, I suppose, is that C++ compilers would probably complain about multiple definition if a variable were defined (rather than just declared) in a header file and included in multiple script files... but that could quite easily be disabled in compiler settings and without any use of "extern" I would expect much the same end-result as well (separate copies of "the same" variable).