RichText: get_visible_line_count() returns wrong value

[Noisefever]

Godot version: 3.02

OS/device including version: Win 10

Issue description:

get_visible_line_count and get_line_count with RichText works not as expected (not like Label).
get_visible_line_count does not return the visible lines, it seems more like the line count. And get_line_count seems to return always 1.

I try to make a SpeakBubble which grows automatically to fit the text. I solved that by growing the Label/RichText while get_visible_line_count < get_line_count. That works with the Label, but not with RichText.

[PrinceMerluza]

In my case get_visible_line_count() is always 0 for the RichText label

[thorlucas]

Doesn't work for label for me. I always get a 0 on the label.

[Ridote]

What happens to me is that get_visible_line_count only works if I dont set linebreaks as \n and let the richtextlabel do it and get_visible_line only works if I put break lines with \n.

This makes scroll_to_line to fail if I use the former case :S

Godot 3.1 Beta2. Windows 10.

I guess this was never solved since it is still opened.

Regards

[williamd1k0]

Did you tried waiting one idle frame before calling it?

A few days ago I had a similar issue and fixed it by waiting one idle frame:

# RichTextLabel
func update_size():
	yield(get_tree(), "idle_frame") # wait one frame
	rect_min_size.y = get_content_height()

[Ridote]

Yeah, no change. It returns always 1. Not sure if I am misunderstanding something about righttextlabel.

[Zylann]

I just tried in Godot 3.1.1, it always return 0 even if I have 5 lines in it.

Also, get_content_height() returns complete garbage, like 7209058.

I did these tests in _ready() though, if I do them in _process I obtain 1 line count (still wrong) and a seemingly correct content height, which is because the text was drawn at least once.
Problem is... someone wants to know that before showing the node https://godotengine.org/qa/51562/get_visible_line_count-returning-previous-change-labels

[williamd1k0]

I think it would be useful if there was an intermediate object to generate text, similar to Unity's TextGenerator.

https://docs.unity3d.com/ScriptReference/TextGenerator.html

[Eoin-ONeill-Yokai]

I can look into this at some point -- There's probably an issue with the logic of the original implementation. This would also help extend rich text effects for more features (such as line context awareness!)

[Yesyoor]

please fix this, I can"t automatically scroll at runtime once there are more visible lines then space to fit. Scroll_to_line always throws an out of bounds error due to incorrect lines.size

[theoway]

visible_line_count issue: So after doing some work, I've found out that we're getting wrong values because nonblank_line_count in _process_line() doesn't change correctly. I've fixed that :)
But it still doesn't consider '\n'(newlines). But it won't be a problem, as it can be changed.
The bigger trouble sets in when a line(sentence) spans over more than one line(to fit inside the given space). So, if a part of the multi-line(that's what I'm calling it) is visible, the algorithm can't differentiate and includes the whole multi-line in counting(I don't know if it is by design or a bug), and thus gives the wrong value.
So, I'll be working on this to make it right.

line_count issue: The line_count doesn't count newlines('\n') and individual lines of a multi-line. Well, I've already fixed it.

[theoway]

After talking to other Devs, it turns out get_line_count() works fine. It counts the number of lines and newlines. No, it doesn't count wrapped-lines(this confused me for a while), unlike label.
But still, get_visible_line_count() sometimes gives wrong values, reason can be getting the value before it is drawn. Anyways, I'll dig in the code and see if it really is a bug.
Hope it helps ;)

[Yesyoor]

okay I get your point about the multi-line spanning across multiple lines. It is counted as one.
The very confusing part is that it works for get_visible_line_count(), returning the correct values but not for get_line_count(), which will return always 1, on the exact same label. And using the scroll to line function unfortunately needs line_count to be set correctly (as far as I can see from the error messages).

My workaround to enable auto scroll: Add the text to the Textlabel each time a new character is turning from invisible to visible, thus avoiding the use of visibility at all.
Instead of revealing the text character by character, I d add character by character to the label, which needs auto follow to be enabled, then it will auto scroll as I hoped to realise by using scroll_to( get_visible_linecount) . Thanks for your efforts so far!

[theoway]

@Railwanderer get_visible_line_count() is a little messed up, not even returning the correct value of wrapped lines most of the times. I think it should at least return the correct value of the actual visible lines, not counting the wrapped lines of course.

[theoway]

So, I've made some small changes and now it returns the correct number of visible lines for now. Again, it returns the correct values only after being drawn. I'll make a PR soon.