RichTextLabel's bbcode_text property is not fully updated during _ready

[willnationsdev]

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Windows 10
Godot 3.0

Issue description:
If, in the _ready() function, you assign a new value to bbcode_text and then call get_total_character_count() or get_line_count(), the variables are not correct. If you then call the same functions in _process or something after _ready, they have the correct values.

Steps to reproduce:
Run a scene with the RichTextLabel root node and the following script:

func _ready():
    bbcode_text = "[u]u[/u]"
    print(get_line_count())
    print(get_total_character_count())

func _process(delta):
    pass
    # print(get_line_count())
    # print(get_total_character_count())

[willnationsdev]

Somehow, that's really messed up. XD there's gotta be some deeper level bug associated with that then. I mean, if you update the data in a property, then the property's data should be updated the next time you read from it. Even if it means the name of this Issue needs to be changed, I'd prefer to find what the problem is and make it more known / addressable for the average user to understand. Maybe someday a community fix can be made.

[bojidar-bg]

Does calling scroll_to_line before get_line_count make it magically work?

[scmccarthy]

I looked into this a bit, and it's a slightly more general problem than only within the _ready function. For example, the following will also produce an incorrect character count:

func _process(delta):
    bbcode_text = "[u]u[/u]"
    print(get_total_character_count())

(Result: 0)

(Side note: I didn't have any trouble with the line count being correct, contrary to the original report. Not sure if this has been incidentally fixed in the meantime or what.)

The issue is that character count (probably among other variables, I didn't look at all of them) is a cached value, and the validity of the cache is only checked when the program internals think it needs checking. This means it gets checked (and recomputed) when you call scroll_to_line as bojidar-bg astutely asked about, as well as when it needs to draw itself, which presumably happens frequently. The validity does NOT get checked when merely asking for the value itself.

In essence, though a lot of the properties and functions on RichTextLabel are exposed, they don't really seem to be designed for that; they're just designed for internal use. The same applies to #12881 and #12882 - the relevant functions work properly for their internal use but present a puzzling and unpredictable interface to end users.

Given that, it might be appropriate to take a step back from the bug and think about what publicly available functions and properties of RichTextLabel are actually desired and useful to expose.

[KoBeWi]

Still valid in 3.2.4 beta2

[KoBeWi]

Works fine in 4.0