New Concept: Proximity Spawning (to reduce bandwidth usage)

[KLS]

Mob::SendPosUpdate(int8 iSendToSelf) is where you would want to look. We have it hardcoded to 800 dist but it wouldn't be too hard to load that from the zone table and use a custom value instead. Turning off more advanced ai like spell casting and buffing when people aren't close to npcs and npcs aren't engaged is probably a good idea too.

[Rocker8956]

Originally Posted by KLS

Mob::SendPosUpdate(int8 iSendToSelf) is where you would want to look. We have it hardcoded to 800 dist but it wouldn't be too hard to load that from the zone table and use a custom value instead. Turning off more advanced ai like spell casting and buffing when people aren't close to npcs and npcs aren't engaged is probably a good idea too.

I wrote some code that replaces the 800 found in Mob::SendPosUpdate(int8 iSendToSelf) with a distance pulled from the zone database. But I have aquestion that is probably dumb but Which would be better...

Query the database everytime the Mob::SendPosUpdate(int8 iSendToSelf) is called? I assume this would be a lot.
OR
Set a variable's value when the zone boots up based on a database query. Then get that variables value whenever Mob::SendPosUpdate(int8 iSendToSelf) is called?

Like I said probably dumb questions but I am not sure how often this would be hitting the database.

[MNWatchdog]

Originally Posted by Rocker8956

I wrote some code that replaces the 800 found in Mob::SendPosUpdate(int8 iSendToSelf) with a distance pulled from the zone database. But I have aquestion that is probably dumb but Which would be better...

Query the database everytime the Mob::SendPosUpdate(int8 iSendToSelf) is called? I assume this would be a lot.
OR
Set a variable's value when the zone boots up based on a database query. Then get that variables value whenever Mob::SendPosUpdate(int8 iSendToSelf) is called?

Like I said probably dumb questions but I am not sure how often this would be hitting the database.

Do it the way I posted above.

[Derision]

Originally Posted by Rocker8956

Query the database everytime the Mob::SendPosUpdate(int8 iSendToSelf) is called? I assume this would be a lot.

That's the last thing you want to do. I just compiled zone with profiling enabled and stood in Dreadlands by Karnor's Castle for 60 seconds and there were around 4500 calls to that method.

[trevius]

I would almost certainly say to set the variables on zone bootup. Seems to be the obvious choice. Anything that reduces the number of database hits is good, and setting that at zone bootup shouldn't cause any performance differences at all.

But, even though KLS says the 800 is hard coded, I can say that just by looking at what the MQ map shows, it seems pretty clear that the code I posted above is the code used for sending position updates. Within a range of 50ish, the movements on the map are almost perfectly smooth (.3 second timer), then from 50 to about 250, they are slightly less smooth (.6 second timer), and from 250 to 500 even slightly less smooth (.9 second timer), And anything from 500 to 800 is kinda choppy (2 second timer), and after that it uses the zonewide update setting, which by default is 1 minute, but if you set the rule it can be much higher.

So, I am not completely convinced that the 800 setting KLS mentioned is what is being used all of the time.

Here is the code that I think is handling those updates:

mob.cpp

void Mob::SendPosUpdate(int8 iSendToSelf) {
	EQApplicationPacket* app = new EQApplicationPacket(OP_ClientUpdate, sizeof(PlayerPositionUpdateServer_Struct));
	PlayerPositionUpdateServer_Struct* spu = (PlayerPositionUpdateServer_Struct*)app->pBuffer;
	MakeSpawnUpdate(spu);
	if (iSendToSelf == 2) {
		if (this->IsClient())
			this->CastToClient()->FastQueuePacket(&app,false);
	}
	else
#ifdef PACKET_UPDATE_MANAGER
		entity_list.QueueManaged(this, app, (iSendToSelf==0),false);
#else
		entity_list.QueueCloseClients(this, app, (iSendToSelf==0), 800, NULL, false);
#endif
	safe_delete(app);
}

entity.cpp

void EntityList::QueueManaged(Mob* sender, const EQApplicationPacket* app, bool ignore_sender, bool ackreq) {
	LinkedListIterator<Client*> iterator(client_list);
	
#ifdef PACKET_UPDATE_MANAGER
	EQApplicationPacket* tmp_app = app->Copy();
#endif
	
	iterator.Reset();
	while(iterator.MoreElements())
	{
		Client* ent = iterator.GetData();

		if ((!ignore_sender || ent != sender))
		{
#ifdef PACKET_UPDATE_MANAGER
			ent->GetUpdateManager()->QueuePacket(tmp_app, ackreq, sender, ent->DistNoRoot(*sender));
#else
			ent->QueuePacket(app, ackreq, Client::CLIENT_CONNECTED);
#endif
		}
		iterator.Advance();
	}
#ifdef PACKET_UPDATE_MANAGER
	EQApplicationPacket::PacketUsed(&tmp_app);
#endif
}


void EntityList::QueueClientsStatus(Mob* sender, const EQApplicationPacket* app, bool ignore_sender, int8 minstatus, int8 maxstatus)
{
	LinkedListIterator<Client*> iterator(client_list);
	
	iterator.Reset();
	while(iterator.MoreElements())
	{
		if ((!ignore_sender || iterator.GetData() != sender) && (iterator.GetData()->Admin() >= minstatus && iterator.GetData()->Admin() <= maxstatus))
		{
			iterator.GetData()->QueuePacket(app);
		}
		iterator.Advance();
	}	
}

updatemgr.cpp

void UpdateManager::QueuePacket(EQApplicationPacket *app, bool ack_req, Mob *from, float range2) {
	int r = UPDATE_LEVELS;
	UMMap *cur = levels;
	const float *cur_d = level_distances2;
	cur += UPDATE_LEVELS;	//move to the end.
	cur_d += UPDATE_LEVELS - 1;
	//work backwards since mobs are more likely to be further away
	for(r = UPDATE_LEVELS; r >= 0; r--, cur--, cur_d--) {
		if(range2 < *cur_d)
			continue;
		//this packet falls into this queue...
		uint32 id = MakeUpdateID(from, app);
//		if(r < 2)
//			net->QueuePacket(app, ack_req);
//LogFile->write(EQEMuLog::Debug, "Queueing packet from %s (0x%.4x) id=0x%x at level %d\n", from->GetName(), app->GetOpcode(), id, r);
		app->PacketReferenced();
		//reference decrementing is taken care of my UMType destructor
		//if anything is overwritten
		(*cur)[id] = UMType(app, ack_req);
//		(*cur)[id] = UMType(app->Copy(), ack_req);
		return;
	}
	//if we get here, were in trouble...
}

[KLS]

Yeah I'm right and wrong it depends if you have update manager enabled or not. By default it's turned off though.

[Rocker8956]

Well after looking into this a bit further it looks like I am going to duck out of this one. This code is really out of my league and I currently do not have time to learn it.
Sorry guys, I was going to give it a shot but don't have the time. Hopefully someone else understands all that code and how it works.

[trevius]

Hmm, I haven't turned update manager on myself. But, after checking into it more, it seems like both are actually being used. Both update manager and the hard setting at the same time. It seems like the hard setting is the cutoff to where it will only use the zonewide update timer. But, within the hard setting it uses the settings from the update manager.

What I have done so far is to change the hard settings from 800 down to 400 like this:

mob.cpp

// this one just warps the mob to the current location
void Mob::SendPosition() {
	EQApplicationPacket* app = new EQApplicationPacket(OP_ClientUpdate, sizeof(PlayerPositionUpdateServer_Struct));
	PlayerPositionUpdateServer_Struct* spu = (PlayerPositionUpdateServer_Struct*)app->pBuffer;	
	MakeSpawnUpdateNoDelta(spu);
//?	spu->heading *= 8;
#ifdef PACKET_UPDATE_MANAGER
	entity_list.QueueManaged(this, app, true);
#else
	entity_list.QueueCloseClients(this, app, true, 400);
#endif
	safe_delete(app);
}

// this one is for mobs on the move, with deltas - this makes them walk
void Mob::SendPosUpdate(int8 iSendToSelf) {
	EQApplicationPacket* app = new EQApplicationPacket(OP_ClientUpdate, sizeof(PlayerPositionUpdateServer_Struct));
	PlayerPositionUpdateServer_Struct* spu = (PlayerPositionUpdateServer_Struct*)app->pBuffer;
	MakeSpawnUpdate(spu);
	if (iSendToSelf == 2) {
		if (this->IsClient())
			this->CastToClient()->FastQueuePacket(&app,false);
	}
	else
#ifdef PACKET_UPDATE_MANAGER
		entity_list.QueueManaged(this, app, (iSendToSelf==0),false);
#else
		entity_list.QueueCloseClients(this, app, (iSendToSelf==0), 400, NULL, false);
#endif
	safe_delete(app);
}

I also slightly tweaked the update manager settings to be a little smaller and less frequent for mid range distances:

updatemgr.cpp

//squared distances for each level
//these values are pulled out of my ass, should be tuned some day
const float UpdateManager::level_distances2[UPDATE_LEVELS]
	= { 50*50, 250*250, 400*400, 600*600 };
	
//delay between sending packets in each level, in ms
//its best if they are all multiples of UPDATE_RESOLUTION
//these values are pulled out of my ass, should be tuned some day
const int32 UpdateManager::level_timers[UPDATE_LEVELS+1]
	= { UPDATE_RESOLUTION,		//.3s
		2*UPDATE_RESOLUTION, 	//.6s
		3*UPDATE_RESOLUTION,	//.9s
		12*UPDATE_RESOLUTION,	//~2s
		48*UPDATE_RESOLUTION	//~10s
	  };

And finally, I set my rule for the zonewide updates from 1 minute to 10 minutes. I really don't even know if we need zone wide updates at all. After these changes, so far the raids in Dreadspire which I was using as a reference for the lag issues have said that the lag is now completely gone. I still need to do more testing, but so far this is looking promising. We may not want these same settings across the board or anything, but certainly smaller closed in zones like dungeons should have the option to lower these settings.

I posted the code changes with colors because this isn't any sort of a final code submission. If I come up with anything that seems final, I will try to get it in the format that KLS is wanting. But, the code currently posted should help make it easier to discuss further steps.

Oh, an one idea I had that could potentially save me a TON of bandwidth was if I could disable position updates completely maybe by setting them to 0 for my server base zone which is Nexus. I only have 1 roaming NPC in there anyway, so if I stopped it from roaming, they wouldn't need position updates. And since that zone is almost always occupied by many AFK players, it would potentially save me a TON of bandwidth. Also, if we ever get the bazaar working, I think we should have similar options to help reduce bandwidth in there.