Surely something fishy is going on here. The 'partner' message is printed from a routine ZippyControl, and I found the following code in the parse loop for ICS output:
- Code: Select all
if (appData.zippyTalk || appData.zippyPlay) {
/* [DM] Backup address for color zippy lines */
backup = i;
#if ZIPPY
if (loggedOn == TRUE)
if (ZippyControl(buf, &backup) || ZippyConverse(buf, &backup) ||
(appData.zippyPlay && ZippyMatch(buf, &backup)));
#endif
} // [DM] 'else { ' deleted
Normally 'i' is the input pointer in this loop, and passed to routines that try to match input as &i, so it can be updated to point after anything that ha been matched. But here a copy ' backup' is made, which is then updated in stead, so that 'i' is not updated, and any mathed message will not count as matched.
I guess the idea was that after this a 'colorize' section follows, that matches the same messages, in order to color them before displaying in the console. Apparently originally this was not done in zippy-recognized messages (hence the 'else'), but now it is, with 'i' being effectively reset to before the zippy message. This colorization would then be responsible from the removal of the reognized message from the input.
Here, however, we seem to have a message that is not recognized by the colorization code, so that in the end it is not matched by anything at all. In such a case the matching resumes one character later. Because the part of the message that ZippyControl reognizes is at the end, it is recognized again and again, with ever shorter name at the beginning.
I will have to think a little how this could be fixed; This code would only work if there is a 100% guarantee that everything matched by ZippyControl, ZippyConverse or ZippyMatch is also recognized by the colorization code. Perhaps a safer approach would be to test afterthe colorization code if 'i' now has passed 'backup', and if not, reset it to 'backup' (whih was advanced to after the Zippy-recognized messages).
