New Concept: Proximity Spawning (to reduce bandwidth usage)

[trevius]

Well, consider that every NPC already has a radius check when they check for people entering aggro range. So, this system would essentially only be extending that radius, which means it probably wouldn't cause more server load in that aspect.

Then, consider that NPCs that might have running scripts, pathing, spell casting, and other checks running continuously would now only be running them when players are within range.

Also, I can repop an entire zone at once with only a blip of a performance hit. If only 2 or 3 spawns are popping per second while players are running around, I don't think that would cause any noticeable impact on performance. Even if they were moving fast enough to spawn 20 at once, it would only happen while they are running around, not while they are fighting, unless maybe if they are kiting. And, raid fights are my main concern for reducing lag. Raids and AE groups are the only real things that I ever see cause performance hits on my server.

And for players moving at really high speeds, normally that would be in open zones outdoors. In that case, you could either leave this system off for all NPCs in the zone, or set them to have a really large radius to ensure that mobs are popping on top of people. I don't think anyone moves faster than 600 feet per second without warping hehe.

Another bonus to this feature is that admins could setup zones that MQ maps are useless for. Players wouldn't be able to see which spawns are up or down on the map unless they actually entered the nearby area. I imagine that could be useful in many situations for those anti-MQ admins

The nice thing about this idea is that it would be a fully optional setting. You could leave important NPCs like Named and other scripted NPCs up all of the time by setting them to not use the system. This system is mainly to get rid of unneeded trash spawns.

I do think that the coding for this might be pretty easy to do. I am going to look into the aggroradius code and see if there is a way to possibly combine that with the spawn2 table to make the server watch for players to enter a set radius around each spawn point.

Yeah, not having an NPC there to base the radius check is probably my main concern, but I still think it should be possible. And the potential for very noticeable performance increases should be worth at least looking into this further.

[trevius]

After thinking about it a little more, there would probably have to be a few extra things done to make sure this system was pretty flawless. Most importanly is to make sure that if the NPC is following a running player that it won't poof once the player gets too far away from it's spawn point. So, if IsEngaged, then it negates it from despawning.

Also, we might want to consider adding extra code to make sure that people can't exploit the system by pulling a single mob that is just barely within range to spawn so they can avoid pulling the other spawns that would normally be near it. But, most likely this wouldn't even be a factor if we set the radius range to something like 300+, since I don't think anything can pull from that far anyway.

Here is some unmodified code from the source I found quickly to maybe start looking at to base this code on:

zone/aggro.cpp

//look around a client for things which might aggro the client.
void EntityList::CheckClientAggro(Client *around) {
	_ZP(EntityList_CheckClientAggro);

	LinkedListIterator<Mob*> iterator(mob_list);
	for(iterator.Reset(); iterator.MoreElements(); iterator.Advance()) {
		_ZP(EntityList_CheckClientAggro_Loop);
		Mob* mob = iterator.GetData();
		if(mob->IsClient())	//also ensures that mob != around
			continue;
		
		if(mob->CheckWillAggro(around)) {
			mob->AddToHateList(around);
		}
	}
}


	LinkedListIterator<Mob*> iterator(mob_list);
	for(iterator.Reset(); iterator.MoreElements(); iterator.Advance()) {
		Mob* mob = iterator.GetData();
		if(mob->IsClient())	//also ensures that mob != around
			continue;
		
		if(mob->DistNoRoot(*from_who) > d2)
			continue;
		
		if(engaged) {
			int32 amm = from_who->GetHateAmount(mob);
			if(amm == 0) {
				towho->Message(0, "... %s is not on my hate list.", mob->GetName());
			} else {
				towho->Message(0, "... %s is on my hate list with value %lu", mob->GetName(), amm);
			}
		} else if(!check_npcs && mob->IsNPC()) {
				towho->Message(0, "... %s is an NPC and my npc_aggro is disabled.", mob->GetName());
		} else {
			from_who->DescribeAggro(towho, mob, verbose);
		}
	}
}

Also, another idea that would help bandwidth and could replace this idea would be to just make it so that only mobs withing X radius of a player will send their current position information to them regularly. The entire zone would still be spawned exactly like it is now on the emu, but the client would only get updates from nearby mobs instead of every mob in the zone. It wouldn't really effect server load, but it should definitely help bandwidth and may be a better solution than the one I am suggesting in this thread. But I don't know how possible this second idea would be.

I am trying to figure out why WoW Emulator servers can handle 2000 players with only 1 or 2MBs of upload bandwidth (at least that is what I have heard). If it is true, then there definitely has to be something we can cut down by alot to help reduce bandwidth. And, I am almost positive that WoW doesn't send all spawn information to all players, I think they do a radius type thing like I am suggesting.

[trevius]

Still looking into this, it seems like this would maybe not be too hard to implement into the spawn_conditions code. Instead of just checking the time of day, it could have a separate option to just check player range from the spawn point before spawning and then depop if they get out of range of the NPC once it has spawned if they don't have aggro on it already.

I am trying to think of this on a per mob basis to make the concept easier to grasp which should hopefully make coding easier. Basically, all we need is a way for the server to spawn an NPC when a player gets near a spawngroup location without using any kind of placeholder to spawn it. It would have to check if an NPC is already spawned at that location before it tries to spawn another. Then, there needs to be a similar setup to depop the NPC when they get out of range if the NPC isn't engaged/aggroed.

I am sure this could be done with quests fairly easily, but it would be much easier to do it for entire zones at a time by setting a simple setting in the database. I think we could even potentially just have the check run as a client location check vs. the spawn group location and radius settings. Then, every spawn location in the zone wouldn't be looking for players to enter their radius, the check would only be done from around the client if they got within the radius which might reduce server load as well.

it looks like the spawn_conditions are checked before anything else when deciding to spawn an NPC, so that would be a good thing to reference when setting up this system.

Doing the coding work for this is probably a bit above my skill level, but I will keep looking into possibilities of how to write code for it.

[trevius]

Another thing I thought of is that the spawn group IDs, the spawn locations (X, Y, Z), and the spawn_radius setting will probably all need to be loaded into memory when the zone boots up. This way, the system can work without having to poll the database constantly for the spawn locations when it is checking the radius.

[KLS]

Personally I really hate this idea, not because i'm against the idea behind it but because I think it's the wrong approach. We really need a more involved spawn conditionals system so people can setup their events in an intelligent manner.

Perhaps a system where npcs can spawn and despawn based on certain conditions set by the quest system. Ex: In this case your boss is engaged and you have it set boss_one_engaged flag for the zone and all npcs that aren't essential despawn. Or perhaps you have a linear zone and only once a boss is killed the trash and next boss will spawn. etc etc.

[KLS]

Oh yeah and how wow works is just more efficient, it's also facilitated by the client.

Every continent is separated into zones which are separated into smaller areas which are all separated into smaller map nodes. Npcs in a node are only active if a player is nearby. At least this is how the emu basically works; not how the official servers work.

Perhaps we could have npcs freeze and not do ai if they're a certain distance from player characters. Might cause some problems for existing events.

[ChaosSlayer]

Originally Posted by KLS

Personally I really hate this idea, not because i'm against the idea behind it but because I think it's the wrong approach. We really need a more involved spawn conditionals system so people can setup their events in an intelligent manner.

Perhaps a system where npcs can spawn and despawn based on certain conditions set by the quest system. Ex: In this case your boss is engaged and you have it set boss_one_engaged flag for the zone and all npcs that aren't essential despawn. Or perhaps you have a linear zone and only once a boss is killed the trash and next boss will spawn. etc etc.

well this may work for sort of ldon/raid/encounter instance, but then you don't realy need anything special - when boss is engage you simply send a signal to depop entire zone exept the econuter


the real issue comes to handlign somethign as large as West Karana or Dread Lands which supose to have crap load of trash mobs running around

[KLS]

The more I think about it the more I think having npcs freeze if there's no pc nearby would help a lot with the situation and have less of a downside than popping and repopping based on proximity.

[trevius]

We have already been testing a quest system to depopall() on all trash mobs when a boss mob or named is being killed. It seems to completely stop all lag as compared to previously people would go LD and lag extremely bad in some cases.

But, I really don't like the quest solution, because then anyone else in the same zone will then see an empty zone, which not only looks bad, but also lets them roam freely without clearing anything and basically negates all of the work to create the trash mobs in the first place.

Any special settings like the radius_spawn idea or freezing them to stop all AI and pathing would have to be specified by a setting in the NPC_types table so it could be done on a per mob basis. Then you can decide which ones you want to be affected by any of these ideas, and which ones to remain normal all of the time. So, bosses, scripted NPCs and maybe some roamers might want to have this setting turned off, but other than that, almost all trash mobs aren't always needed.

By turning off the AI or freezing the mobs like KLS mentioned, that might help the server performance, but I honestly don't see any issues at all lag-wise on my local lan, ever. I only ever hear about the lag, so it is pretty obviously a bandwidth issue. I have 1MB upload bandwidth from my ISP, which is fairly decent as far as home connections go. If 1MB up can have lag during a raid of about 3 groups with maybe 70 people logged into the server, then I think there could be some definite improvements to improve bandwidth utilization.

Unfortunately, I don't know of any way to not send regular updates of the current location of every spawn in the zone every second to every character in the zone. So, the only solution I can think of is to not have trash mobs spawn unless a player is within range. The only other option would be if someone could figure out a way for the server to only send location updates for NPCs within a radius of the client.

[ChaosSlayer]

I am trying to figure out why WoW Emulator servers can handle 2000 players with only 1 or 2MBs of upload bandwidth (at least that is what I have heard). If it is true, then there definitely has to be something we can cut down by alot to help reduce bandwidth. And, I am almost positive that WoW doesn't send all spawn information to all players, I think they do a radius type thing like I am suggesting.

its a good notice. A friend of mine plays wow his loading time is INSTANT from desktop into the game.
Thsi may have to do soemthign with wow inherited seamless zoning structure - the game is inheretly designed to be zoneless (with few exeptions) and this means any given player is only been sent information of some small surrounding area. However this does not mean that mobs are not up.

Now even with all those "wow" features (wow world is much smaller than eq, but on other hand a player is only present in a single zone at a time) the diffirence in numbers of players supported is massive - there got to do be something we missing in how to handle server performance