[Verse] `ToDiagnostic()` breaks when being concatenated or formatted with extra strings

[Sprintermax]

Summary

When using ToDiagnostic() in verse to debug values when working with verse, if we do any operations with the diagnostic values, such as addition with strings, concatenation with other diagnostics and so on, it breaks and does not output anything on the logs.

Please select what you are reporting on:

Verse

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

1. Try to Print a diagnostic value that were formatted, example:

DiagnosticToPrint : diagnostic = "[DEBUG TEST] " + ToDiagnostic(SomeClass) + "\n\t" + "Value: " + ToDiagnostic(SomeClass.MyVariable)

Print(DiagnosticToPrint) # Silently fails, no error, but also no message printed on the logs at all (not even a blank message)

(Note: The strings and values being concatenated on the diagnostic above are just examples, the bug happens with anything, not only with these specific characters/usage)

Expected Result

The resulting diagnostic after the concatenation should be currectly formatted and printed on the logs

Observed Result

Nothing prints when using a concatenated diagnostic, not even a blank message entry on the logs - it just gets “ignored” entirely.

Platform(s)

All

Additional Notes

This issue only happens with concatenated diagnostics, it does not happen with singular ones, for example:

Test1 : diagnostic = ToDiagnostic(MyClass) # works

Test2 : diagnostic = ToDiagnostic(MyClass) + ToDiagnostic(OtherClass) # broken

Test3 : diagnostic = "ClassDebug: " + ToDiagnostic(MyClass) # broken

# Same if we convert the string to diagnostic first:
Test4 : diagnostic = ToDiagnostic("ClassDebug: ") + ToDiagnostic(MyClass) # broken

[Sprintermax]

Additionally, I would want to request the exposal of String field of the diagnostic class. Look at the diagnostic class (from Epic Internal digests):

# An opaque diagnostic message that only shows up in diagnostic logs.
# The format of the diagnostic may change at any time without warning and may not be inspected by Verse code.
diagnostic<native><public> := class<computes><epic_internal>(diagnosable) {
    GetDiagnostic<override>()<reads>: diagnostic = external {}

    String<native><epic_internal>: string # <------------- THIS
}

It already exists but is epic_internal and not exposed for the public.

I would love to have access to it, so I can “pre-process” the resulting string before printing, which can be much more flexible to avoid spam on the logs (Ex. most of the cases only the last part is necessary), and also many other usages in code to tweak the string before actually displaying them, both in logs or even with a custom made in-game debug log.

[Bug-Reporter]

FORT-1078762 has been added to our ‘To Do’ list. Someone’s been assigned this task.

[AndrewScheidecker]

We couldn’t reproduce this with a simple test in a deviceOnBeginin 40.00. Is it possible there’s something else necessary to reproduce this problem?

We don’t plan to expose a way to get the raw string for adiagnostic. The intent is for it to only be useful at development-time, and for it to be able to see through encapsulation and print private or internal details of the value. This isn’t as evident in the current VM, where it just prints UObject names, but for new VM objects, it prints the fields of class instances as well. If we let you extract the raw string, that would let you read things that you shouldn’t have access to.

[Sprintermax]

I will do some tests to check the behavior.

The place where I was using this functionality was inside Scene Graph Entities, I have not tested with Creative Devices.

I will check the behaviors to confirm, and if possible try to isolate and give the actual usage I am trying. Will get back to this with the result of my tests.

Another issue is, that UE Print Logs is limited to ~16k characters, any text longer than that gets trimmed out from the logs (Idk if this is thing from UE/UEFN, or if is from the Print() command itself).
To work around this limitation we need to “break” the outputs on some cases into multiple logs, and later do extra processing to remove the UE log timestamps/join each individual log message. It would be great to not need to do all these extra steps if possible…
(For example, currently I am using regex to replace " \/.+\.(.*)" with " ($1)" to remove the “useless” full path of the uboject, and deleting all "\[[0-9:.-]*\]\[[ 0-9]*\][A-Za-z]*: : \(\) " to remove the log timestamps to join each message)

[Sprintermax]

I did some tests and seems like the behavior somewhat changed from last time that I tested it:
(I’ve attached the log messages and the verse that I’ve used during the tests at the end)

It is currently printing fine on UE logs (I remember having issues on the past but seems to be fixed).

But, the in-game logs is different: It seems to work with smaller messages, but fails in different ways depending on context:

The top-left log overlay works fine with small texts, even diagnostic concatenations, but it seems to ignore completely all messages that are long (I was unable to confirm if this is triggered after a specific message size).
It also stops printing all other print statements on the code after that print. (Note that there is no throttling warning or anything, just stopped entirely).

On the dedicated ingame log history menu, it shows the first big message (the one that gets truncated), but then after it, it also stops entirely from showing any other print statements from the code, they being diagnostics or not.

On both examples above, were supposed to have many more diagnostic messages shown on the game, from the second print scene tree version, and raw string print separators without diagnostics. But these are not displayed at all, and no throtling message appears too.
On the UE logs seems to be fine now (besides the annoying truncation), but the issue persists partially on the game logs where many print statements gets fully ignored after a certain point.

Here are the files I used for doing the tests:
scene_tree_print_test.verse (7.0 KB)
log messages.txt (89.6 KB)