[BUG] Chatlog Becomes Blank/Empty After Large Amounts of Colored Output

[draukadirtch]

Ashita Version (Type /ashita in-game to get this.) 4.1.0.2

FFXI Version (Type /version in-game to get this.) Horizon

Windows Version (ie. Start > About Your PC) Windows 10 Pro

Describe The Bug Have been trying to pin down what was causing my chat to go blank after playing for a bit. Seemed a bit random at first but saw a post by Thorny on discord about how the chat works. (If it fails to read chat history once, it no longer reads chat from drive) Made me try to think about what could cause some kind of corruption of that process. SimpleLog has its own issues and no longer running that stopped it from happening randomly. I think the main reason for it causing blank chat has something to do with how Ashita is adding chat to the log though. I can replicate blanking out chat by reloading a LAC lua that adds command aliases to ashita on load and unload. (lua based on these profiles and files https://github.com/GetAwayCoxn/Luashitacast-Profiles) When loaded it creates 30+ aliases through a loop for every command added to a table. When reloading, it removes those 30+ aliases and then adds them back, adding 60+ lines of chat very quickly. This seems to be the culprit. I don't have an issue with the chat window when logging in, but if I have to reload the lua because of gear changes, it seems to have a fairly high risk of blanking chat.

Steps To Reproduce Load one of the Luas from https://github.com/GetAwayCoxn/Luashitacast-Profiles with the common files. Use '/lac load' to reload the profile and then expand the chat window. It does not seem to always blank on one reload, so might need to do a second time. Pretty rare that a second time doesn't clear the chat. When coroutine.sleep(.1) is added in the SetAlias function though, I can reload multiple times with the aliases being added just a bit slower and it does not seem to corrupt the chat.

Additional Information I do understand I am running on Ashita for Horizon and this might not be strictly an Ashita issue, but thought I would at least put in a report since I seem to have found the cause. Only other person in Discord I have seem so far talking about this issue noted two different private servers as well, so again, not 100% sure if this can be replicated on retail.

[zombie343]

I've experienced this problem in v3 as well when creating many aliases too. I believe v4 has a feature to make an addon (like aliases silent, i.e. no output) because the rate at which the log is being updated can also trigger the blanking we're both experiencing.

[atom0s]

This is an issue with the game client itself, and not a bug with Ashita directly.

The FFXI client has its own custom formatter with the chat box that allows several special case alterations, replacements, and such to happen based on the text being drawn. This includes things such as:

• Inline coloring.
• Inline symbols. (ie. the auto-translate brackets, elemental icons for Synergy, etc.)
• Special line breaks, tabs, and other general formatting.
• Special line holds. (ie. when the game waits for you to press enter to continue.)

In most cases, SE uses these special tags sparingly, especially the coloring. Generally, a chat line will only ever have 1 color replacement, usually when an item is being discussed in the chatline and that is usually only ever a single item. The overall line color is set using the mode id for the line entry itself with the inline coloring being reserved only for additional context.

When using tools such as Ashita or Windower, the usage of those color tags is greatly increased to allow addons, plugin, and even the base tool (Ashita/Windower) to have unique and rich color output for various things. The current assumption as to what is happening when this bug occurs is that either:

• The formatter/parser that handles the replacements is getting a bad pointer to the end of the string.
• The formatter/parser that handles the replacements is getting (or calculating) a bad string length/size.

When this happens, it causes the parser to not properly find an 'end tag' for one of the special cases mentioned above and causes it to effectively create an invalid entry into the chat log that it fails to recover from.

Another way this bug can happen is while dualboxing when using the stock client or Windower. The game writes the chatlog to a set of temporary log files and makes use of those files while redisplaying the log when its maximized and such. There is a chance, while dualboxing, that you will land up corrupting one of the files causing the game to fail to properly re-read the files back when opening the full log, causing it to blank out as well. (Ashita does not have this issue because we have an internal hook that separates the chatlog temp files per-character instead of it being shared for all instances of the game that are running.)

I haven't taken the time to really dig into the causes of when its triggered from too much inline coloring and such, as getting this bug to actually happen is pretty hard to replicate. If you can find an easy way to cause it to happen quickly though, it can help aid in debugging it more in depth and potentially figuring out a way we can patch the client to fix it ourselves.

[atom0s]

I am going to close this issue as this is not a bug with Ashita but the game client itself. Heavy usage of the injected color tags can lead to this issue, but it is not due to anything Ashita itself is doing.

As a point of recommendation; we encourage people that do wish to use/add color to their output to rely only on the initial color table that starts with byte 0x1E. The secondary color table (0x1F) is known to cause this issue much more frequently. While using 0x1E colors does help reduce the issue from happening, it can still happen.