Display() / DisplayAt() / Say() / SayAt() issues - might possibly be bug

[fernewelten]

Hello.

I'm trying to build a high-resolution (1280x720) adventure with AGS 3.4; for the exact setup, cf. the bottom of this post. This is my first attempt to work with AGS. I've read the FAQ and perused the F1 documentation several times.

Currently, I'm trying to make a custom text window work. I'm testing the following code with different displaying functions:

Code: ags

function room_FirstLoad()
{
    DisplayAt(550, 400, 100, "That's me talking!");
}

I notice:

* When I use player.Say() or player.SayAt() or Display(), the system uses some font that I haven't found in the configuration screens anywhere. Also, the system ignores the custom text window GUI 7 that I set up in General Settings. I've tried every setting in Dialog/Speech style without changing anything in this regard.

player.Say():

Display(): (same picture as above)
player.SayAt():


* When I use DisplayAt(), the system does use my custom text window and does use a font in the resource tree, I think font 1.


The documentation of DisplayAt() claims: "Identical to the "Display" function, only this allows you...".

I've probably overlooked some customization somewhere. So how do I proceed from here?
There's also a slight chance that I might have tripped over some obscure bug.
I've tried several Google queries without finding any article that treats similar problems.

Peter

PS. Please disregard the graphics. I use scribbles for everything where I am still unsure of the exact details, by principle.

Here is my setup:

My AGS version, as given in the Help/About AGS... screen:

AGS Editor .NET (Build 3.4.0.16)
V3.4.0, March 2017
Copyright © 2006-2011 Chris Jones and 2011-2017 others.
Scintilla (c) 1998-2003 Neil Hodgson, all rights reserved
DockPanel Suite (c) 2007 Weifen Luo
See the DOCS folder for copyrights of used libraries.
System: Windows 7
Editor plugins loaded:
x ags.plugin.notes.dll

My "General Settings" screen:

Put sound and sprite files in source control   False
Resolution   1280 x 720
Backwards Compatibility   
Enable mouse wheel support   True
Enforce new-style audio scripting   True
Enforce new-style strings   True
Enforce object-based scripting   True
Left-to-right operator precedence   True
Script API version   3.4.0
Script compatibility level   3.4.0
Use low-resolution co-ordinates in script   False
Use old-style custom dialog options API   False
Character movement   
Automatically move the player in Walk mode   True
Automatically walk to hotspots in Look mode   True
Characters turn before walking   True
Characters turn to face direction   True
Compiler   
Build target platforms   Windows, Linux
Compress the sprite file   False
Enable Debug Mode   True
Split resource files into X MB-sized chunks   512
Dialog   
Allow speech to be skipped by which events   Mouse, keyboard or timer
Dialog bullet point image   0
Gap between dialog options (in pixels)   0
Number dialog options   Draw numbers and use keyboard shortcuts
Print dialog options upwards   False
Run game loops while dialog options are displayed   False
Sierra-style portrait location   Left
Speech style   Lucasarts
Use game-wide speech animation delay   False
Use GUI for dialog options   0
Inventory   
Display multiple icons for multiple items   False
Inventory item cursor hotspot marker   None
Override built-in inventory window click handling   False
Use selected inventory graphic for cursor   True
Saved Games   
Enhanced save games   False
Save game file extension   
Save games folder name   Test Freedom
Save screenshots in save games   True
Sound   
Play sound when the player gets points   (None)
Text output   
Always display text as speech   True
Anti-alias TTF fonts   True
Custom text-window GUI   7
Custom thought bubble GUI   7
Fonts designed for 640x480   False
Write game text Right-to-Left   False
Visual   
Default transition when changing rooms   FadeOutAndln
GUI alpha rendering style   Additive Opacity
Pixel-perfect click detection   True
Sprite alpha rendering style   Classic
When player interface is disabled, GUIs should   Grey out all their controls
Windows Vista Game Explorer   
Developer website   http://peter.bouillon.hat-gar-keine-homepage.de
Enable Game Explorer integration   False
Game description   
Genre   Adventure
Release date   01.01.2021
Version   0.0.1.2
Windows Experience Index   1

[Slasher]

Check your speech font properties... Perhaps you have selected UseOutlneFont..?

[fernewelten]

Perhaps you have selected UseOutlneFont..?

OutlineFont is 0.

I've found out something very strange in the meantime: As noted, player.Say() does not make my custom text gui #7 appear. But the system doesn't ignore that gui completely either: If I set "padding" to a negative value in that gui #7, the spoken text is clipped at all the sides. Just as if there was an "invisible" gui around the spoken text that normally just fits the spoken text and that is shrunk with negative "padding" values. But why would an "invisible" gui obey padding values for another gui that isn't shown? Look:

Code: ags

function room_FirstLoad()
{
    player.Say("Help! My precious[words are being clipped!");
}

"padding" set to 0 in GUI #7 (note that there is some clipping effect even now)


"padding" set to -10


So I've come to believe that this might be an AGS glitch after all. For the meantime, I've decided to proceed without custom text guis.

Another thing that is more or less annoying but tolerable in itself: I'm writing a large screen adventure (1280x720 pixels). Compared to that size, the gui editor window is really tiny. The default for the edge and corner graphics is sprite #1, which is my current place for my verb coin. This coin is huge by comparison (120x120 px), although the size is quite reasonable for an adventure of the screen size (as far as verb coins go). The result is a cluttered, "stamp-sized" editing field. Look:


If this becomes a bug report instead of a beginner's question, as I thought at first, then the thread probably needs to move into another forum section. How? I don't want to crosspost.

[Kumpel]

A negative Padding does exactly that. It clips the gui What happens if you use positive values (as in default) beetween 3 and 5)? Why are you using negative values at all?

And about the editor window. I think you are not really understanding how the gui text window editor works. You can use it to define the cornes and edges of a display window. that means the several parts should only be as big as the frame of you text window is. my custom frame tiles are only 2x2 pixels. The Verbcoin has to be created in a normal gui where you can change the size of the gui editor window.

[fernewelten]

Why are you using negative values at all?

Thats why: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52225.msg636514425#msg636514425
Of course, this is pointless when the speech bubble isn't shown at all when the player Say()s something. And that's what is happening to me: The speech bubble is neither shown for a positive padding nor for zero padding, nor for a negative padding.

that means the several parts should only be as big as the frame of you text window is. my custom frame tiles are only 2x2 pixels.

Sorry, I think I mis-explained and didn't give enough details. Let's explain this better I hope: As far as I can see, I must load all the graphics in the sprite editor. I've worked on the verb coin interface first. When I uploaded the verb coin image at that time, the sprite editor assigned sprite number 1 to it. Since this time, sprite number 1 means the verb coin sprite. Wherever I use sprite number 1, the system uses the sprite of the verb coin.

Recently, I tried to make custom text guis work. When I created a new, fresh custom text gui, the editor showed me a default bubble with four corner sprites and four edge sprites. It used sprite number 1 for all these sprites (Properties: Image = 1). That was the default the system used. In my case, all these pictures turned out to be pictures of my verbcoin, since sprite number 1 is the verb coin sprite. Thus, the system displayed the editor I've shown above:

I fixed that by setting "Image" to the number of a smaller sprite.

Still, since I have a large (1280 px wide) window, the corners of the speech bubble will turn out to be quite large, too. For instance, I plan a bottom left corner that "points" to the speaker (highlighted in green in the picture below):


I am using 15-point speech fonts and so typical spoken text will be more than 600 pixels wide. A small bottom-right corner with a small "pointer" would look very ugly. I'd prefer the bottom left corner to be about 1/3 of the speech width.

The documentation claims that the custom text gui window is "about a quarter" of the game screen size. In my case, however, the screen is considerably smaller than that.

[Riaise]

You've got "Always display text as speech" as true, which is why Display is showing as speech rather than as a text box. I'm not certain, but could the custom text GUI not be showing because you're using Lucasarts-style speech? If you change the speech style in game options to "Sierra with background", does it work then?

[fernewelten]

If you change the speech style in game options to "Sierra with background", does it work then?

Thanks for coming to help.

"Always show text as speech" -> false, "Speech style" -> "SierraWithBackground"

Display() does show the custom text window, DisplayAt() does show the custom text window.
player.Say() does not show the custom text window, player.SayAt() does not show the custom text window.

"Always show text as speech" -> true, "Speech style" -> "SierraWithBackground"
Display() does not show the custom text window, DisplayAt() does show the custom text window.
player.Say() does not show the custom text window, player.SayAt() does not show the custom text window.

"Always show text as speech" -> false, "Speech style" -> "Lucasarts"
Display() does show the custom text window, DisplayAt() does show the custom text window.
player.Say() does not show the custom text window, player.SayAt() does not show the custom text window.
Same as when "Speech style" is set to "SierraWithBackground".

"Always show text as speech" -> true, "Speech style" -> "Lucasarts"
Display() does not show the custom text window, DisplayAt() does show the custom text window.
player.Say() does not show the custom text window, player.SayAt() does not show the custom text window.
Same as when "Speech style" is set to "SierraWithBackground".

So AGS behaves the same no matter what "Speech style" is set to.

Problem 1: The custom text window never appears with player.Say(). But it is a speech bubble - it is intended for speeches.

Problem 2: When "Always show text as speech" -> true, then DisplayAt() behaves differently from Display(), contrary to the F1 documentation.

[Snarky]

If you read the manual more carefully, you'll see that it says:

Customized Text Windows
If you want to add a personal touch to the standard white text-boxes which display all the messages during the game, you can create a border using the GUI Editor.

It says nothing about it affecting character speech. In other words, it works as it is supposed to.

You can set a GUI to be used as the speech background for "Sierra-style speech with background" using the game.speech_text_gui variable.

If you want a custom GUI for LucasArts-style speech, or want to format it in a way that isn't supported with the standard modes, you'll have to write your own little function to display speech (or use an existing module, like Phylactère), and use that instead of player.Say().

[Gurok]

SierraWithBackground only works if the character speaking has a SpeechView. Otherwise, it looks and behaves like Lucasarts-style speech.

Do you have a SpeechView set for the character?

If you don't want a portrait, you might try using a view that points to a blank sprite. (I haven't tested this.)

[fernewelten]

To clarify, I'm after an effect like this, but in high-resolution:


Preferably, in a way that lets me use the Dialog features of AGS.

Note that the "pointer" part of the speech bubble takes up about 40 % of the width of this bubble; it is constant, but the size of the bubble is dynamic (depends on the size of the spoken text).

Translated to my current screen size and font size, the speech bubble for "Where is that noise [coming from?" would need to be around 300 pixels wide, which would mean that the bottom-left "corner" would have a constant width of about 100 pixels. Using the approach in this thread, all the corners would be about 100 pixels wide, and the top and bottom edges would be 1 pixel wide. Padding would probably turn out to be around -35 pixels (negative).

The screenshot is from Resolution, which is an AGS game, albeit low-res and closed-source.


By the way, I've googled the current place of the Phylactère module to be  publishing page link to the download. The page is French, but the only thing it says is "use player.Phylactere() instead of player.Say()", so you don't miss much if you can't speak that language.

I'm currently looking into this extension; thanks for the tip.

[Snarky]

I'm about as certain as I can be (without having seen the code) that Vince wrote his own custom speech system for Resonance. Among other things, doesn't the little speech bubble hook always point in the direction of the character? The built-in system doesn't give you that degree of control.

To use a custom speech function in AGS dialogs, you can just do:

Code: ags

// Instead of...
player: Hello!
// ... do this:
  player.SaySpecial("Hello!");

Indenting code allows you to use normal AGS functions in dialog scripts.

[fernewelten]

@Snarky

Yes, I agree, this is probably the way to go. The more so since I can make up a nice one-letter or two-letter method name so that the typing overhead in the dialog editor is nearly non-existent.

I'm aware that it would need several custom text guis to replicate all the cool dialog effects in Resonance - they don't only have "speech bubble tails" that always point to the proper speaker, but also special speech bubbles for telephones etc. etc. I don't plan my adventure to be quite as lavish in this regard.

I'll let you know how it works out, but it'll need some more time since I had to give other aspects priority. I'm currently revamping the verb coin interface so that the pointer always shows a sensible and "allowed" default action wherever it goes, which is also the left-shortclick action; a left-longclick will open a verbcoin that always only shows those actions that are "allowed" at the current screen position. The interface is already mostly functional.

[Gurok]

@fernewelten: Did you try setting a SpeechView for the player character as I suggested above? Regardless of whether you choose to go with a module-based solution, it would be nice to know if that fixed your original problem.

[Crimson Wizard]

By the way, I've googled the current place of the Phylactère module to be  publishing page link to the download. The page is French, but the only thing it says is "use player.Phylactere() instead of player.Say()", so you don't miss much if you can't speak that language.

Phylactere module may indeed be a way to go. That actually surprised me why it was never posted on english AGS forums, because a lot of people seem to be using it.

I may also mention a demo game to my "typed text" module, where I reused the code from Phylactere to create my own custom speech (basically, took their bubble drawing and display text in my own way): https://bitbucket.org/ivan-mogilko/ags-script-demos/downloads/TypedTextDemo_0.7.0.zip
It may be used as an example of further customizing speech.

[Slasher]

Your TypeText is brilliant Crimson.

I believe the Phylactere version (french site) has now been updated to accept Speech&[n] though I have not tried it.

[fernewelten]

Did you try setting a SpeechView for the player character as I suggested above?

@Gurok:

Sorry. I was interrupted by a meeting right now and could not finish my posting activities. I'm back now. Yes, I've tried creating a view with one transparent frame and setting this as the "speech" view. This looks fine, as far as I can see, but with player.Say(), the gui gets a fixed position at the top of the screen in Sierra style. But I could correct this in turn through using player.SayAt() instead of player.Say(). I could wrap a small function around player.SayAt() that calculates a good position based on the player position.

I'll certainly experiment with that option, too.

This option will be especially interesting if I decide to use proper speech views for my characters. I have several ideas that revolve on proper speech views. Since I have a large, 16:9 screen at my disposal ... On the other hand, if the game turns out to have lots of characters, I won't have the resources to provide proper speech views for all of them.

Thanks a lot for the hint!