DXX-Rebirth Forum

Full Version: [v0.58.1] Messages sent via F8 in Coop are truncated
You're currently viewing a stripped down version of our content. View the full version with proper formatting.


Hello everyone.

I last used 0.57.3, and then upgraded to 0.58.1. I was quite surprised to see this bug suddenly appear. I presume it is related to the networking improvements.

Steps to reproduce:

1. Start copy 1 of d2x-rebirth.
1a. Login as pilot TEST1.
1b. Start a new Co-op multiplayer game, descent 1 level 1, port 42424.
2. Start copy 2 of d2x-rebirth.
2a. Login as pilot TEST2.
2b. Join multiplayer manually, host, port 42424, my port 424245
2c. At the welcome screen, accept.
1c. When test2 joins, start the game.
1d. If copy 2's screen doesn't render, hit ESC to bring up the "Abort game" menu, and hit cancel (maybe another bug?)
1e. Send the message "hello".

Expected result: copy 2 sees the following on the HUD:
TEST1: hello

Actual result:
: llo

I have also taken the liberty of running git bisect using the above procedure as a test, and:

c87886c81426119b45bd70ed44e9c43d902437ae is the first bad commit
commit c87886c81426119b45bd70ed44e9c43d902437ae
Author: Kp <kp@valhallalegends.com>
Date:   Sat Mar 30 04:31:09 2013 +0000

    Simplify logic for robot to drop proximity and smart bombs

Which doesn't make much sense, but maybe there's a branch merge in there somewhere.

By the way, thanks for maintaining a great game! As much as I like this game, it's kind of ironic my first post is a bug. Oh well. Smile
This has already been fixed for .58.2. Thanks for the report, though.
It is unification related, rather than strictly network related.  I think you made a mistake with your bisect.  As you say, that commit makes no sense.  However, if we assume that the commit you identified is the last good commit, rather than the first bad commit, then the first bad commit would be da757190cc36b3e9cc1ddbce11fc59ad66b3ffce, which modifies the function responsible for the message shown.  I had seen previous vague reports of chat problems, and with this commit identified, I see why.  Indexing errors I introduced in the refactoring cause it to use the second character of your message as the index of the player who sent it.  In most cases, this causes an array overread and displays random memory as a string, followed by the real message.  That same error also skips over the first two bytes of the message.  In 4f56e3d9cac35c0f5443b5d689d27f84d55a14ec, zico ripped out the special feature I was trying to preserve when I broke this.  If this bug interferes with your games and you do not wish to wait for a new release, please try cherry-picking in 4f56e3d9cac35c0f5443b5d689d27f84d55a14ec.


Great! That cherry-pick worked like a charm.

Here's the specific patch I came up with in case anyone else needs it:

diff --git a/main/multi.c b/main/multi.c
index 0e88951..2460c0d 100644
--- a/main/multi.c
+++ b/main/multi.c
@@ -1551,21 +1551,9 @@ void
multi_do_message(const ubyte *cbuf)
        const char *buf = (const char *)cbuf;
-       const char *tilde;
-       char *colon;
        char mesbuf[100];
-       char dollarbuf[100];
-       int tloc,t;
-       int loc = 0;
-       buf += 2;
-       if ((tilde=strchr (buf+loc,'$')))  // do that stupid name stuff
-       {                                                                       // why'd I put this in?  Probably for the
-               tloc=tilde-(buf+loc);                           // same reason you can name your guidebot
-               snprintf(dollarbuf, sizeof(dollarbuf), "%.*s%s%s", tloc, buf, Players[Player_num].callsign, buf+tloc+1);
-               buf = dollarbuf;
-       }
+       const char *colon;
+       int loc = 2, t;

        if (((colon = strstr(buf+loc, ": ")) == NULL) || (colon-(buf+loc) < 1) || (colon-(buf+loc) > CALLSIGN_LEN))