Faulty newline handling for printf in OutputLogger about gigavibe-java-edition

[9382]

I think the main issue here is that printf is complex and submits to out in parts but the OutputLogger is naive (or stupid depending on how you feel about it) and thinks that the message is "a different one" for each of its segments because its logic is very basic and therefore requires a timestamp.

Also, your usage of printf is confusing. Using a different example with proper args (System.out.printf("%s Test.", System.currentTimeMillis()); 3 times) creates 2024/05/11 22:13:21 | 17154620014562024/05/11 22:13:21 | Test.2024/05/11 22:13:21 | 17154620014672024/05/11 22:13:21 | Test.2024/05/11 22:13:21 | 17154620014672024/05/11 22:13:21 | Test. (you can clearly see it timestamping every "split" in the format)

I do have a potential solution in mind to mitigate this and am working on it right now

[WolfNT90]

Also, your usage of printf is confusing.

I realized later that I should've probably used it as I intended to use it, but I think my thought process must've been to simply showcase that any printf is faulty. My bad.

[9382]

The new version (3733765) will now stop adding timestamps onto prints that dont terminate in newlines. Newlines that are part of the same print (and that get received by the logger in the same byte array, aka not printf's %n) will continue to only be timestamped at the start of the entire string (e.g. println("a\na\na")), which isn't great and this should probably be improved, but is no different from the old behaviour and is different to this specific bug

[9382]

I've improved it further with 3a9a7ca (in functionality, the code itself looks a bit bad) to fix the behaviour I describe in my above comment. If there's any further issues (or new ones caused by this change that I haven't spotted), feel free to re-open this issue