Go Back   EQEmulator Home > EQEmulator Forums > Development > Development::Bug Reports

Development::Bug Reports Post detailed bug reports and what you would like to see next in the emu here.

Reply
 
Thread Tools Display Modes
  #1  
Old 10-21-2008, 08:43 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

I don't think expecting AEs to flow smoothly across 100+ npcs in a single zone is reasonable =p Can look and see if we can improve it though.
Reply With Quote
  #2  
Old 10-21-2008, 11:10 PM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Quote:
Originally Posted by KLS View Post
I don't think expecting AEs to flow smoothly across 100+ npcs in a single zone is reasonable =p
Agreed. That's why, instead of trying to stop a speeding train, I'm thinking at least do something so everything down the line know it's coming.

The big thing I'm not sure about is, should we do this just for AE rampage (an exception), or are there any other circumstances where we would need to tell the client the zone is still alive? And if so, what's the best way to implement it without using much more bandwidth?

If memory serves me, Live implemented something back around Luclin or PoP (I forget which, couldn't find it browsing through the patch logs) where only so many (10-30?) mobs would attack at once, the rest would sit & twiddle their thumbs a safe distance away, then when one dies, another would get closer to take its place. It was odd, because you could pull a massive train, but when some started hitting you, the rest scattered like roaches. Then, if you got far enough that they weren't attacking you, then would all catch up (was a pita to get them all grouped together). I'm not sure if it's still the same way on Live, but maybe this is what we're looking at in the long run.
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #3  
Old 10-22-2008, 12:50 AM
ChaosSlayer
Demi-God
 
Join Date: May 2007
Posts: 1,032
Default

I don't remeber where that was, but it was somewhere, that there was a max cap on how many mobs can be agroed at player at once.
this was capped at like 20 or 30 or so. Specificly for the purpose to prevent massive chain-agro trains and massive lag.

Of course aoe farmers would hate that, but if helps to improve zone stability- something like this could be put into rules =)

PS. related question of zone lag - is it posible to server side set MAX viewable distance for a zone? and fog density?
Reply With Quote
  #4  
Old 10-22-2008, 01:01 AM
trevius's Avatar
trevius
Developer
 
Join Date: Aug 2006
Location: USA
Posts: 5,946
Default

The odd thing is that he was able to test rampage with a normal weapon and not cause any large CPU spike or "crash", but using a procing weapon, it caused the problem right away and CPU went to 100%. Now, in his tests, he was using an AE procing weapon, which I can understand would cause a huge spike in CPU over a normal non-proc weapon when rampaging a huge pull. But, the rampage crashes on my server seem to happen with just normal procs, so maybe it is the proc process that is driving CPU Utilization up. I may have to do some more in-depth testing myself if I get time. If it is the proc process, maybe we can figure out what is causing it to be so much more CPU intensive than normal melee hits, because I don't think the formulas are any more complex.
__________________
Trevazar/Trevius Owner of: Storm Haven
Everquest Emulator FAQ (Frequently Asked Questions) - Read It!
Reply With Quote
  #5  
Old 10-22-2008, 03:02 AM
paaco
Discordant
 
Join Date: Jan 2005
Posts: 320
Default

With a wep like he was using that has to be a massive amount of number crunching hitting all of those mobs. I don't know if it's much faster at crunching numbers but if anyone wants to test anything like this on my server just as a comparison I'll give you whatever items, skills, lvl you need. It would be awesome to fix rampage and AoE so they aren't crashing zones so bad. That is a nasty problem on Storm Haven, I like to train myself in Delve late at night and rampage for aa's. But every now and then I crash the zone. ( sorry! ) That is only using my 1.5 and the cog blaster wep in offhand.

my server runs 32 bit windows
Phenom 9850 Quad Core
4 gigs of ram
on a 10mbit down 2mbit up cable connection.

If anyone wants to test on it just gimme the word.
Reply With Quote
  #6  
Old 10-22-2008, 03:14 AM
AndMetal
Developer
 
Join Date: Mar 2007
Location: Ohio
Posts: 648
Default

Quote:
Originally Posted by paaco View Post
Phenom 9850 Quad Core
The processing power (2.5GHz x 4 cores) would be awesome, except the zones themselves don't support multithreading (at least on my Dual Xenon 3.2GHz machine). Otherwise, I'd want to see what happens

I think the main issue w/ the procs is that the spell code had a lot more that needs to be checked (resists, focuses, etc) vs just the melee code. Add it on top of each other, and things go crazy.

I mean, yeah, my example in SSeru is worse case scenario, but it's still dangerous for stability to use on more than a few mobs at once with a proccing weapon.

One thing that may be worth testing is the exact impact on a single proccing weapon vs an AE proccing weapon.
__________________
GM-Impossible of 'A work in progress'
A non-legit PEQ DB server
How to create your own non-legit server

My Contributions to the Wiki
Reply With Quote
  #7  
Old 10-22-2008, 04:03 AM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default

Spell packets are also considerably larger than melee packets and there's more of them. Knowing procs cause it is a good place to start at least.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

   

All times are GMT -4. The time now is 04:26 PM.


 

Everquest is a registered trademark of Daybreak Game Company LLC.
EQEmulator is not associated or affiliated in any way with Daybreak Game Company LLC.
Except where otherwise noted, this site is licensed under a Creative Commons License.
       
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Template by Bluepearl Design and vBulletin Templates - Ver3.3