Mods properly calculated
Stages should be put in place if not already:
https://wiki.project1999.com/Food_and_drink#Stages_of_Hunger_and_Thirst
Values stored in the database are 0-6000, previously we capped it at 6000 but previous math would have normal values in the 60k+ range in order for food to be consumed at a reasonable rate. We are now using more native logic where 1 = 1 minute, following logic:
(Minutes)
0 - 5 - This is a snack.
6 - 20 - This is a meal.
21 - 30 - This is a hearty meal.
31 - 40 - This is a banquet size meal.
41 - 50 - This meal is a feast!
51 - 60 - This is an enduring meal!
61 - X - This is a miraculous meal!
Raid/Group Mana/Endurance updates should now update real-time once again
Fixed an issue with clients looking like they are 'skipping' when they are moving in view of another client
Fixed an issue with NPC's who are ghosted in plain view of a client when they are not really there
- HP Updates now only send to others when HP percentage changes (0-100%)
- HP Updates were sending excessively even during idle zones when HP wasn't changing at all
- Attack animations now only send once per second versus up to a hundred times a second per Mob/Client
- 17,000 OP_ClientUpdate packets per second have been observed in combat scenarios, some of the major culprits have been
throttled without affecting what the client should see
- Before and After packet differences under similar load/tests (Packets per second)
- 7,000 - 8,000 OP_Animation pps After: 600-800 pps
- 13,0000 - 17,000 OP_MobHealth pps After: 1-10 pps
- 15,0000 - 20,000 OP_ClientUpdate pps After: 500-1,000 pps
- Packet reports from a 46 client test here:
https://gist.github.com/Akkadius/28b7ad2fdd82bdd15ea737c68f404346
- Servers who use Marquee HP updates will also recieve far less packet spam as they will only be sent when HP changes
$client->Popup2("Title", "Text", YesID, NoID, Buttons, Duration, Button0, Button1);
YesID / NoID are the "popupid" for EVENT_POPUPRESPONSE depending on the players choice
Ahh not too sure why this is needed. We used the other field before
and the client is still displaying correct item clicky cast times
as well as food duration string ... Oh well
- Before when reverse aggro checks were done (client to NPC), checks would happen every 750 millseconds where a client would
check an entire entity list with distance calcs and other checks for aggro, with many clients in a zone and many NPC's this would
add a lot of unecessary overhead. A temporary adjustment on 3/25 was made and upped the check to 6 seconds.
- Now, there is a new methodology to scanning. The client will build a cache list of NPC's within close range as defined in new rule:
RULE_INT(Range, ClientNPCScan, 300) and will also get any NPC that has an aggro range beyond that defined range to use in
the frequent checks for aggro, the result is far less overhead
- Client scanning changes when moving versus not moving, the client will scan aggro every 500 milliseconds while moving, and
3000 millseconds aggro check when not moving, with a 6000ms re-fetch for close NPC's
- A demo of these changes can be found here:
https://youtu.be/aGroiwLSTVU
been adjusted to 6 seconds per new rule RULE_INT(Aggro, ClientAggroCheckInterval)
- When zones have many players, with many NPC's, this adds up quickly
- the defaults are set in the code and can be tweaked by sourcing utils/sql/git/optional/rule_values_range_update.sql
- Thanks to mackal for gathering live ranges, thanks to takp for initial numbers
- We would send 200 for combat updates and the client will only display <= range 54 anyways, these should help a lot in spammy combat
RULE_CATEGORY( Range )
RULE_INT ( Range, Say, 135 )
RULE_INT ( Range, Emote, 135 )
RULE_INT ( Range, BeginCast, 200)
RULE_INT ( Range, Anims, 135)
RULE_INT ( Range, DamageMessages, 50)
RULE_INT ( Range, SpellMessages, 75)
RULE_INT ( Range, SongMessages, 75)
RULE_CATEGORY_END()
