Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Bad Command Byte

  1. #1
    Private First Class Earliboy's Avatar
    Join Date
    Nov 2012
    Location
    Germany
    Posts
    130
    Thanks
    5
    Thanked 88 Times in 61 Posts

    Exclamation Bad Command Byte

    Hello,
    i often heard and had the problem of the bug with Bad Command Byte.
    I think most of you know this bug, and hate it!
    I know, its just needed to delete some useless loops in the mod, but i would like to find or write an fix for this bug.
    Does anyone got an idea or got some logs (Coredump or anything else) to see, why its happening?
    No ... No ... this is not possible .......

  2. #2
    Brigadier General
    Join Date
    Oct 2012
    Posts
    994
    Thanks
    20
    Thanked 588 Times in 388 Posts
    Quote Originally Posted by Earliboy View Post
    Hello,
    i often heard and had the problem of the bug with Bad Command Byte.
    I think most of you know this bug, and hate it!
    I know, its just needed to delete some useless loops in the mod, but i would like to find or write an fix for this bug.
    Does anyone got an idea or got some logs (Coredump or anything else) to see, why its happening?
    It's not a bug. It's a game limit. COD2 ver 1.0 has only 16k of gamestate memory. If you go over that limit with assets from a mod, you will incur this error, which basically tells you the game has run out of gamestate memory.

    The way to "fix" it is to upgrade to COD2 ver 1.3, where the gamestate memory has been increased to 128k.

  3. The Following User Says Thank You to Tally For This Useful Post:

    kung foo man (22nd January 2013)

  4. #3
    Assadministrator kung foo man's Avatar
    Join Date
    Jun 2012
    Location
    trailerpark
    Posts
    2,010
    Thanks
    2,102
    Thanked 1,084 Times in 753 Posts
    Collected some informations:

    Final Error on Crash:

    Code:
    10:Le pape Love War EXE_TIMEDOUT
    Client 990 connecting with 100 challenge ping from 94.69.14.205:26662
    94.69.14.205:26662:reconnect
    Going from CS_FREE to CS_CONNECTED for  (num 13 guid 1217107)
    SV_ReadPackets: fixing up a translated port
    WARNING: bad command byte 7 for client 13
    WARNING: bad command byte 6 for client 13
    SV_ReadPackets: fixing up a translated port
    SV_ReadPackets: fixing up a translated port
    WARNING: bad command byte 4 for client 13
    cmdCount < 1
    WARNING: bad command byte 4 for client 13
    ./server.sh: line 37:  2228 Segmentation fault      $cod2 $args



    Example-code from Enemy Territory (look at end):

    Code:
    /*
    ===================
    SV_ExecuteClientMessage
    
    Parse a client packet
    ===================
    */
    void SV_ExecuteClientMessage( client_t *cl, msg_t *msg ) {
        int c;
        int serverId;
    
        MSG_Bitstream( msg );
    
        serverId = MSG_ReadLong( msg );
        cl->messageAcknowledge = MSG_ReadLong( msg );
    
        if ( cl->messageAcknowledge < 0 ) {
            // usually only hackers create messages like this
            // it is more annoying for them to let them hanging
    #ifndef NDEBUG
            SV_DropClient( cl, "DEBUG: illegible client message" );
    #endif
            return;
        }
    
        cl->reliableAcknowledge = MSG_ReadLong( msg );
    
        // NOTE: when the client message is fux0red the acknowledgement numbers
        // can be out of range, this could cause the server to send thousands of server
        // commands which the server thinks are not yet acknowledged in SV_UpdateServerCommandsToClient
        if ( cl->reliableAcknowledge < cl->reliableSequence - MAX_RELIABLE_COMMANDS ) {
            // usually only hackers create messages like this
            // it is more annoying for them to let them hanging
    #ifndef NDEBUG
            SV_DropClient( cl, "DEBUG: illegible client message" );
    #endif
            cl->reliableAcknowledge = cl->reliableSequence;
            return;
        }
        // if this is a usercmd from a previous gamestate,
        // ignore it or retransmit the current gamestate
        //
        // if the client was downloading, let it stay at whatever serverId and
        // gamestate it was at.  This allows it to keep downloading even when
        // the gamestate changes.  After the download is finished, we'll
        // notice and send it a new game state
        //
        // show_bug.cgi?id=536
        // don't drop as long as previous command was a nextdl, after a dl is done, downloadName is set back to ""
        // but we still need to read the next message to move to next download or send gamestate
        // I don't like this hack though, it must have been working fine at some point, suspecting the fix is somewhere else
        if ( serverId != sv.serverId && !*cl->downloadName && !strstr( cl->lastClientCommandString, "nextdl" ) ) {
            if ( serverId >= sv.restartedServerId && serverId < sv.serverId ) { // TTimo - use a comparison here to catch multiple map_restart
                // they just haven't caught the map_restart yet
                Com_DPrintf( "%s : ignoring pre map_restart / outdated client message\n", cl->name );
                return;
            }
            // if we can tell that the client has dropped the last
            // gamestate we sent them, resend it
            if ( cl->messageAcknowledge > cl->gamestateMessageNum ) {
                Com_DPrintf( "%s : dropped gamestate, resending\n", cl->name );
                SV_SendClientGameState( cl );
            }
    
            // read optional clientCommand strings
            do {
                c = MSG_ReadByte( msg );
                if ( c == clc_EOF ) {
                    break;
                }
                if ( c != clc_clientCommand ) {
                    break;
                }
                if ( !SV_ClientCommand( cl, msg, qtrue ) ) {
                    return; // we couldn't execute it because of the flood protection
                }
                if ( cl->state == CS_ZOMBIE ) {
                    return; // disconnect command
                }
            } while ( 1 );
    
            return;
        }
    
        // read optional clientCommand strings
        do {
            c = MSG_ReadByte( msg );
            if ( c == clc_EOF ) {
                break;
            }
            if ( c != clc_clientCommand ) {
                break;
            }
            if ( !SV_ClientCommand( cl, msg, qfalse ) ) {
                return; // we couldn't execute it because of the flood protection
            }
            if ( cl->state == CS_ZOMBIE ) {
                return; // disconnect command
            }
        } while ( 1 );
    
        // read the usercmd_t
        if ( c == clc_move ) {
            SV_UserMove( cl, msg, qtrue );
            c = MSG_ReadByte( msg );
        } else if ( c == clc_moveNoDelta ) {
            SV_UserMove( cl, msg, qfalse );
            c = MSG_ReadByte( msg );
        }
    
        if ( c != clc_EOF ) {
            Com_Printf( "WARNING: bad command byte for client %i\n", cl - svs.clients );
        }
    
        SV_ParseBinaryMessage( cl, msg );
    
    //    if ( msg->readcount != msg->cursize ) {
    //        Com_Printf( "WARNING: Junk at end of packet for client %i\n", cl - svs.clients );
    //    }
    }
    The actual Code:

    Code:
        if ( c != clc_EOF ) {
            Com_Printf( "WARNING: bad command byte for client %i\n", cl - svs.clients );
        }
    
        SV_ParseBinaryMessage( cl, msg );
    So its saying bad-command-byte but its still parsing the message. Maybe a forgotten return; in the if. That should disconnect the user and prevents further harm.

    Also strange in the crash:

    Code:
    SV_ReadPackets: fixing up a translated port
    That looks like a dynamic port-change of the client. Maybe the router of the greece guy is messing ports up? That could confuse the server and ends up in the segmentation fault.



    BTW, there are two Bad-Command-Byte errors: one is just happening on a player (cant connect, needs to retry) and the other one is happening on the server (ends up in a crash).
    timescale 0.01

  5. #4
    Global Mossaderator Mitch's Avatar
    Join Date
    Nov 2012
    Posts
    654
    Thanks
    204
    Thanked 450 Times in 305 Posts
    Quote Originally Posted by Tally View Post
    It's not a bug. It's a game limit. COD2 ver 1.0 has only 16k of gamestate memory. If you go over that limit with assets from a mod, you will incur this error, which basically tells you the game has run out of gamestate memory.

    The way to "fix" it is to upgrade to COD2 ver 1.3, where the gamestate memory has been increased to 128k.
    A map with portals decreases the gamestate memory too right?

  6. #5
    Corporal STAUFFi's Avatar
    Join Date
    Aug 2012
    Location
    Germany
    Posts
    269
    Thanks
    106
    Thanked 128 Times in 83 Posts
    maybe he mean Botzombies.
    i have some time Bad Command Byte to.
    -> Selbies BotZombies

  7. #6
    Private First Class Earliboy's Avatar
    Join Date
    Nov 2012
    Location
    Germany
    Posts
    130
    Thanks
    5
    Thanked 88 Times in 61 Posts
    Quote Originally Posted by STAUFFi View Post
    maybe he mean Botzombies.
    i have some time Bad Command Byte to.
    -> Selbies BotZombies
    I'm not talking about 1 special server, i'm talking about the bug itself. I often saw this bug, at many servers and also at my own.
    I just wanna try to get an fix for this, may more gamestate by editing cod2 itself.
    Its just annoying, you work on a awesome map, or an awesome big mod and then you just get bcb -.-
    No ... No ... this is not possible .......

  8. #7
    Brigadier General
    Join Date
    Oct 2012
    Posts
    994
    Thanks
    20
    Thanked 588 Times in 388 Posts
    Quote Originally Posted by Earliboy View Post
    I'm not talking about 1 special server, i'm talking about the bug itself. I often saw this bug, at many servers and also at my own.
    I just wanna try to get an fix for this, may more gamestate by editing cod2 itself.
    Its just annoying, you work on a awesome map, or an awesome big mod and then you just get bcb -.-
    As I said, it was fixed - in patch 1.3. The 1.2 patch was supposed to also raise the gamestate to 128k, but Infinity Ward screwed it up, and the 1.2 patch is in fact broken. It neither raises the gamestate nor implements Punkbuster properly (the player GUIDs are still at 0 most of the time). But the 1.3 patch fixed both problems.

    We all suffered from the gamestate memory problem with our big mods. I worked on the eXtreme+ mod back in 2006 and we had a nightmare getting our stuff to work with version 1.0. Every time we put in a great new feature, it wouldn't run because the bad command error. You just have to work around it, or upgrade to 1.3.

  9. #8
    Assadministrator kung foo man's Avatar
    Join Date
    Jun 2012
    Location
    trailerpark
    Posts
    2,010
    Thanks
    2,102
    Thanked 1,084 Times in 753 Posts
    Can somebody upload an example-bug-map?
    timescale 0.01

  10. #9
    Private
    Join Date
    Mar 2015
    Posts
    32
    Thanks
    0
    Thanked 1 Time in 1 Post
    Hello all i have the same problem to my server. I have a version 1.3 and i still have the same problem. How to fix this?

  11. #10
    Sergeant maxdamage99's Avatar
    Join Date
    Aug 2014
    Location
    Russia
    Posts
    458
    Thanks
    79
    Thanked 122 Times in 101 Posts
    punisher your mod > 100mb?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •