Rampage AA + big pulls = zone issues?

[So_1337]

Is it possible they were initially aggro'd and just took that long to get to you? I found that even using the new #aggrozone command that it would take a considerable amount of time for all the enemies in a zone to get to me.

[jax0rz]

From my testing it does seem a lot more stable if you are using a pure melee weapon instead of a proc weapon. My idea for a fix would be if you are calling function Attack via rampage, call TryWeaponProc once and save the calculation's it does for each hand if you are dual wielding. Then just apply that saved proc info on a flat rate based on the players dex until rampage is over. That way you are still proccing, but not spiking the CPU so badly doing the same calculation over and over.

I tried to code this, but I'm not the best coder and it seemed like a lot of work that would be best left to someone more expert with the current eqemu code.

[Loccochris]

If it is indeed the spell packets over actual proc calc then I wonder if it is possible to check everytime an aoe proc goes off how many mobs are in the area and if its > 10 just don't send the spell packet. Will basically add 1 extra comparison everytime a proc goes off (if proc type = aoe) and then if it is an aoe its going to add more overhead by counting in an area around the player. Depending on where the call to send initial spell packet is it might be easier to just clone PBAOE spells and have a version identical to the other just without a spell effect and if it is a pbaoe proc to switch which version of spell gets cast.

[trevius]

While the large amount of traffic being generated by AEing is definitely a concern, I don't think that is the actual cause of this issue. I think the problem is the server calculating it all at once. I think it gets so involved in the process of calculating the AE spells and hits and updates that it waits to long in between sending a keep alive to the client to keep them from crashing. At least that is my understanding of what AndMetal found.

Though, your idea is probably a good one to use anyway, because it would at least cut down on some unneeded bandwidth usage during AE.

[Loccochris]

While the large amount of traffic being generated by AEing is definitely a concern, I don't think that is the actual cause of this issue. I think the problem is the server calculating it all at once. I think it gets so involved in the process of calculating the AE spells and hits and updates that it waits to long in between sending a keep alive to the client to keep them from crashing. At least that is my understanding of what AndMetal found.

Though, your idea is probably a good one to use anyway, because it would at least cut down on some unneeded bandwidth usage during AE.

Hmm, I would think that the communication from server to client is threaded separately so it should have a chance at processor/nic card. There might be an issue where if they are in the same thread the calcs would prevent position updates (plus rest of packets needed to keep you in game) from happening. Would require threading specific parts of the packet lib that ONLY deal with keeping a player connected to its own dedicated thread.

If that is the problem threading it would probably also end up fixing all the LD's from zoning or multi boxing as a nice side effect. Of course finding the source and fixing it is not going to be easy, have to dig pretty deep in packet libs and pray the coder wrote good comments lol.

[KLS]

The problem is it completely lags the main thread. While outgoing and incoming communication have their own threads the main thread still decides when we queue a new outbound position packet. People noticed that aoe with addition spell effects attached make the problem worse which might be that it's more work than attacks, tho not by much but also that for each spell effect it adds extra packets that then need to be sent out. And things like basic packets the client needs to stay connected are already lagged because the main thread is lagging.

Since position packets etc. aren't part of the base protocol they aren't automatically handled in those threads like ACK and disconnect/connect packets for example. Keep alive packets are part of the base protocol but I'm guessing the client expects more info from the server than the base keep alive packet to maintain connection. That is basically the problem. We could spawn another thread for just AoE calculations but that doesn't seem like a very elegant solution.

[Kobaz]

OK, I haven't looked at the code in question (and C++ confuses me), but back in my youth when I wrote ecological sims in Smalltalk we would cache all but the random variations on affects upon agents in a Dictionary, which is a lot like a STL map. This could save thousands of calculations. Could this be done, using a key like npc_type*100 + level, so for each level 25 kobold you only need to calculate a random(-5,5) or equivalent for each mob, rather than the whole sum for each mob and each iteration?