Appending text (Choices or [n+]) causes previous text to move due to new bubble (text-length-dependent layout)

[hsandt]

The problem

Describe the bug
When using a layout that depends on text length, such as Bubble, appending text (by offering Choices to player while showing question, inserting [n+] in text or setting New lines as new events in Appended mode and writing multi-line text) will cause the text before the appended part to move up due layout recentering on text length change, causing an unstable view that can disturb the player.

2024-05-21.Dialogic.2.unstable.append.text.webm

Even when showing choices instantly (question is short and Settings > Choices > Choice appear Instantly), the issue is visible with a kind of flash glitch due to position update.

2024-05-14.Dialogic.show.choices.instantly.webm

The issue is not visible with stable top-left text box content like the Visual Novel layout, demonstrated at the bottom of the first video.

To Reproduce

Here is demo text you can insert in your script (in external text editor), or reproduce it via nodes:

	This is the text before append.[n+] And this is the text after append. See how previous text is moved.
	This is a long question that will take some time to show before the question choices appear.
	- This is a long choice that takes place
	- And another one
	- And a 3rd one

1. Set first style to use TextBubbleLayer (and Visual Novel Textbox for comparison)
2. Play Timeline above (easiest to is to click Play Timeline button in Dialogic panel for quick preview)
3. Advance while looking at how text moves

Expected behavior
Pre-append text should be stable, as with Visual Novel Textbox

System (please complete the following information):

• OS: Linux Ubuntu 22.04
• Godot Version: v4.2.1.stable.official [b09f793f5]
• Dialogic Version: main commit a9c56aa (2024-05-05)

Solutions

Workaround

I see no easy way to stabilize text but changing the whole layout to use fixed top-left (which would place bubbles very high when not much text, and let text cover character sprite when text is longer than expected)

Possible fixes

For classic text append, we'd need to predict the total text length and reserve that space for the bubble in advance. Another trick used by some adventure game frameworks is to pre-write the appended text in an invisible color (alpha = 0) then change its color later (same technique used as when fading it a character in typewriter display mode).

For choices it's harder, we'd need to predict the choices dimensions (and they are sometimes on one line, sometimes split, or a mix of both - although personally I'd rather have one line = one choice, but that's another issue). Alternatively we could reserve a different box on the side for choices, that would not affect the placement of the question text.

[Jowan-Spooner]

Hey @hsandt,
this sounds like a VERY hard to solve problem, because size calculations always are.
A realtively simple fix for your problem would be to use the [input] effect instead of [n+] I think. It works nearly the same but I think it should size the bubble correctly from the start.
Maybe this helps. I doubt this issue will be solved soon, as it's probably going to be quite annoying 🙈.