PDA

View Full Version : Bad Command Byte



Earliboy
21st January 2013, 21:53
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?

Tally
22nd January 2013, 06:43
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.

kung foo man
22nd January 2013, 08:31
Collected some informations:

Final Error on Crash:



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):



/*
===================
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:



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:


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).

Mitch
22nd January 2013, 09:15
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?

STAUFFi
22nd January 2013, 13:36
maybe he mean Botzombies.
i have some time Bad Command Byte to.
-> Selbies BotZombies

Earliboy
22nd January 2013, 14:51
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 -.-

Tally
22nd January 2013, 16:07
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.

kung foo man
3rd February 2013, 10:06
Can somebody upload an example-bug-map?

punisher2202
3rd January 2016, 19:22
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?

maxdamage99
3rd January 2016, 19:44
punisher your mod > 100mb?

punisher2202
4th January 2016, 18:23
punisher your mod > 100mb?

i don't have any mod

IzNoGoD
4th January 2016, 21:52
You're probably precaching a whole lot. Maybe lay off the precachestring a bit.

punisher2202
7th January 2016, 20:30
You're probably precaching a whole lot. Maybe lay off the precachestring a bit.

ok thanks.