I hope we will be able to start using ImGui so we can focus on our features rather than how we draw console outputs after we separate the loader and console domain stuff into separate dlls, but using C++/CLI with C# files is preventing us from doing this.

Hopefully, I managed to find a way to find line split points for long strings so we can properly draw long outputs as multiple lines. We should cache results of END_TEXT_COMMAND_GET_NUMBER_OF_LINES_FOR_STRING though, because it executes a lot of assembly instructions and is considerably expensive. In my PC, that native took 150 us for a string with about 700 ASCII characters, while Encoding.GetBytes took only 1 to 1.5 us on Encoding.UTF8 for the same string. You might ask when to invaridate cache of line count results, and I would say when the screen resolution gets changed.
We should do this before releasing v3.7.0, since I'd like to properly show that deprecated API warning properly.

A method for line count...

private uint GetLineCount(string str, float x, float y)
{
    Function.Call(Hash.BEGIN_TEXT_COMMAND_GET_NUMBER_OF_LINES_FOR_STRING, "CELL_EMAIL_BCON");
    PushLongString(str);
    return Function.Call<uint>(Hash.END_TEXT_COMMAND_GET_NUMBER_OF_LINES_FOR_STRING, x, y);
}

A method for finding the split point/index for a specific line...

bool FindLineSplitPoint(string str, uint targetLineNum, float x, float y, out int foundPos)
{
    if (targetLineNum == 0 || string.IsNullOrEmpty(str))
    {
        foundPos = -1;
        return false;
    }

    int strLength = str.Length;
    int low = -1;
    int high = strLength;

    while ((high - low) > 1)
    {
        int mid = low + (high - low) / 2;

        if (GetLineCount(str.Substring(0, (int)mid), x, y) >= targetLineNum + 1)
        {
            high = mid;
        }
        else
        {
            low = mid;
        }            
    }

    foundPos = high;
    return (foundPos >= 0 && foundPos < strLength);
}