AGS v2.7 Final: Yet Another Edition

[SSH]

If you load the "Default game" template as new game in beta 7, spend ages setting up a bunch of stuff , importing sprites, etc, and then save the game without having a room file, it crashes without any warning/dialog after the dialog box about "no room files" is OKed...

I'm not going to try and reproduce this, tho  It doesn't happen if you do it straight away after using that template... I guess it may be dependednt on sommething I changed (and lost). Oh, I also did run a "Recompile all room files" earlier on, which appeared to do nothing at the time.

The "edit this AGS game" file had been modified, as had Compiled/acsetup.cfg, but all other files had not been changed from when I first created game from template (1 hour 40  mins earlier  )

There were backup versions of the .dta and .spr files in the game directory, with the older modification times.

[Rui 'Trovatore' Pires]

Actually, I've had similar problems recently. Never COULD reproduce them. Random weirds instances where AGS quits.

[Pumaman]

if (gui == gStatusbar) {...}

Could this be added, CJ?

Yeah that could be added. The only reason I'm nervous to is because people won't necessarily realise it's a pointer comparison, and might assume it does a proper full struct compare. Not too important with GUIs, but if you had some sort of custom struct it has potential to confuse people.

But actually, this is probably the neatest solution. It avoids the dummy object, allows it still to return null which is the OO-way, and still makes comparing the result a single if statement, as before.

Unfortunately, the compiler won't allow to compare a base pointer with a pointer to an object of a child struct. I see a workaround in allowing pointer comparison regardless of their types but this is, of course, not the best solution as we may end up comparing two entirely different objects (although, such if-blocks shouldn't run at run time as long as both pointers don't hold nulls).

Yeah, allowing base pointer comparisons sounds like the neatest solution here.

It seems rather arbitrary which errors crash your game, and which merely put a warning in the logfile, for instance. Also, I believe that teleporting to a non-existant room (especailly with the ^X debug command) should not crash your game, but for instance stay in the current room.

Well, the idea is that errors are given for things where there is no reasonable default course of action, and where the game author needs to fix the problem. For example, a NewRoom failure could stay in the current room, but that wouldn't be intuitive and people would complain "NewRoom doens't work!!!!11".

If you load the "Default game" template as new game in beta 7, spend ages setting up a bunch of stuff , importing sprites, etc, and then save the game without having a room file, it crashes without any warning/dialog after the dialog box about "no room files" is OKed...

Sorry to hear that ... I've not had any such problems myself, and it's strange that there was no error dialog either.

Save early, save often, as they say.

There were backup versions of the .dta and .spr files in the game directory, with the older modification times.

That's strange in itself. The backup spr file is only created once the ac2game.dta has been saved successfully, so if you have a .spr backup then you should have a working ac2game.dta. Unless the backup was created as part of the New Game creation process, of course.

[strazer]

Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?

[Pumaman]

Can I make a struct member variable that can be written only by functions of the struct but can be read directly by all other functions?
Do I really need to make Getxxx functions for every variable?

Interesting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.

Anyway, beta 8 is now up. This fixes a few things, and adds a float data type. Currently Display() doesn't support floats, so there's no way to display the current value of one other than doing a FloatToInt on it and displaying the rounded value. I'm looking into solutions for this.

Now that's definitely the last beta before Christmas -- I'm off for a Christmas break tomorrow. Have a great holiday, everyone! 

[strazer]

Interesting idea, I'll certainly consider it. Can you think of a snappy keyword to represent this?
readonlyexternal comes to mind, but that's a bit unwieldy.

Actually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?
How about "writeprotected"?

Happy holidays!

[RickJ]

Here are a few possible keywords for the "readonlyexternal" thingie,

• readonly, readonlyext
  
• readext  or readexternal
  
• readpub or readpublic
  
• writeprotected
  
• protectedw

[Gilbert]

Sorry if I made a mistake or it was answered already, as I didn't really have a better look on the beta until now. (Since I have absolutely no knowledge in OO-scripting, it's something completely alien to me).

As what I can see currently, when using GUI functions, you have to use something like gInventory.Whatever() (it seems you can't use things like gui[1].Whatever() like characters and objects do), normally that's okay, but for some more advanced stuff this can be a pain. Say for example:
1. You cant do things like this easily:

int a=0;
while (a<5) {
  GUIOff(a);
  a++;
}

2. Say for example I have a battle system, where you control 3 characters, each have a similar GUI to control his actions (say #3-#5, all appear at the sametime), to simplify the codes you can do something like below in InterfaceClick():

if ((interface>=3)||(interface<=5)){ //clicked on battle GUIs
  if (button==1) { //attack
     //blah blah attack action for appropiate character
  } else if (button==2) {.....
      ....
  }
}

If I insist on using this new OO convention you may need to repeat the scripts several times.

So, does this mean that I have to use old style scripting instead in these circumstances? That way the old functions can't be all made obsolete actually, and it's not quite possible to change everything to this OO format anyway. (Or are there ways around such problems? I don't know anything about OO so I can't tell).

[SSH]

Second Gilbot's suggestion of a gui[n] array....

Actually, now that GUIs can have their own individual handlers, would it be possible to allow import and export of individual GUIs rather than always havign to load and save the whole set of GUIs. That would be another boon to co-operative development: it would also make it easier for someone to import, for example a Savegame-with-screenshot GUI on top of whatever GUIs they are using already.

Another thing that I thoguht would be nice is to have user-defined Game properties, like you have room, onject, character properties already. And, as I think is on your list already, sepearate schemeas for the different types of object.

The nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like  anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?

[RickJ]

..  would it be possible to allow import and export individual GUIs rather than always havign to load and save the whole set of GUIs.

I second SSH's suggestion as long as there was an "ALL" option.   I think this would be helpful to some people.

[SSH]

A couple more things....

I got that crash again, and it is very intermittent. Fortunately this time I had saved 30 seconds before again. It always seems to happen on a save, but I reloaded my 30-second old game and tried doing the same chnages again (it was all just changing stuff on the game settings page). This time it saved OK.  Something intermittent like this implies "memory leak" to me!

I suggest you try loading in a bunch of sprites, editing GUIs, change stuff here and there for a while and see if you can get the crash too, CJ. I'd never seen this instability before this beta, and I think it will really bug people.

Secondly, if you have a GUI control you called the object handle goPUsh by mistake and you want to change it to goPush, it wont let you and you have to rename it via "temp" or something first then back to what you wanted. It seems that the object check is case-insensitive, and also includes itself if the check of clashing names...

[Proskrito]

I second Gilbots suggestion aswell, and extend it to gui buttons also. It would be great to have gui[n].button[n] or something similar.

Also, not sure if its related to this beta or even if its my fault, but i have 4 guis i want to resize at the same time. 3 of them i have no problem with, but there is one that does not resize properly, unless i write the resizing function twice.
this does not work:
gFri.SetSize(HRES - xright,FHEIGHT);
but this works:
gFri.SetSize(HRES - xright,FHEIGHT);
gFri.SetSize(HRES - xright,FHEIGHT);
seemed strange to me, so i thought i'd say it just in case.
thanks for all the hard work chris : )

[Radiant]

For what it's worth, I agree with Gilbot and SSH's earlier suggestions.

For nomenclature, the things in rooms have always been called objects in AGS, so I think they should stay that way. The OOP-objects could be referred to as classes, maybe? Like they are in C++.
Properties... well maybe this could be cleared up by referring to room.properties, character.properties, etc.

[Pumaman]

Actually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?

You may want to manipulate the data before you return it.

Case in point -- the character[].idleview variable. Because internally AGS stores the view number minus 1, giving the script direct access to it caused confusion and problems. With a GetIdleView approach (via the property), the script can be given the correct value that it expects.

Here are a few possible keywords for the "readonlyexternal" thingie

Thanks, I'll have a think about it.

As what I can see currently, when using GUI functions, you have to use something like gInventory.Whatever() (it seems you can't use things like gui[1].Whatever() like characters and objects do), normally that's okay, but for some more advanced stuff this can be a pain. Say for example:

I agree, a gui[] array would be useful. The only thing is, a lot of people will have "int gui" variables so I don't want to name the array "gui" because it will cause all sorts of problems. So then, I could call it "guis" instead but that's inconsistent. Ah well, nothing's perfect.

Actually, now that GUIs can have their own individual handlers, would it be possible to allow import and export of individual GUIs rather than always havign to load and save the whole set of GUIs. That would be another boon to co-operative development: it would also make it easier for someone to import, for example a Savegame-with-screenshot GUI on top of whatever GUIs they are using already.

Yeah, that's something that could reasonably be added now. And with names rather than numbers, it doesn't matter if the imported GUI has a different number to where it was exported from.

The nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like Ã, anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?

I agree -- Ã, the object (struct) thing vs the object (room object) thing is particularly confusing -- any ideas on how to clarify this would be welcome.

I got that crash again, and it is very intermittent. Fortunately this time I had saved 30 seconds before again. It always seems to happen on a save, but I reloaded my 30-second old game and tried doing the same chnages again (it was all just changing stuff on the game settings page). This time it saved OK.

Hmm, I'll try and see if I can replicate it. How long did you work in the editor for before the crash happened?

Secondly, if you have a GUI control you called the object handle goPUsh by mistake and you want to change it to goPush, it wont let you and you have to rename it via "temp" or something first then back to what you wanted. It seems that the object check is case-insensitive, and also includes itself if the check of clashing names...

I'll look into it.

Also, not sure if its related to this beta or even if its my fault, but i have 4 guis i want to resize at the same time. 3 of them i have no problem with, but there is one that does not resize properly, unless i write the resizing function twice.

That's very strange, can you upload something that replicates the problem?

[Pumaman]

I got that crash again, and it is very intermittent.

I've just been investigating this, and I have managed to get a crash myself, but whether it's the same one or not, I don't know.

The crash I'm getting happens if you have been editing a room with no code in its room script, and didn't save the room before loading another one. I'll get it fixed, but does this sound like something you'd have done in the time leading up to the crash?

[Snarky]

Actually, I thought that was what "protected" would do. After all, what's the harm of reading a variable?

You may want to manipulate the data before you return it.

Case in point -- the character[].idleview variable. Because internally AGS stores the view number minus 1, giving the script direct access to it caused confusion and problems. With a GetIdleView approach (via the property), the script can be given the correct value that it expects.

Here are a few possible keywords for the "readonlyexternal" thingie

Thanks, I'll have a think about it.

I don't know if you're familiar with C#, but it uses a concept it calls Properties (though it seems we're already using that word for three other things, one of which I've always called member variables) to get around the GetX()/SetX() inconvenience. You can define a member "variable" that is actually a pair of methods:

Code: ags

private int m_hiddenvariable;

public int MyProperty
{
Ã,  Ã, get
Ã,  Ã, {
Ã,  Ã,  Ã,  return m_hiddenvariable;
Ã,  Ã, }
Ã,  Ã, set
Ã,  Ã, {
Ã,  Ã,  Ã,  m_hiddenvariable = value;
Ã,  Ã, }
}

If you omit the "set" block, the property can be read but not written to. The "get" and "set" blocks can manipulate the output and input data (for instance to perform bounds checking or handle special cases).

For nomenclature, the things in rooms have always been called objects in AGS, so I think they should stay that way. The OOP-objects could be referred to as classes, maybe? Like they are in C++.

Objects aren't called classes in C++. They're called objects. A class is a type of object, and an object is an instance of a class.

The nomenclature is getting a bit confused now, too. I mean we have Objects (OOP) and Objects (in rooms), and we have Properties (OOP), Properties (things like Ã, anti-glide mode) and Properties (user defined schema)... maybe some thoguht needs to go on giving them well-defined and different naming conventions?

I agree -- Ã, the object (struct) thing vs the object (room object) thing is particularly confusing -- any ideas on how to clarify this would be welcome.

How about talking about game objects and game properties (or AGS objects/AGS properties) when referring to the AGS concepts, and just objects and properties (or variables) when referring to the OO concepts? Or renaming the old "objects" to "items".

[Pumaman]

don't know if you're familiar with C#, but it uses a concept it calls Properties

Yeah, this is what AGS does for the built-in properties, it just doesn't currently support them for user-written script.

How about talking about game objects and game properties (or AGS objects/AGS properties) when referring to the AGS concepts, and just objects and properties (or variables) when referring to the OO concepts? Or renaming the old "objects" to "items".

I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.

[RickJ]

I really don't want to rename the old objects to something else -- that would cause no end of confusion. We do need some way to make it distinct -- perhaps have another word (totally unlike "object") for the script OO objects.

Previously, in this thread, I have used "oobject"  and "object" to make the distinction.   I don't think I could make the case that "oobject" is totally unlike "object" though.    

So instead why not just call them "structures" instead of "objects".  I know that those of us with C or C++ experience will find this suggestion unpleaseant (I do as well.).    However, if we can put our prejudice aside for a moment, IMHO, we may be able to see some merit in this idea.  I think most of the folks will find it easy to make the connetion between "struct" and "structure"  and will be untroubled by the terminology.    Those of us who who have enough programmng experience to not like it should, by definition,  have enough programming experience to get over it. 

[strazer]

Maybe it's just my Linux chm viewer acting up but could it be that a lot of entries for the new functions don't link to their anchors on the respective pages in the help file?

Also, I'm in favor of object-ising walkable areas, regions and walkbehinds as well.
As it is now, their functions seem out-of-place compared to the rest of the scripting language.
I vote for at least grouping them via static member functions so you have the advantage of auto-completion.

And how about merging PlaySound and PlaySoundEx now that parameters can be optional?
Not specifying a channel would use PlaySound as usual, otherwise it would act like PlaySoundEx.

[Radiant]

Little bug: GUIs are displayed under 'display' text, but over 'displayspeech' text.