Why bots get stuck in each other?

[Immortal_BLG]

Actually a question in the thread name...

I tried to change 'server' argument value in PM_Move() to false for bots due to this code (from PM_CheckStuck() function):

// Deal with precision error in network.
if (!pmove->server)
{
	// World or BSP model
	if ( ( hitent == 0 ) || ( pmove->physents[hitent].model != NULL ) )
	{
		int nReps = 0;
		PM_ResetStuckOffsets( pmove->player_index, pmove->server );
		do 
		{
			i = PM_GetRandomStuckOffsets(pmove->player_index, pmove->server, offset);

			VectorAdd(base, offset, test);
			if (pmove->PM_TestPlayerPosition (test, &traceresult ) == -1)
			{
				PM_ResetStuckOffsets( pmove->player_index, pmove->server );
		
				VectorCopy ( test, pmove->origin );
				return 0;
			}
			nReps++;
		} while (nReps < 54);
	}
}

but it did not help :\

Someone can knows in what business and where it is necessary to search for the reason.

Thanks!

P.S. Sorry for bad english

[SamPlay]

Hi,
I had the same problem of bots getting stuck when bumping into each other, and I do not understand why either.
I have coded a "player collision avoidance" system but it cannot make sure bumping will not occur from times to times.
As regards your code question, I actually redirect PM_Move code to my own code, so I think it could help you, but I cannot be more precise as I do not understand what you are trying to do. We can discuss it further if you want.
You could also have a look at JKBotti source code.
regards.

[Immortal_BLG]

Thanks for response! I can try to write simple anti-stuck code, like in PM_CheckStuck function, but I just want to figure out the reason of bot bumping.

Best regards!

[Immortal_BLG]

AND FINALLY I HAVE UNDERSTOOD IN WHAT THE REASON!!!
The guys from Valve forgot to add a check "if (host_client->fakeclient) return" for functions SV_GetTrueMinMax and SV_GetTrueOrigin, which sets predicted variables 'mins'/'maxs' and 'origin' to pmove->moveents, but these variables aren't correct, as they aren't calculated for bots! - this is the source of the problem.

To fix this you need to delete these lines:

SET_CLIENT_KEYVALUE (index + 1, infobuffer, "cl_lw", "1");
SET_CLIENT_KEYVALUE (index + 1, infobuffer, "cl_lc", "1");

as functions SV_GetTrueMinMax and SV_GetTrueOrigin do checks and on these variables.

THESE VARIABLES DO NOT NEED FOR THE BOT!

P.S. also to test it on the fly, you can simply set the value of console variable "sv_unlag" to 0!

[The Storm]

Too bad that so many years even Valve with their CSBot didn't suspected that this is the problem... Nice that you have found it!

By the mean "deleting these lines" are you saying that we should unset them for the bot like that:

SET_CLIENT_KEYVALUE (index + 1, infobuffer, "cl_lw", "0");
SET_CLIENT_KEYVALUE (index + 1, infobuffer, "cl_lc", "0");

or there is something more specific that should be done.

[Immortal_BLG]

Originally Posted by The Storm

Too bad that so many years even Valve with their CSBot didn't suspected that this is the problem

The official CS bot doesn't use these variables!
The official bot uses only "*bot" key value - that's all!!!

Originally Posted by The Storm

By the mean "deleting these lines" are you saying that we should unset them for the bot like that:

At bot creation his client_t structure is nulled:

Q_memset(fakeclient, 0, sizeof (client_t));

(structure client_t contains values of variables cl and lw) - so, values of these variables are always equal 0

ADDED: bonus

edict_t *PF_CreateFakeClient_I (const char *netName)
{
	client_t *fakeclient (NULL);
	int index;

	for (index = 0; index < svs.maxclients; ++index)
	{
		fakeclient = &svs.clients[index];

		if (!fakeclient->active && !fakeclient->spawned && !fakeclient->connected)
			break;
	}

	if (index == svs.maxclients)
		return NULL;	// server is full

	edict_t *const fakeclientEdict = EDICT_NUM (index + 1);

	if (fakeclient->frames != NULL)
		SV_ClearFrames (fakeclient->frames);

	// Wipe the client structure
	Q_memset (fakeclient, 0, 0x5008u);

	// Set up client structure.
	fakeclient->UNKNOWN10_resource.pPrev = &fakeclient->UNKNOWN10_resource;
	fakeclient->UNKNOWN10_resource.pNext = &fakeclient->UNKNOWN10_resource;
	fakeclient->UNKNOWN9_resource.pPrev = &fakeclient->UNKNOWN9_resource;
	fakeclient->UNKNOWN9_resource.pNext = &fakeclient->UNKNOWN9_resource;

	Q_strncpy (fakeclient->name, netName, 32);

	fakeclient->active = true;
	fakeclient->spawned = true;
	fakeclient->UNKNOWN0 = true;
	fakeclient->connected = true;
	fakeclient->fakeclient = true;
	fakeclient->userid = g_userid++;
	fakeclient->name[31] = '\0';
	fakeclient->UNKNOWN1 = 0;
	fakeclient->edict = fakeclientEdict;
	fakeclientEdict->netname = fakeclient->name - pr_strings;
	fakeclientEdict->pContainingEntity = fakeclientEdict;
	fakeclientEdict->flags = FL_CLIENT | FL_FAKECLIENT;
	Info_SetValueForKey (fakeclient->userinfo, "name", netName, 256);
	Info_SetValueForKey (fakeclient->userinfo, "model", "gordon", 256);
	Info_SetValueForKey (fakeclient->userinfo, "topcolor", "1", 256);
	Info_SetValueForKey (fakeclient->userinfo, "bottomcolor", "1", 256);
	fakeclient->sendinfo = true;

	SV_ExtractFromUserinfo (fakeclient);	// parse some info from the info strings

	fakeclient->steamID = ISteamGameServer_CreateUnauthenticatedUserConnection ();
	fakeclient->UNKNOWN7_connectionInformation.UNKNOWN0_typeOrStatus = 1;

	ISteamGameServer_BUpdateUserData (fakeclient->steamID, netName, 0);

	return fakeclientEdict;
}

[The Storm]

Are you sure? I remeber seeing the CSbot to get stuck in each other, regardless that they have nice algorithm to avoid themself... Anyway if you have tested this good there is no point to argue.

[Immortal_BLG]

Sometimes I myself am not sure that I do.

My test was simple: on very small map (de_killzone - simply box) I have created 14 bots, each of them has been subordinated to my actions. And I drove them from corner to corner. Result: at cl_lw = cl_lc = sv_unlag = 1 - bots get stuck into each other at almost every collision; at cl_lw = 0 or cl_lc = 0 or sv_unlag = 0 - bots have never got stuck in each other, except for cases when boats have faced and intensively jump in a direction to each other, and that isn't often!