Say function glitch

[Dualnames]

The .Say command, including the SayAt command appear to be glitched. I have not been able to find the source for the glitch, cause I'm not even doing anything. They seem to work just fine throughout the game, except when over two guis.

Regardless of character or scrolling room, after certain number of Say functions on a row, they are displayed all over the place. I'm using LucasArts speech, and after some tests the character's positions don't change. Somehow though AGS mishandles the x and y position for these texts and well..that.

Advise please. I can always use a SayAt with standard coordinates, but I don't want to.

[Construed]

It may be a problem with a memory leak or such, i was getting a similar problem "ags saying it does not support nested functions" when it was properly bracketed and i recently had a total game.agf crash due to the memory leak...
I would suggest perhaps remaking the gui's, by deleting them and starting over, or if you have scripts that rely on gui numbers, just leave those null and make new ones..

[Khris]

A nested functions error is always a missing bracket. No exceptions.

Dual:
I noticed that GUIs sometimes cause .Say text to be moved. One example is the black bar on top of the Maniac Mansion Mania games; it's there so the original game's layout is maintained and if a character is standing close enough to the top of the screen, their .Say text gets moved down, often appearing on top of their head.

But from what you describe, the length of the message doesn't make a difference, only the number of .Says called before? Could you post a screenshot or something? Otherwise we're stuck at guessing randomly.

[Dualnames]

Sure, let me do that.

First, here follows the code (this is just inside an interaction and only gets processed once):

Code: ags

if (Game.DoOnceOnly("copper_on_motor")) 
{
  cCrispin.FaceCharacter(cEgo, eBlock);
  cCrispin.Say("Hey!");
  cEgo.FaceCharacter(cCrispin, eBlock);
  cCrispin.Say("She gave that to me as a token of her affection!");
  cEgo.Say("I'll give you all the copper wiring you want once we're done here.");
  cCrispin.Say("(Like I want a token of *your* affection.)");
}

//till this point everything appears perfectly

gWiring.Visible=true;
gWiring.Transparency=75;//TEMP
if (Game.DoOnceOnly("copper_on_igmotor2")) 
{
  cEgo.Say("I need to find a way to connect the colored nodes to each other without crossing any wires.");   
  cCrispin.Say("Why don't we just use the plasma torch?");
  cEgo.Say("That's not going to work this time.");
  cCrispin.Say("The crowbar?");
  cEgo.Say("Nope.");
}

Mind you I've taken screenshots at different playthroughs, the second one illustrates that the function works greatly, till that point.

"Nope" appears above "The crowbar?", as if the player has moved there. But the y axis property also glitches if the dialog would carry on.

I made a 3rd screenshot to help stuff a bit.

[Khris]

I tried a few GUI and player positions and tested where AGS would position the player's speech. There's definitely a pattern.
Like I said, it looks like depending on the default speech position in relation to visible GUIs and the size of the "speech sprite", AGS will occasionally move the speech to a GUI-free area of the screen.

With a pretty big GUI right in the center of the screen, moving a long/wide message doesn't make much sense, but a short text like "The crowbar?" is moved outside the GUI, probably due to the fact that GUIs are usually meant to be on top of everything else.

So, not a glitch. Since there doesn't seem to be an option to override this, it looks like you're stuck using SayAt (or adding lots of whitespace to short messages).

Try:

Code: ags

  cCrispin.Say("                                       The crowbar?");[/ code]

[fuzzie]

Don't know if this helps, but: this is handled by the adjust_x_for_guis/adjust_y_for_guis functions in the source, which try pushing text to the right or below a GUI. They will ignore a GUI only if it is completely transparent (transparent background colour and no background graphic), if the interface is completely disabled and "GUIs Turn Off When Disabled" is set, or if the GUI is more than 50 pixels high (for Y adjustment) or more than 280 pixels wide (for X adjustment).

[Snarky]

So it would probably work to extend the GUI with a transparent section on the side to make the width more than 280...

If you don't have too many lines, I think using SayAt (with the coordinates calculated from the character position and size, preferably through an extender function) would be cleaner, though; assuming SayAt lines don't get pushed off the GUI.