New Concept: Proximity Spawning (to reduce bandwidth usage)

[cubber]

This sounds interesting but I have a few questions to think about.

1. If this despawns mobs that are not in a certian radius of the player then couldn't this approach be used as an exploit? If a player is trying to camp a named mob and the mob is not up, couldn't the player just venture out of the place holder's radius to despawn it? Triggering a respawn when they come back into it's radius, essentialy cycling the camp without killing anything? What about named mobs like CT that are only supposed to spawn on a schedual?

Or will the "despawned mob" basically be "cached" until it is revealed again, killed, or cycled by spawn timer?

2. What about respawn times in general? Could this be used to get around respawn times?

3. Also in comparison to WoW, I think that the spawn radius would have to be quite larger than what they impliment. It is quite annoying to be able to see a few hundred yards away but not see any mobs in that area until you are almost right on top of them.

[Rocker8956]

This does not effect if the mob is spawned. Basically the mob is still there but the player does not get updates on the mob's position unless the player is within so many feet of the mob.

One question I have though, does this effect track?

[cubber]

Ahh that makes more sense then.

[trevius]

Cubber, the original suggestion to actually depop mobs that were out of range would have worked perfectly fine for everything accept Track. The spawn timers would still be checked before a mob would be spawned if a player entered the spawn radius. The only thing you would need to take into account to avoid possible exploits would be to remember that you don't want to depop and repop named or anything with particularly nice loot tables, especially if they are set to equip the items. As long as they don't equip the items, the players would still have no way to tell what loot was or wasn't on the mob, so even named could potentially be depopped. The main thing is that there would be a per NPCID setting to allow you to enable the spawn to use the system or just to stay up like mobs currently do.

But, it looks like this change may not even be needed anyway as there seems to be a much better way to accomplish what I was originally wanting to do just by adjusting values in the source for setting the radius that the updates are sent.

The last code changes I posted in this thread show how to adjust the source to help reduce bandwidth. As far as I can tell and have heard so far, even just making the changes I posted has made a HUGE impact (in a positive way) on the amount of lag and performance problems on the server. The only time my players have seen noticeable lag since the change was when my server broke 100+ players this weekend, which hasn't happened in a while. So, I am fairly confident that if we can make some code that allows each of these settings to be tweaked in the source, I think we can potentially make a great reduction in bandwidth utilization and allow more players on servers with lower upload speeds and with less lag.

I think we should have settings added to the zones table to set the QueueCloseClients settings for both warping to location and for walking animations. I also think we should have the options to be able to adjust all 4 of the level_distances2 settings individually as well as all 5 of the UPDATE_RESOLUTION settings. Of course there should be defaults set if the fields are left at 0, which would be default for the new fields. But, by giving this option, I really think high traffic zones could be tweaked enough to really make a big difference on any server.

Also, I have set zone wide updates to 10 minutes and so far I haven't noticed any different at all in game other than less lag from when it was set to the default of 1 minute. I will have to try running around in an open zone at GM speed to see if I notice anything weird. But, unless I am wrong, maybe we should allow the globalpositionupdate rule to have a setting that will completely disable zone wide updates. Maybe setting it to something like 0 or so could make it disabled.

Either way, I think we are on the way to increasing server performance for servers with limited bandwidth. I would love to see home servers able to reach the 200 or 250+ player counts that are seen on PEQ or the CEQ Dragon Soul server. I know PEQ is/was hosted in a Data Center which essentially gave it unlimited upload speeds and I assume Dragon Soul is as well.

[KLS]

Yes, you need zonewide updates.

But we can make the zone wide update smarter, it's only really a problem for mobs that move a significant distance in their roam path. Think large zones like plane of growth or temple of veeshan.

The problem is this:

Player is at point A and receives basic mob initial positions.
Player sees mob at point B 1000 units away but because it's out of update range and mob is a roamer it wont update.
Player moves to point B but mob is at point C 1000 units away because it roamed and now sees the ghosted mob because point C is out of update range too and point B was initial position.

We can make it smarter by sending updates to all players if a npc moves a certain distance threshold I think, then we wont have to send a global update for all npcs.

[Rocker8956]

I think this would only effect character's with track and people using MQ. Couple of questions to confirm that though.

Does track get the mob's position from the server everytime it ticks? or does it use the cleint's last known position of that mob?

The ghost would disappear before the player saw it because the player would have to be within the level 3 distance to see it correct? or does the update only happen if the mob is within that range?

Is the client smart enough to ask "Is this mob really there?" when the player tries to target it?

[Rocker8956]

Sorry for the back to back post, ran out of time to edit.

Does an update occur in the level 2 and level 3 intervals even though it occured during the level 1 interval?