AGS v2.7 Final: Yet Another Edition

[Ishmael]

character[].ChangeRoom(room,x,y)

Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from. This way I can elimate the character ending up stuck outside a walkable area and all.

[rich]

I like the new object oriented thing that's going on here. I do have two questins though:

1. Will there be any new written documentation to explain all of these new commands?

2. Seeing how the 1-letter word bug was fixed with the text parser, is there a chance that the two-word synonym feature will be added in 2.63 or will it be a later release? (e.g. "pick up" will be acceptable as a synonym for "get"). Right now, it simply looks like spaces are not accepted in words.

Thanks for all of your wonderful work, Chris!

Rich

[Rui 'Trovatore' Pires]

Silly question, I suppose, but will "player" still be a substitute for "character[]"?

Oh, and is there no way to update "player" whenever the main character changes?

[strazer]

I think player is just internally defined like

Code: ags

#define player character[EGO]

Have you tried defining it yourself, like

Code: ags

// Main header script

#define player character[GetPlayerCharacter()]

?

[Pumaman]

character[].ChangeRoom(room,x,y)

Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from.

This sort of thing is exactly why I'm having this consultation. If you think it would be useful to keep a ChangeRoom command without co-ordinates, that can be arranged.

1. Will there be any new written documentation to explain all of these new commands?

The manual will be updated to list the new commands before the Final is released.

2. Seeing how the 1-letter word bug was fixed with the text parser, is there a chance that the two-word synonym feature will be added in 2.63 or will it be a later release? (e.g. "pick up" will be acceptable as a synonym for "get"). Right now, it simply looks like spaces are not accepted in words.

I cannot make any guarantees about which suggestions will get into the next version and which will not, I'm afraid.

Silly question, I suppose, but will "player" still be a substitute for "character[]"?

Oh, and is there no way to update "player" whenever the main character changes?

Ideally I'd like to add this, but it's not a priority feature. We'll see how things go.

[Kweepa]

About blocking in Move commands, coordinates in ChangeRoom, etc.

I think the clearest thing is that ChangeRoom takes one parameter, the room number. Then SetPosition moves the character. Shoehorning multiple functionality, however related, into a function call is ugly, and unreadable.

Similarly, moving blocking out into a separate function means that you don't need multiple versions of every possible action. So I'm for it.

As for direct, I think that should be in the function name, so you've got Walk() and WalkDirect(). Much more readable than Walk(x, y, 1);

Looks like some great changes for AGS. It may make it more confusing for newbies, but they'll be learning...

Cheers,
Steve

[Dan2552]

character[].ChangeRoom(room,x,y)

Are the x and y needed parameters? I hope not, because I've got used to moving the character to the appropriate location in the destination room, depending on the room the character came from. This way I can elimate the character ending up stuck outside a walkable area and all.

couldn't that be just

Code: ags

character[EGO].ChangeRoom(1,character[EGO].x,character[EGO].y)

i cant remember if thats how AGS works.  but if you think about it it should.

[Radiant]

Very interesting changes!

I do have some suggestions on consistency, and clarity to new users...

How about LockView and UnlockView, rather than set and release?
Considering what it does, SetIdleState should be named SetIdleView.
This one is nitpicky, but I would like 'talk' renamed to 'say'.

I think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof. Come to think of it, it isn't entirely logical that 'char[].ChangeRoom' also changes the visible room if the char specified happens to be the player character, but I can't think of a good workaround.

If you're going consistent in removing 'Ex' and other related functions, then you should consider removing TalkBackground, and instead, making the backgroundness a parameter to Talk. And also maybe to Think and TalkAt.

Shouldn't MoveStraight have direct and blocking parameters?
AddWalkPath might be renamed to AddWayPoint, since that's what it actually does, and it might need a 'direct' parameter.

It doesn't really bother me, but this is inconsistent:

Code: ags

character[EGO].z = 10;
character[EGO].SetTransparency (10);

(e.g. logically, both would be a function or a member var; the advantage of making the latter a member var is that reading it or doing math on it is easier; that's just my preference, I know C canon states that you should use Set and Get functions).
Same thing applies to Add and Loseinv; I tend to use 'char

• .inv[y] = z' sometimes, so if you're making that read-only I would like to have a SetInv function.
  
  For consistency, there is a FaceChar and FaceLoc, but no FaceObj. There is a MoveToLoc and MoveToObj, but no MoveToChar.
  By the way, it would be nice to have a 'blocking' parameter to FaceCharacter / FaceLocation, since then you can use it in rep_ex_always to have an NPC keep watching the player character.
  
  MoveToWalkableArea might be nice with a parameter that states if the character 'teleports' there (as it does now), or simply walks there.
  
  Is it an idea to use 'default' parameters with functions (e.g. if the user doesn't specify a function's last parameter, a default value is used, like in C++)? Or would that be too confusing, or too annoying to code?
  
  The three basic behaviors in AGI games (other than standing still) are chase, wander and avoid. Chase is obviously implemented, and I believe that Avoid isn't actually used in any AGI game anyway. However, it may be nice to add a function 'character[].Wander (int walkable_area_number, or maybe region_number instead)' that makes the character wander around randomly. Of course it's easy to put this in a script instead, but newbies might appreciate it.
  
  Would it be possible to have SetCharView an option to also lock into a certain loop? So that it won't get changed to a direction loop if you move the character.
  
  Unrelated to this, I believe GetTextWidth() should have a maximum width parameter. Why? Suppose I have a string that has no line breaks. If its GTW is larger than the screen's width, or it's put on a GUI label or something, it will get wrapped. But you can't tell in advance where exactly it will be wrapped.
  

[Pumaman]

I think the clearest thing is that ChangeRoom takes one parameter, the room number. Then SetPosition moves the character. Shoehorning multiple functionality, however related, into a function call is ugly, and unreadable.

I agree, to some extent. However, the reason that NewRoomEx was added in the first place was that people wanted a quick way to change room and set position in one go. Perhaps it would've been better never to introduce it, I don't know.

As for direct, I think that should be in the function name, so you've got Walk() and WalkDirect(). Much more readable than Walk(x, y, 1);

I'd like to avoid having duplicate functions that do very similar things. However, what I will do is provide some defines (eg. BLOCKING=1, NON_BLOCKING=0) so that the function call is more readable in the script.

It may make it more confusing for newbies, but they'll be learning...

Actually, I think it'll make it easier to learn. Just typing "character[EGO]." and being given a list of things you can do is easier to pick up than guessing which functions operate on a character

How about LockView and UnlockView, rather than set and release?
Considering what it does, SetIdleState should be named SetIdleView.
This one is nitpicky, but I would like 'talk' renamed to 'say'.

LockView is a good idea -- I think that could still be partnered with ReleaseView, though I can see the argument for it to be called Unlock.

As for "Say", I agree actually that it's a better verb to use for the situation. If nobody objects, I'll use it.

I think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.

Yeah, I thought the same thing. However, otherwise it becomes the only function that still takes a CHARID as a parameter, which I'm sure would confuse people who would try and use "character[EGO]" as the parameter, and so on.
So I'm not sure about this one.

If you're going consistent in removing 'Ex' and other related functions, then you should consider removing TalkBackground, and instead, making the backgroundness a parameter to Talk. And also maybe to Think and TalkAt.

I did consider this, but I think Talk is one of those functions that should be as simple to use as possible, so I don't really want to add an extra parameter to it. I can see your point though.

Shouldn't MoveStraight have direct and blocking parameters?

Well, there'd be no point in a "direct" parameter because then it would do the same thing as MoveCharacterDirect. A blocking parameter would be possible just for consistency's sake, although I can't see it getting used in this context.

AddWalkPath might be renamed to AddWayPoint, since that's what it actually does, and it might need a 'direct' parameter.

Good idea, I like how that sounds.

It doesn't really bother me, but this is inconsistent:

Code:
character[EGO].z = 10;
character[EGO].SetTransparency (10);

I agree -- and in fact, one thing I have added since the beta is support for Properties. These are basically functions disguised as normal variables, which will mean that instead of doing
SetCharacterTransparency(EGO, 10);
you can do:
character[EGO].Transparency = 10;

It still actually generates code to make the function call so still works as it should, but is far more intuitive to use.

For consistency, there is a FaceChar and FaceLoc, but no FaceObj. There is a MoveToLoc and MoveToObj, but no MoveToChar.

FaceObject is a definite possibility.
As for the MoveToXXX functions, I'm not sure whether to remove them completely ... all the co-ordinates can be obtained and then used with Walk anyway.
I don't think these really get used -- probably because of the somewhat arbitrary location that the character is moved to relative to the object. But do correct me if they're useful.

Is it an idea to use 'default' parameters with functions (e.g. if the user doesn't specify a function's last parameter, a default value is used, like in C++)? Or would that be too confusing, or too annoying to code?

That's something I'd like to add, yes. So that Walk, for example, would be non-direct and blocking by default, but you could specify the extra parameters if you wanted to.

However, it may be nice to add a function 'character[].Wander (int walkable_area_number, or maybe region_number instead)' that makes the character wander around randomly. Of course it's easy to put this in a script instead, but newbies might appreciate it.

This is certainly something to consider as a future feature -- but it doesn't directly affect this renaming exercise and can always be added as an additional function later on.

Would it be possible to have SetCharView an option to also lock into a certain loop? So that it won't get changed to a direction loop if you move the character.

I've wanted to actually stop movement affecting the sprite at all while the view is locked, but this would have caused too many backwards compatibility problems. This may be a good opportunity to re-visit this, however.

Unrelated to this, I believe GetTextWidth() should have a maximum width parameter. Why? Suppose I have a string that has no line breaks. If its GTW is larger than the screen's width, or it's put on a GUI label or something, it will get wrapped. But you can't tell in advance where exactly it will be wrapped.

I can appreciate that, but let's try to concentrate on one thing at a time 

[Rui 'Trovatore' Pires]

About the whole room changing matter... I'd just like to say that I, myself, have never used NewRoom. I ALWAYS use NewRoomEx, and wouldn't like to see that ability go, myself.

[Radiant]

I think 'character.skipuntildone' sounds confusing, since this command isn't an action affecting the character, so it shouldn't be a member thereof.

Yeah, I thought the same thing. However, otherwise it becomes the only function that still takes a CHARID as a parameter, which I'm sure would confuse people who would try and use "character[EGO]" as the parameter, and so on.

Good point. But, it would fit in better with StartCutscene etc. At least you should rename the function, as the character itself doesn't skip. Maybe something like WalkAndFastForwardGame.

I agree -- and in fact, one thing I have added since the beta is support for Properties. These are basically functions disguised as normal variables, which will mean that instead of doing
SetCharacterTransparency(EGO, 10);
you can do:
character[EGO].Transparency = 10;

What about char[ego].transparency ++  ?

As for the MoveToXXX functions, I'm not sure whether to remove them completely ... all the co-ordinates can be obtained and then used with Walk anyway.
I don't think these really get used -- probably because of the somewhat arbitrary location that the character is moved to relative to the object. But do correct me if they're useful.

I never use MoveToChar, since it causes the two chars to overlap (for conversation, for instance, you'd want the two chars to end up face to face near each other, but not overlapped). I do occasionally use MoveToObject, specifically if the object is an inventory item that can be picked up. I wouldn't really miss it if it were removed though.

Is it an idea to use 'default' parameters with functions

That's something I'd like to add, yes. So that Walk, for example, would be non-direct and blocking by default, but you could specify the extra parameters if you wanted to.

Ah, but then you could to char[ego].say ("Hello", BLOCKING); 

One more thing, all the functions for characters refer to 'moving', but the variable that can be checked if the character is still moving, is called 'walking'.

By the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.

Am I correct to assume that, other than char[].* functions, there will be Object[2].Transparency = 5, and stuff like that?

[Pumaman]

But, it would fit in better with StartCutscene etc. At least you should rename the function, as the character itself doesn't skip. Maybe something like WalkAndFastForwardGame.

Alright, I think I'll just leave it as is for now, it won't become a member function of Character. We can consider what to do with it later.

What about char[ego].transparency ++  ?

Funny you should ask; the ++ and -- operators are the only ones that will not work with Properties (because of the way they optimise memory reads and writes). But everything else will work as usual, eg:

Character[EGO].Transparency += 1;

or

Character[EGO].Transparency = Character[EGO].Transparency + 1;

would accomplish the same thing.

I wouldn't really miss it if it were removed though.

What about everyone else -- who would miss the MoveToHotspot/MoveToObject functions if they were removed?

Ah, but then you could to char[ego].say ("Hello", BLOCKING);

Aye, but then the problem is it would lose its %d/%s support. So the question is, would you rather have a Say command with an optional Blocking parameter, or two different Say and SayBackground commands, but both supporting %d and %s?

One more thing, all the functions for characters refer to 'moving', but the variable that can be checked if the character is still moving, is called 'walking'.

As you can see, I am renaming the MoveCharacter functions to Walk. This is also to make way for a new Character.Move command which will do the same as Walk, but not play the walking animation.

By the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.

They are compile-time. It's not really possible to have run-time #ifdef's, because the code has already been compiled and you can't suddenly remove half of it.

Am I correct to assume that, other than char[].* functions, there will be Object[2].Transparency = 5, and stuff like that?

In the long term, yes. I'm starting with characters because it's the biggest job and should give the system a proper testing before moving on to the other stuff. The way I look at it, if it all works with characters, it should have no problem with the rest.

[Radiant]

Thanks for the info!

Ah, but then you could to char[ego].say ("Hello", BLOCKING);

Aye, but then the problem is it would lose its %d/%s support. So the question is, would you rather have a Say command with an optional Blocking parameter, or two different Say and SayBackground commands, but both supporting %d and %s?

Good point. I do suppose the %d/%s support is very useful with Say.
That just leaves a possibility of mering SayAt with SayBG, into one SayWithExtraParameters (note that in the old system, you can't do a SayAtBackground anyway)

As you can see, I am renaming the MoveCharacter functions to Walk. This is also to make way for a new Character.Move command which will do the same as Walk, but not play the walking animation.

That sounds a bit confusing... Move is kind of a synonym of Walk. Maybe you could name it something like WalkNoAnim or something.

By the way you mentioned #IFDEFs as a feature... are these compile-time or run-time? Specifically, an #IFDEF LINUX would be useful at runtime to filter out some things that aren't possible in Linux, e.g. non-existent plugins.

They are compile-time. It's not really possible to have run-time #ifdef's, because the code has already been compiled and you can't suddenly remove half of it.

True. But I did notice that some errors in a room script don't trigger unless the player character enters said room. Anyway the reason I'm asking, is that I would like to have some way of running a game that has plugins, in Linux where those plugins don't exist. And since you're working on #directives anyway, would something like this be possible? It would already work if it was just restricted to a single function (e.g. SystemCall, that consists of a windows part and a linux part, and only the part appropriate to your machine gets parsed).

[Scummbuddy]

I didn't want to mention this earlier, because I thought it was my machine, but it seems it may have happened to others...

There seems to be trouble importing templates into the editor.

Here's the current topic that is hinting at it: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=17747.from1100645999#new

I wanted to test something real quick with the latest release, and dropped in Proskrito's MI2 template into the beta folder. Then when I tried to create a new game, the template did not show up. I closed ags and opened it again, and no luck. I added the default template and the blank template, and those showed up. Then I closed ags again, and dropped in all templates I had, 4 proskrito and the 2 normal ags ones. only 2 of proskritos showed up and the 2 default ones showed. I assumed my computer was slow or was low on memory, but gave up.

[Dan2552]

I didn't want to mention this earlier, because I thought it was my machine, but it seems it may have happened to others...

There seems to be trouble importing templates into the editor.

Here's the current topic that is hinting at it: http://www.adventuregamestudio.co.uk/yabb/index.php?topic=17747.from1100645999#new

I wanted to test something real quick with the latest release, and dropped in Proskrito's MI2 template into the beta folder. Then when I tried to create a new game, the template did not show up. I closed ags and opened it again, and no luck. I added the default template and the blank template, and those showed up. Then I closed ags again, and dropped in all templates I had, 4 proskrito and the 2 normal ags ones. only 2 of proskritos showed up and the 2 default ones showed. I assumed my computer was slow or was low on memory, but gave up.

i thought that was only me too 

[Pumaman]

Ok, I've been looking into the templates problem.

There is indeed a bug, which has in fact been there ever since templates were added, but has only surfaced recently due to other changes.

Basically, when you create the template, if you give it a filename longer than 15 characters, it will not always load back into the editor properly.

The workaround for now is simply to make sure that when you create a template, you give it a name of 15 characters or less.

Unfortunately, for templates that are already out there, the user cannot simply rename the file -- this will not work. Therefore, any template authors who this affects, please re-make your templates with a shorter name.

And before anyone asks, the 15 characters excludes the ".agt" extension.

My apologies for the inconvenience.

[Pumaman]

Ok, beta 2 is now available.

This adds the complete set of Character functions and properties. Don't bank on the names all being permanent, because if anyone suggests and useful changes before the next beta I'll probably make them.

As for the Say/SayAt/SayBackground, I've left them as 3 different functions because I couldn't think of a neat way to combine them. If anyone has any bright ideas, do shout.

The new Properties look like normal attributes, but start with a capital letter. For example:
character[EGO].Clickable
is a property, whereas
character[EGO].room
is still the old variable.

One difference you'll notice with properties is that they use the correct view number, NOT the view number minus 1.

For the Animate and Walk functions, the Direct, Direction and Blocking parameters are no longer 1 and 0, there are constants instead:
ANYWHERE / WALKABLE_AREAS  for Direct
FORWARDS / BACKWARDS   for Direction
BLOCKING / IN_BACKGROUND  for Blocking

Finally, I should probably mention default values. For Animate, the defaults are FORWARDS and BLOCKING; for Walk, they are WALKABLE_AREAS and BLOCKING. For WalkStraight, it is IN_BACKGROUND.
Again, these are open to change if appropriate.

Anyway, have a play and let me know your opinions. Remember, there's still time to change things, but this might be your last chance!

[Radiant]

Okay. To avoid confusing people, maybe you could add a Property 'Room' as well? Because having everything capitalized is kind of neat.

And am I correct to assume that ANYWHERE and the other stuff are actually #defined to boolean values? Because personally, I prefer using 1 and 0 (or TRUE and FALSE) to lengthy text strings.

This may be radical, but how about EGO->Clickable as a shorthand for character[EGO].Clickable?

The only useful thing I could think of for the Say trilogy is SayEx, which might combine SayAt and SayBackground. Not sure if that's useful though. The alternative is naming SayBackground 'Whisper' and SayAt 'Ventriloquate'

[Vel]

WoooooHoooo!
Thanks CJ!

[Ishmael]

I'd prefer Walk not being blocking by default, but I guess I can get used to set the value if others find it better the other way...

The reason here is that my current interface does not include any MoveCharacterBlocking commands, nor do the interactions apart from room changes and such where it's neccesary to avoid the player from getting thrown back into the previous room or something.