Woot! I think I found part of what KLS is talking about:
zone/updatemgr.cpp Code:
//squared distances for each level I think more could definitely be done, but I will have to look into finding other parts that could possibly be tweaked further. |
Quote:
Anyway, just my thoughts. I'm sure that if you're doing this, you've already thought of it, but wanted to suggest that if you use quest::depopzone that you make sure to disable the respawn timers until the boss has died, and then re-enable them. Though that only sounds useful for fights that aren't intended to have the added difficulty of add control =) Just my thoughts, this sounds like a really good suggestion if a reasonable way to implement it can be found. |
Working with Trev on this,
We have as system set up atm that if an event is engaged, we do a zone wide depop of all trash mobs using quest::depopall(npcid) for each trash, then pop some KOS guard mobs in specific locations so people can't just run around the zone with a few others things built in to avoid abuse. When event is over zone repops all the trash with quest. This works fine. But obviously the flaws are there which is it really affects any other group in the zone forcing a 8-10 minutes of down time. Plus if you want to do an event with smaller force it could take even longer, and then if your moving from event to event quickly you could basically have the zone locked up for a while making it unplayable by others. Is that worth it so everyone doesn't have a 70% chance to lock up/crash when fighting the event, probably but its not the ideal solution. There are other ways around it which are better, but just require more advanced planning and coding useing standard scripts, set up certain areas of the zone with only certain NPCid's then have quest mobs spawn and check aggro if any players are in that area and if its clear then depop it, otherwise leave it up and hope by the time they are done in the area the event is over. But really all these solutions are cumbersome and were praying we can get something more solid. |
anoher thing: you think turning OFF Npc buff friends would help with the lag?
Since npc needs to not only buff all their friends but also keep a watch when their buffs expire etc |
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.
|
How about have the server dynamically base the range it sends the clients updates of mobs info is based on if the person is moving around or not.
Someone staying relatively stationary doesnt need to get updates from mobs more than 400 distance, while someone running certainly would in order to avoid running into said mobs. This also avoids having to set this range on a per zone bases. |
PS You could even add a fudge factor based off current server population so when theres less people logged on the range would be longer and be shorter when more people are logged in.
|
Quote:
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. |
Quote:
|
Quote:
|
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 Code:
void Mob::SendPosUpdate(int8 iSendToSelf) { Code:
void EntityList::QueueManaged(Mob* sender, const EQApplicationPacket* app, bool ignore_sender, bool ackreq) { Code:
void UpdateManager::QueuePacket(EQApplicationPacket *app, bool ack_req, Mob *from, float range2) { |
Yeah I'm right and wrong it depends if you have update manager enabled or not. By default it's turned off though.
|
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. |
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 Code:
// this one just warps the mob to the current location Code:
// this one is for mobs on the move, with deltas - this makes them walk updatemgr.cpp Code:
//squared distances for each level 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. |
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. |
All times are GMT -4. The time now is 02:32 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.