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?
Bad Command Byte
Printable View
-
21st January 2013, 20:53EarliboyBad Command Byte
-
22nd January 2013, 05:43TallyIt'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.Quote:
Originally Posted by Earliboy
The way to "fix" it is to upgrade to COD2 ver 1.3, where the gamestate memory has been increased to 128k. -
22nd January 2013, 07:31kung foo man
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):
The actual Code: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 );
// }
}
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.Code:if ( c != clc_EOF ) {
Com_Printf( "WARNING: bad command byte for client %i\n", cl - svs.clients );
}
SV_ParseBinaryMessage( cl, msg );
Also strange in the crash:
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.Code:SV_ReadPackets: fixing up a translated port
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). -
22nd January 2013, 08:15MitchA map with portals decreases the gamestate memory too right?Quote:
Originally Posted by Tally
-
22nd January 2013, 12:36STAUFFi
maybe he mean Botzombies.
i have some time Bad Command Byte to.
-> Selbies BotZombies -
22nd January 2013, 13:51EarliboyI'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.Quote:
Originally Posted by STAUFFi
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 -.- -
22nd January 2013, 15:07TallyAs 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.Quote:
Originally Posted by Earliboy
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. -
3rd February 2013, 09:06kung foo man
Can somebody upload an example-bug-map?
-
3rd January 2016, 18:22punisher2202
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?
-
3rd January 2016, 18:44maxdamage99
punisher your mod > 100mb?
-
4th January 2016, 17:23punisher2202i don't have any modQuote:
Originally Posted by maxdamage99
-
4th January 2016, 20:52IzNoGoD
You're probably precaching a whole lot. Maybe lay off the precachestring a bit.
-
7th January 2016, 19:30punisher2202ok thanks.Quote:
Originally Posted by IzNoGoD