Hey,
my brief question:
Is it possible to have a health variable and to add it to the character[] struct? That would be really useful because right now you'd have to declare a new struct (for example "person") and then have person.health but if you want to check the x or y coordinate of the same person you'd have to use character.x or .y! a possibility to create a new character.health var would be great!
You cannot extend built-in types, no. This is a possibility for a future version.
Edit:
AGS v2.8 Alpha 7:
Quote from: Pumaman on Sat 12/05/2007 00:11:47
* Added support for script extender functions
(...)
What is an extender method?
It's a feature that people have been asking for for quite a while; the easiest way is to give an example:
function SayHello(this Character*)
{
this.Say("Hello");
}
and then later on in the script you can do:
player.SayHello();
character[EGO].SayHello();
etc
Basically, it allows module authors to add extra methods to the built-in types like Character.
Ok, thank you for the reply.
I have another question:
How is it possible to create a self-made var in a self-made struct?
Something like this:
struct structY
{
int a;
int b;
};
struct structX
{
int c;
int d;
structY e;
};
structX F;
Do you get what I mean?
It would allow you to do something like this:
F.e.a
It returns an error for me!
structs inside structs are not currently supported.
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=19369.msg247561#msg247561
Well, if you put one in the header file and the other in the global script, it works...Perhaps not "supported," but it works...
[Edit: Realized date of posts...]
Sorry about this bump, but I hope this code is still relevant to [ ... ]. I was linked to this thread and didn't realize it had been over a month since the last post.
Thanks - yes, it still is very relevant to me, since I will restart 'Troopers' - my project - once again and then code in the 'new' 2.7 style, but I'll wait with that until the official 2.7 is out!
Well that's good to know...But why wait till the official 2.7 comes out? It's pretty much finished as far as I can tell except some bug-fixes...I'd say just get started and get the jump on things.
Hmm..... I don't remember right now why I wanted to wait until the official 2.7 comes out... Strange...
Anyways, I've got too much private (not computer related) stuff to do right now, so I'll have to delay the project for a week at least anyways...
That doesn't really belong in this thread anymore, so I guess I'll shut up now... :)
Sorry for digging this back up, but I have a relevant question (and I can't find any information in the tracker). Will structs within structs ever be supported? I know I already provided a workaround, but I have discovered a situation where it would be very preferable if I could have a third level of structure-age.
Basically it would be easier to keep track of each half of a long dialog option as an individual item in the SM I am making. i.e., I would need at least three structs (something like):
struct DialogHalf {
char text[200];
protected DlgScroll_OptState state; /* enum (values: on, off, offByScrolling, offForever); protected to prevent illegal values, i.e. turning on an "offForever" option */
import function getState();
import function setState(DlgScroll_OptState state);
};
struct DialogOption {
char text[200];
protected DlgScroll_OptState state; /* same as above */
import function getState();
import function setState(DlgScroll_OptState state);
short length;
DialogHalf half[2];
};
struct Dialog {
opt[30];
};
Dialog dlg[500];
That way I could do something like:
if (dlg[42].opt[12].length > 318) gLabel0.SetText(dlg[42].opt[12].half[0];
else gLabel0.SetText(dlg[42].opt[12].text);
It may not be apparent here why this would be easier, but when keeping track of when only the second half of an option should be shown (as in scrolling) this would be invaluable. Otherwise I'll have to find some way to undermine the way AGS currently works (as I've done before :)).
Edit: I also realize the similarities between DialogHalf and DialogOption, but I intentionally chose not to inherit DialogHalf in this case. If I could actually use these structs in this manner I might change my mind...
Yes, it's a possibility for a future version. However, I can't promise any timescales.
I have found a workaround for my problem, but it will probably be frowned on a lot. It involves creating another Script Module placed before the DlgScroll module and defining the DialogHalf struct in the header of this new module. It compiles and works correctly, however creating a new module simply to define a struct seems wasteful. But yet, it's the simplest solution I can see.