xpsave improvement (modspecific)

[acQu]

Hey,

i found no sorting algorithm in etpub xpsave source, so i just wrote one. Feel free to give feedback:

void G_xpsave_sort()
{
	int	i, j, index1, index2;
	
	gentity_t	*ent;
	g_xpsave_t	*temp[MAX_XPSAVES];

	qboolean found;

	//do this for security
	for(i=0; i < MAX_XPSAVES; i++)
		temp[i] = NULL;

	index1 = 0;	
	index2 = level.numConnectedClients;

	for(i=0; g_xpsaves[i]; i++) {

		found = qfalse;

		for(j=0; j < level.numConnectedClients; j++) {

			ent =  &g_entities[level.sortedClients[j]];
			
			if(!Q_stricmp(g_xpsaves[i]->guid, ent->client->sess.guid))
			{
				found = qtrue;
				break;
			}
		}

		//list 1
		if (found)
			temp[index1++] = g_xpsaves[i];

		//list 2
		else
			temp[index2++] = g_xpsaves[i];

		//list1 written ? just complete list2 then
		if(index1 == level.numConnectedClients)
		{
			i++;
			while(g_xpsaves[i])
			{
				temp[index2] = g_xpsaves[i];
				index2++;
				i++;

				//maximum reached ?
				if(index2 == MAX_XPSAVES)
				{
					G_Printf("xpsave_sort: index2 maximum reached
");
					return;
				}	
			}
			break;
		}			

		//maximum reached ?
		if(index2 == MAX_XPSAVES)
		{
			G_Printf("xpsave_sort: index2 maximum reached
");
			return;
		}			
	}

	//clear for security
	//note: actually you could just overwrite it, no ?
	for(i=0; i < MAX_XPSAVES; i++)
		g_xpsaves[i] = NULL;

	//do this for security
	temp[MAX_XPSAVES - 1] = NULL;

	for(i=0; temp[i]; i++)
		g_xpsaves[i] = temp[i];

	G_Printf("xpsave: sorting successful...
");
}

You need to reference this function at the very beginning of G_xpsave_writeconfig in etpub source code. In my mod it works also well. Tested 2 times local.

Advantage is that it fixes potential server lag, so grab it up and give feedback, point out bugs, improvements etc

[acQu]

I corrected something.

One question. Is it possible that level.numConnectedClients could increase or decrease during all that calculation ?

[acQu]

I corrected something.

One question. Is it possible that level.numConnectedClients could increase or decrease during all that calculation ? The same goes for level.sortedClients or g_entities array. Is it possible that something could change when the server executes this function ? For example when a client disconnects right at the moment when the server is exing G_xpsave_sort, would it wait and then update values ?

[acQu]

I corrected something.

One question. Is it possible that level.numConnectedClients could increase or decrease value during all that calculation ? The same question i ask myself for level.sortedClients or g_entities. Is it possible that values could change when the server executes this function ? For example when a client disconnects right at the moment when the server is exing G_xpsave_sort, would it wait and then update values ?

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also for all who do not know what this does and are too tired to read the code, this does sort your xpsave.cfg in a way that the most active clients are standing at the front of the list, and the more inactive are beeing put further and further behind in the list. the idea behind that is that it costs the server less calculation to search for xpsave data once a client connects. And this calculation could actually get huge when that client is sitting at the end of a 30000 elements big xpsave database.

I need to get answered that question about value changes though. Because actually the engine is build up like an OS right ? There are these trap_calls. I therefore could imagine that it would stop executing my function or generally stop executing dlls, when something is happening important like a client dis or something is happening. Although i would not know how this would work.

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also for all who do not know what this does (ideally) and are too tired to read the code, this does sort your xpsave.cfg in a way that the most active clients are standing at the front of the list, and the more inactive are beeing put further and further behind in the list. the idea behind that is that it costs the server less calculation to search for xpsave data once a client connects. And this calculation could actually get huge when that client is sitting at the end of a 30000 elements big xpsave database.

I need to get answered that question about value changes though.

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also for all who do not know what this does (ideally) and are too tired to read the code. This does sort your xpsave.cfg in a way that the most active clients are standing at the front of the list, and the more inactive are beeing put further and further behind in the list. The idea behind that is that it costs the server less calculation to search for xpsave data once a client connects. And this calculation could actually get huge when that client is sitting at the end of a 30000 elements big xpsave database.

I need to get answered that question about value changes though.

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also for all who do not know what this does (ideally) and are too tired to read the code. This does sort your xpsave.cfg in a way that the currently active clients are beeing put at the front of the list, and whenever the disconnect, they start to drop down the list again.

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also just for explanation. What this does is sorting your xpsave.cfg in a special way. Active clients are beeing put at the front at the list, and start dropping again as soon as they disconnect

[acQu]

I corrected something.

Ooone question though…is it possible that level.numConnectedClients could change value during execution of G_xpsave_sort ?

Also just for explanation. What this does is sorting your xpsave.cfg in a special way. Active clients are beeing put at the front at the list, and as soon as they disconnect, they slowly start dropping again.

[crapshoot]

numConnectedClients is recalculated every time CalculateRanks is called. most likely all of your code will be running in a single frame so it wouldn’t matter, but personally i would loop through level.maxclients instead. actually, i would probably use sqlite or some self coded db (like jaymod did) for xpsave, but that is another discussion.