Looking into increasing limit on length of chat messages

[Arklon]

Pretty much everyone is annoyed by how little text you can fit in a chat message. I looked at the limiting factors on chat messages a bit earlier today. Here's what I found:

- The function that handles taking input for the chat message, and then prepares the chat command packet, is called StatusBar_OnUIEvent in the OllyDbg comment file. At 4118C2, it checks if the current input is less than 36 characters before it tries adding new characters. At 4119D1 and 4119D7, if the string length is greater than 63 (obviously a much bigger number than 36), it clips the string to that length.
- The bottom text bar (where chat messages/etc. get displayed) has a character limit of 78 including the null terminator. The top bar (where chat text is inputted) has a much bigger limit, I didn't test how much exactly yet.
- Each message log entry has a character limit of 51 including null terminator.
- For chat messages, they are prefixed with "[Player name]: ", and since player names can be up to 12 characters, that's up to 14 characters for that prefix. Message log entries are prefixed with "[Mark]: ", and if we assume mark doesn't go beyond 4 digits in a typical game, that's up to 6 characters for that prefix. So for a chat message in the message log, that's up to 20 characters for the prefix, which leaves 30 characters for the content of the chat message before it gets truncated. Also, if a single word is longer than the width of the message log box, it won't get split up and wrapped around to the next line at all, you won't be able to read anything that goes past the right side of the box.
- The command packet itself has a limit of 255 characters including the terminator because the dataLength variable in the packet header is a single byte.

If we increase the length of message log messages, then we can bump up chat message length to 57. If we increase the length of the buffer for text in the bottom text bar, we can go even further with it. Does anyone have any familiarity with the message log code and how we could change that? (That means you, Hooman. )

[Hooman]

Interesting. I never thought about doing this before. You're right though, in that the chat length limit is kind of low.

Will need to check if the buffers are statically or dynamically allocated, and if there are particular reasons for the limits. You mentioned one reason already about the display area. Perhaps some of the other limits come from the limited display area when playing at the lowest supported resolution.

I like how you included code addresses, and specific numbers for the length limit.

I'm not entirely certain what to do about your request for help though. It's been a while since I last looked at that code, and I somehow suspect you'd be just as capable as me about making the necessary changes at this point. Is there something specific that you're caught on?

[Arklon]

I'm not entirely certain what to do about your request for help though. It's been a while since I last looked at that code, and I somehow suspect you'd be just as capable as me about making the necessary changes at this point. Is there something specific that you're caught on?

Eh, it was worth asking. The message log-related code didn't look to be as thoroughly documented as other parts of the code, and I'm unsure exactly what all needs to be changed to increase the length of each entry. Guess I'll have to do some digging.

[Hooman]

I took a quick peek at the addresses you mentioned. I noticed the function that returns empty CommandPackets uses an array multiplier of 113 in the addressing, so there's a static buffer size limit of 113 bytes per CommandPacket. The string starts at offset 16 (0x10) in the packet, and must be 0-terminated, so that's 96 bytes left for text. I don't see any fields accessed after the string, so that full space should be available for text. I believe the limit of 63 you mentioned above can simply be modified to 96 without fear of memory corruption issues. That's assuming any other copies from that buffer are appropriately size checked and don't overflow a destination buffer.

That leaves the text entry buffer, and the log entry buffer. Can you find where those buffers are accessed or allocated?

[Hooman]

I just took a look at the MessageLog code. The MessageLog object is statically allocated of a fixed size, and contained in the object is an array of fixed size buffers for each log entry. There are 76 bytes per log entry, of which 12 bytes are used for header fields (3 x int), with 64 bytes remaining for the text, including the 0-terminator. The one access point I examined is properly bounds checked, so it won't crash if a larger string is fed to this code. It will truncate in that case. The limit includes the string prefix with the time stamp, and a hidden color code "<N>", so actual string length will be less.

You of course know what all that fixed size static buffer business implies. Without your COFFer to re-link the executable, the object would have to be moved in memory to increase it's size, all references to it patched up, and all array indexing into that internal array found and modified to account for a larger entry size. Not an easy task to increase the length of log messages.

[leeor_net]

Would it be possible to load additional code to send/receive messages using a different UI input and message protocol instead of using what's built into OP2? I wouldn't know how to display it after that but just a thought. (Keep in mind I genuinely have no idea what OP2's code looks like save for the bit of skimming I did on the DLL exports in the SDK).

[Arklon]

You of course know what all that fixed size static buffer business implies. Without your COFFer to re-link the executable, the object would have to be moved in memory to increase it's size, all references to it patched up, and all array indexing into that internal array found and modified to account for a larger entry size. Not an easy task to increase the length of log messages.

The first one is trivial if you just hook the initialize function to allocate it on the heap, second one should also be doable with the PatchGlobalReferences function (which patches all pointers to a specified global by scanning the base relocation table) in my Patcher library even though there's a whole bunch of pointers to different things involved here that'd need to be patched, but the third one might be a pain.

[Hooman]

The network limitations seem to be the least of the worries. It's the least restrictive, and the easiest to patch to allow longer strings. Putting long messages into the message log seems to be much more difficult.

Interesting comment about hooking the initialization to allocate on the heap. I guess that was how you used it before? For some reason, I was thinking a larger section of static memory was set aside (perhaps in a DLL), and the patcher moved references over to that. I suppose the heap works too, where you just act like the memory is statically allocated, while it actually lies within the heap.

And here for a moment I was thinking, wait a minute, changing "mov ecx, staticAddress" into "mov ecx, [heapAddress]" would expand the instruction from 5 bytes to 6 bytes. Guess I was overthinking it, as there's no real distinction between static memory and heap memory at the assembly level. Once patched, it simply becomes "mov ecx, heapMemory". No need to convert the code to use proper indirect addressing to access the heap.

The array indexing is a pain though. There's no way to scan for that. You'd have to manually find and analyse all MessageLog functions to mark all references to the array stride calculation. Not quick to do, and hard to be sure about. There's always the chance you missed a function that got compiled to some far away section of the code.


Guess we'll just have to rewrite the game. That will be the quickest way to get longer chat messages. 

[leeor_net]

Guess we'll just have to rewrite the game. That will be the quickest way to get longer chat messages. 

Ya know, I keep saying this and nobody seems to take me seriously.

[Arklon]

The array indexing is a pain though. There's no way to scan for that. You'd have to manually find and analyse all MessageLog functions to mark all references to the array stride calculation. Not quick to do, and hard to be sure about. There's always the chance you missed a function that got compiled to some far away section of the code.

Somehow I doubt there'd be any array indexing to worry about outside of the MessageLog's methods and the communications report pane.

[Hooman]

Clarification: I meant a MessageLog function that was compiled and inserted into the executable in a place that wasn't close to the other MessageLog functions. Functions for a single class don't always end up being placed serially in the compiled code. They usually are though, so that helps a little with the analysis.

[Arklon]

I could always set read/write breakpoints where the message log array is to see what all functions touch it. That's how I figured out the acid trip bug.

[Hooman]

You could yes, and that would help analysis. My comment was more that there's always the possibility of missing some obscure code path. You can't be certain you've found all access to the array. You can however still be correct with very high probability, so perhaps it's not a real issue.

Did you figure out the acid trip bug? I thought there was still some air of unknown about it.

[Arklon]

I haven't looked at the acid trip bug in a long time. We figured out it's a memory leak with waypoint objects caused by the ScGroup code, but I never tracked down where or why it's not freeing the objects. We could band-aid it by just allocating more memory for the waypoints, which would be trivial since they're already on the heap.