AGS v2.7 Final: Yet Another Edition

[RickJ]

Is there anything that you guys is particularly important that should be added before 2.7 goes Final?

I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.

I agree with Strazer.Ã,  It would make more complete/useful, etc...

[SSH]

Is there anything that you guys is particularly important that should be added before 2.7 goes Final?

I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.

Seconded, or thirded, or whatever...

RunDialogOption(topic, option)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.

This would be nice, but is work-aroundable, unlike the most-important thing, the single GUI import/export

[strazer]

This would be nice, but is work-aroundable

Right. Scratch that.

[Jet Kobayashi Zala]

For the 2.7 Final:

Hmm... I'm not sure if this is a bug... has anyone tried the "Based on X-Position" option for textboxes? It seems to not work for me.  I'm assuming from the help that it's based on the speaking character's X-Position, however, it doesn't seem to work for my test game.  Has the new OO-izing killed the feature inadvertedly?

Hmm... can't really think of anything else to include considering all the new additions and posted recommendations made already.

[strazer]

the "Based on X-Position" option for textboxes

I don't understand what feature you mean. Are you referring to TextBox gui controls? Display() guis? Character.SayAt?

[Rui 'Trovatore' Pires]

I think he's talking about the character portraits in Sierra-Style speech.

[Pumaman]

I think being able to have repeatedly_execute, game_start, on_event, on_key_press, etc. in modules is pretty important. It would make their inclusion more user-friendly.

Yeah, I guess it would. I'm a bit concerned about performance if repeatedly_execute is done so I"ll have to consider that, but the other handlers could definitely be added.

Rename "No interaction" checkbox
See my comment in there.

Display room info on "Areas" pane
Should be an easy one and results in one less tracker entry.

These two sound reasonable, and I agree it would be a good time to clean them up.

LECTalkView + SierraTalkView
I think we should decide on an approach now. Unfortunately, I have no idea what the best way would be.

Ok, well I think the easiest solution would probably be to have a PortraitView property for the sierra style; and the normal SpeechView would then contain the lucasarts view if the combi speech style was selected.

Import/Export single GUI
I didn't see a practical use for this before, but now that modules are implemented, I agree with SSH that this would be pretty handy.

Yes, I can see the benefits of this. The GUI im/ex-port needs to be updated anyway to handle the control event handlers.

RunDialogOption(topic, option)
Until more customizable dialog option GUIs are possible, this would make workarounds more flexible. See my comment in there.

I agree with your later comment that this isn't necessary for 2.7.

Hmm... I'm not sure if this is a bug... has anyone tried the "Based on X-Position" option for textboxes? It seems to not work for me.

In what way doesn't it work? The feature is supposed to determine whether the portrait appears on the left or right of the screen, depending on which character is standing to the left/right of the other. Nothing more.

[Rui 'Trovatore' Pires]

CJ, could you please allow more than 20 properties? I need it, I really do. I've reached the limit of properties you can have, and I need more. I don't know how many more... how does 10 more sound?

EDIT - And I suppose we won't be seeing "SetProperty" this time around, will we? :

Nevermind, I worked around it. But:

If we can't set a properties' text... is there any chance we can set the property to a string and then access and edit the string like a common string? That'd be a workaround, I guess...

[RickJ]

... I'm a bit concerned about performance if repeatedly_execute is done so I"ll have to consider that ...

Ouch, I was hoping to use this.  Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module?   If it is the former case you are concerned about then perhaps a "caveat emptor" disclaimer is all that is necessary.   If it is the latter case I can only plead ignorance and leave it up to your good judgement.   

[strazer]

Ouch, I was hoping to use this.

So was I.

[Jet Kobayashi Zala]

Sorry. With regards to the X-Position option, yes, I'm referring to the Sierra portraits  for the Sierra-Style Speech.  When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech.  I've made entire rooms walkable, walking the character from left to right, but no luck. And, indeed, I have made sure that the right character is calling the Say function.

Note: To display the text, I'm using the character[].Say(), which I think replaced the DisplaySpeech().

[strazer]

Would it be possible for the compiler to support operators (at least + and *) in array declarations?

I'd rather do
  char threedarray[AGS_MAX_VIEWS*AGS_MAX_LOOPS_PER_VIEW*AGS_MAX_FRAMES_PER_LOOP];
than having to put a fixed value in there.

When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech

When I was testing it with a single character saying something, the portrait appeared always on the right side of the screen, regardless whether he was on the left or right side of the screen.
When I had another character (char 2) say something immediately afterwards from the same interaction, his portrait appeared on the left side (char 1 was standing right of char 2). If char 1 stands left of char 2, char 1's speech appears left, char 2's right.
So it seems to depend on the number of Say commands in the script and the position of the characters relative to each other.
I agree the portrait should appear on the side of the screen the char is at if you use a single Say command.

[SSH]

The text dump of scripts should include modules (although maybe not if they are set to non-editable)

It would also be nice if scripts were dumped in the roder they are compiled, at the momentnb header comes last and rooms cripts first which is kind of backwards...

and I'd want a module rep_ex, too...

[AGA]

I have no idea if this has already been suggested, but I don't really care...

The option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.

[Jet Kobayashi Zala]

When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech

When I was testing it with a single character saying something, the portrait appeared always on the right side of the screen, regardless whether he was on the left or right side of the screen.
When I had another character (char 2) say something immediately afterwards from the same interaction, his portrait appeared on the left side (char 1 was standing right of char 2). If char 1 stands left of char 2, char 1's speech appears left, char 2's right.
So it seems to depend on the number of Say commands in the script and the position of the characters relative to each other.
I agree the portrait should appear on the side of the screen the char is at if you use a single Say command.

Strazer, I just tried the same test and noticed something else. If I start a set of says with two characters, they appear on the correct side. However, if I run the dialog, switch sides and talk again (just by moving char 1 to the opposite side he was on from char 2), the char 1's first textbox (which is the first dialog in the speech), still appears as if he was on the previous side for the first textbox.  That is:

Char 1     Char 2
Talk, all is fine.
Char 1 walks to the right of Char 2
Char 2     Char 1
Talk, and Char 1 portrait is still shown on the left for first speech, then char 2 speech is shown with portrait on the left, then Char 1 is shown again, but on the right side.

[Pumaman]

If we can't set a properties' text... is there any chance we can set the property to a string and then access and edit the string like a common string? That'd be a workaround, I guess...

I'm not really sure what you're asking, but changable custom properties are not something that will be implemented for 2.7.

Ouch, I was hoping to use this.  Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module?

Yeah it's to do with the internal overhead, however I have some ideas on how to streamline it, so this may not be an issue.

Sorry. With regards to the X-Position option, yes, I'm referring to the Sierra portraits  for the Sierra-Style Speech.  When I was testing it, no matter which side of the screen the character was on (that is, whether left or right), it still displayed the portrait on the left side of the speech.

This feature is by no means perfect. For example, the first character to speak will always have their portrait on the left, since on the first Say line it doesn't know who they're talking to. Also, if characters move around and switch positions in between speech lines this fact is not necessarily picked up.

Would it be possible for the compiler to support operators (at least + and *) in array declarations?

This is actually non-trivial to add but I'll bear it in mind.

The option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.

Well, if you mean putting every single function in its own module then it would be possible, but the overhead of having 300 script modules would probably outweigh the benefits.

[RickJ]

Ouch, I was hoping to use this.  Are you talking about a peformance hit because of what the user script may be doing or because of internal overhead accessing stuff in a module?

Yeah it's to do with the internal overhead, however I have some ideas on how to streamline it, so this may not be an issue.

Thanks for the effort, I hope you are able to find a suitable solution.   For whatever it's worth,  if the performance penalty is incurred only when rep_ex() is included then it is perhaps tolerable.  It would just need to be noted in t he module description or header that this is the case.   I don't mean to disuade you from  attempting to eliminate the problem, but rather, to assure you that  I/we are willing to work around it if need be.   

The option to modularise entire #sections would be great. It would effectively remove the need for a global script, but it would be a lot easier to keep track, especially now GUI scripts have changed the way they have.

Well, if you mean putting every single function in its own module then it would be possible, but the overhead of having 300 script modules would probably outweigh the benefits.

I don't know exactly what AGA had in mind in his original question but it made me  think along the lines of having seperate modules for character interactions inventory interactions, etc.  So I guess there would be something similar to one module for each character, one module for the inventory, one module for GUIs, etc.      rather than one module for each interaction function.

The automatically inserted/deleted interaction functions, IMHO, can get a bit untidy/unmaganeable as a game grows in size.   Perhaps another approach would be to use #section directives to manage the groups I describe above and maintain the global script as is.  The editor could then have some additional bookmarks and perhaps edit buttons in the inventory and character editor tabs.   

[SSH]

The text dump of scripts should include modules (although maybe not if they are set to non-editable)

It would also be nice if scripts were dumped in the roder they are compiled, at the momentnb header comes last and rooms cripts first which is kind of backwards...

and I'd want a module rep_ex, too...

If there is an overhead in accessing modules from rep_ex, does this apply to a global rep_ex calling a module function, too? That would be much more serious!

[AGA]

I don't know exactly what AGA had in mind in his original question but it made me  think along the lines of having seperate modules for character interactions inventory interactions, etc.  So I guess there would be something similar to one module for each character, one module for the inventory, one module for GUIs, etc.      rather than one module for each interaction function.

Yeah, that's what I meant. Not one module for every individual GUI interaction, one for every inventory item etc, but one big module for ALL GUI interactions, one for all inventory etc. So you'd end up with about 5 or 6 different, largeish modules.

[Pumaman]

If there is an overhead in accessing modules from rep_ex, does this apply to a global rep_ex calling a module function, too? That would be much more serious!

No, it doesn't apply to that.

Yeah, that's what I meant. Not one module for every individual GUI interaction, one for every inventory item etc, but one big module for ALL GUI interactions, one for all inventory etc. So you'd end up with about 5 or 6 different, largeish modules.

That's not a bad idea ... I'll bear it in mind for 2.71.