Odd struct error message [SOLVED]

Started by Chrille, Tue 19/01/2010 20:35:37

Previous topic - Next topic

Chrille

At the top of my global script there is some code for a struct which causes this error message:
"GlobalScript.asc(56): Error (line 56): Attributes of identifier do not match prototype"

Here is the code:
Code: ags
  struct InteractZone {
    String zoneTitle;
    int zoneImage;
    String zoneType;
  };

  InteractZone zoneHotspot[10];
  InteractZone zoneObject[10];


Line 56 is the one about 'InteractZone zoneHotspot[10];'
I tried searching both google and the forums for that exact error message and got no results at all. Could it be something further down in the script causing the error message?
GASPOP software
http://www.gaspop.com

Khris

I copied that piece of code to a default game's global script, compiled fine for me.

Try moving the struct declaration to the header. If the instances are supposed to be global, you'll have to do that anyway.

monkey0506

That error message generally indicates that you have an improper import-definition relation somewhere. For example:

Code: ags
import String some_func();

int some_func() { // error -- function does not match import
}


Are you providing an import for this somewhere that could be different than the actual definition you've provided?

Chrille

That was indeed the case, I'd accidently placed an int before the imports. Thanks!
GASPOP software
http://www.gaspop.com

Chrille

I'd like to follow this up by asking exactly how you're supposed to export & import the InteractZone struct & the zoneHotspot bit in a script header because everything I tried gave me errors. In the end I placed the code mentioned earlier directly in the global script header.

But, I've run into a new problem with this struct. I mentioned in another recent thread I was planning on using it for retrieving data for hotspot interactions. In a room script, when the room loads, I set the attributes of the zoneHotspot array slots to things like maniHotspot[1]zoneTitle = "Bla"; etc.. So when the cursor is over a hotspot it's supposed to read from the array slot matching the ID of the hotspot the cursor is over.

The problem is that it doesn't return anything. When ask for, say, Display ("zoneHotspot[1].zoneTitle") in the room script, 'Bla' shows up perfectly. But asking for it from the global script I get nothing. I'm sure I did something wrong by putting the struct info in the header, but what?
GASPOP software
http://www.gaspop.com

monkey0506

#5
Well if there's issues with the way it's being imported/exported then that would probably be the reason for the room script/global script discrepancies.

Particularly if you're defining the instances of your struct (i.e., zoneHotspot, zoneObject, etc.) in a script header then you're creating a new instance by that name for every single subsequent script.

The proper procedure for using structs across multiple scripts this way is:

Code: ags
// Header.ash

struct InteractZone {
  String zoneTitle;
  int zoneImage;
  String zoneType;
};

import InteractZone zoneHotspot[10];
import InteractZone zoneObject[10];

// Script.asc

InteractZone zoneHotspot[10];
export zoneHotspot;
InteractZone zoneObject[10];
export zoneObject;

// WhateverScript.asc

zoneHotspot[5].zoneTitle = "LOLWUT?";


The important things to take away from this:
  • The struct definition must appear in the script header so other scripts will know what the structure of the struct is.
  • You place imports in the script header, just like you would normal variables.
  • For arrays, the import must define the size of the array.
  • The instances of your struct go in the main script file, not the header.
  • You must export the instances of your struct after they have been defined.
  • For arrays, the export does not define the size of the array, just the name.

    Now there are those who would say that "proper" OO programming dictates that you should encapsulate these properties with getter and setter functions. But that's just creating a bunch of needless work on yourself. To them I say, check out the implications of the undocumented (and unsupported!) keyword attribute combined with this idea of extender methods...:)

    But for those who don't care about all that silliness, the way you're doing it is fine, so long as you adhere to the appropriate procedures for sharing the data across your scripts.

Khris

To elaborate a tiny bit:

An import line must contain the complete declaration line, e.g.

import int health;
import bool star_visible[100];
import function DrawStar(int x, int y, int radius);


An export line must contain the name, nothing else, e.g.

export health;
export star_visible;


Functions don't need to be exported.

Chrille

Thanks for clearing things up! It took me quite a while to switch to the new interaction system but now it works perfectly.
GASPOP software
http://www.gaspop.com

SMF spam blocked by CleanTalk